「TDD Boot Camp Tokyo 2013-07」に参加しました

2013/7/27(土) 「TDD Boot Camp Tokyo 2013-07」に参加してきました。

DoorKeeper
http://tddbc.doorkeeper.jp/events/4663

Togetter
http://togetter.com/li/539759

場所は品川シーサイド楽天タワーです。
私、自宅から自転車で行きました。お財布に優しい距離なのです

参加者は40名くらいでしょうか。
申し込み開始初日でMAXまで達したような。。。毎度恐るべしTDDBC！

しかし素晴らしいイベントだった！
地球防衛軍４で連日忙しく 日が空いてしまいましたが、今更ながら復習のためブログ書く。

---

■基調講演 by 和田さん

今回のTDDBCのスライドは公開していないとのことなので、手元の個人メモから書き起こしてみる。
復習の際は、TDDBC福岡のスライドを参考にさせていただきました。
http://www.slideshare.net/t_wada/tddbc-fukuoka-day1

■和田卓人のTDD講座
・gihyo.jpで連載していた。 http://gihyo.jp/dev/serial/01/tdd
・ニコニコ動画でも全20回、解説付きで見れる。 http://www.nicovideo.jp/mylist/4805036

■Boot Campとは
・アメリカ海兵隊の新兵の短期間修練

■TDD
・不安を克服する術が、TDD。
・ケント・ベックの「テスト駆動開発入門」からTDDは始まった。

テスト駆動開発入門 (2003/09) ケント ベック 商品詳細を見る

・偉大な本は偉大な書き出しから始まる。「動作する綺麗なコードは、あらゆる理由で価値がある」

■動作する、きれいなコードへ

（出典： http://www.slideshare.net/t_wada/tddbc-fukuoka-day1）

●上側のオレンジ線
・これまでは、「良い設計をして、次に実装をすることで、きれないシステムが出来上がる」と言われてきた。
・図で言うと、上側のオレンジの道。でも、上側の道には罠がある。
・上側の線は、「きれいで動かない」という状態から抜けられない。
　→ つまり、「きれいな設計にしたい」という欲求から抜けられない。まさに沼地状態。
・システム開発にはスケジュールがある。コードを書き始めると、いろいろ分かり始める。
　→　「ここまで設計する必要は無かった」とか「きれいな設計だけど遅すぎて使えない」とかが分かり始める。
・なぜか？それは、ソフトウェア開発の歴史が未熟だから。
・ソフトウェア開発は登場人物が多すぎるので、予測が立ちにくい。
　→　手を動かしてみて初めてわかる。

●下側の青線
・設計はいいから早くコード書こうぜ、というのが下側の青線の方。
・動くけど汚いシステムが出来上がる。

●両者の比較
・上は、完璧心の呪い。
・下は、堕落沼。
・下にハマっていてもいけない。
・動くものでも、きれいにする意志を忘れてはいけない。
・上と下はそれぞれ難しさがある。
・でも、縦線を超える（動かない→動く）ことが大事。それを教えてくれたのがTDD。

■TDDのサイクル
・TDDでは、テストコードとプロダクトコードを交互に書きながら進めていく。
・TDDとは、サイクル。
・まず、「やることリスト」を作る。
・そこから１つだけ、やりたいことをピックアップする。
・そのテストコードを書く。
・テストコードを動かすと、プロダクトコードを実装してないので絶対に失敗する。（赤色になる）
・目的のコードを書く。テストを通すことを第一に考える。
・さっき書いたテストが成功する。（緑色になる）
・目標を満たす状態になったので、今度はコードの方をきれいに直すフェーズになる。それがリファクタリング。
・テスト駆動開発のサイクル自身は非常に単純

■TDDと黄金の回転

（出典： http://www.slideshare.net/t_wada/tddbc-fukuoka-day1）

１．テストを書く
２．リファクタリング
３．次のテストを書く

・回転にはチカラが宿る（by ジョジョの奇妙な冒険）
・どれも矢印で示せるのが大事。矢印は分岐しない。ひとつのアクティビティとして扱える。
・アジャイルの「帽子をかぶり分ける」と一緒。
・一番大事なのは、堕落沼（4象限の下側の青い線）から抜け出すため、リファクタリングを行うこと。
・リファクタリングには「意思」が必要。
・１個１個のアクティビティの中に「片付けフェーズ」を設けている。それが上手くリファクタリングをやるコツ。

■TDDをどうやるか？
・良い書籍がある。
・1冊目は、マーチン・ファウラーの「リファクタリング」

リファクタリング―プログラムの体質改善テクニック (Object Technology Series) (2000/05) マーチン ファウラー 商品詳細を見る

・2冊目は、「リーダブルコード。少ないページで読みやすく書いてある。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) (2012/06/23) Dustin Boswell、Trevor Foucher 他 商品詳細を見る

■TDDの精神
・テスト駆動開発は「回転」である。回転には力が宿る。(ジョジョ）

■TDDのこころ
以下の●印。

●１つずつ、少しずつ。段を小さく
・噛み砕いてテストに書ける段階まで分解していくのが大事。
・そこが難しいところでもあり、慣れが必要になる。
・タスクに分解するスキルがまず最初に大事になる。

●ひとりずつ仕留める
・複数を相手にせず、ひとりずつ対処する。
・宮本武蔵の「五輪書」にも、複数の敵に囲まれたときにどうすればよいかが書いてある。
　→ 「1対多」を、「1対1の連続」にする。

●すばやくまわす
・テスト駆動開発における回転は、「フィードバックサイクル」。
・速く回れば回るほど、テスト駆動開発はうまく機能する。
・レッド→グリーン→リファクタリングを早く回す。

●自分が最初のユーザ
・テストから書く、ということは、自分がこれから実装するコードの最初のユーザは、自分が書くテストコードになる。
・自分が書いたコードが使いやすいかどうかは、自分が使ってみないとわからない。
・実装を考える前に、必ず自分が使う側に回る。
・そうすると、「作るのが楽なもの」と「使うのが楽なもの」が違うことがわかる。
・「ドックフードを食う」という表現があるが、つまり、自分が作るものを自分で使い始める。

●不安をテストに
・テスト駆動開発をやってると、どのくらいテストを書けばいいか、何をテストに書けばいいか、という疑問が出てくる。
・答えは、「不安をテストにしよう」。
・テスト駆動開発の目的は、自分たちの不安を解消しながら前に進んでいくこと。
・回転を妨げるのは、不安。
・裏を返すと、不安じゃないところはテストしなくてよい。
・getterやsetterには不安はないはず。なので、そこはテストしなくていいはず。
・自分のコードにはムラがある。そこをテスト書いていきましょう。
・テストがセーフティーネットになり、命綱になる。バンジージャンプする直前に綱を編み始めるのでは遅すぎる。

■なぜTDDをするのか
・TDDには数値的なメリットはあるが、最大の理由は心理的なもの。
・即座にフィードバックを得るため。自分が今書いたコードが、動くか動かないか、すぐわかる。
・その積み重ねが膨大なテストケースになる。
・TDDをやってれば、見落としがない部分に関しては自信を持てる。

■TDDの真の目的
・テストは「目的」ではなく「手段」。
・真の目的とは、「健康であること」。
・なんの健康か、というと、コード。無駄の無いコード。
・変化に対応するのは健康体のコード。
・テストを書いて、リファクタリングを続けて、無駄が無く、重複が無く、良い名前がついたコードにすることができる。
・変更に対応するのは健康体のチーム。TDDで爆弾処理のようなことはしなくて済む。
・TDDで大きなトラブルは置きにくくなる。 → 定時で帰る。
・不安を克服し、健康を維持する。
・これがTDDの真の目的。

■事例
・TDDの効果に関する研究論文から２つ紹介する。

●MS/IBMの事例

（出典： http://www.slideshare.net/t_wada/tddbc-fukuoka-day1）

・MSではWindow Vistaの開発でTDDが一部導入されたらしい。あとMSNの開発にも。
・上の図から傾向が読み取れる。
　①不具合は軽減する方向に効果が出た。
　②コードの実装時間は増えている。
・実装時間は2割増えて、欠陥が7割くらい減る。
・お客様へTDDの効果を説明するのに使える図。

●エリクソンの事例

（出典： http://www.slideshare.net/t_wada/tddbc-fukuoka-day1）

・TDD被験者にアンケートを取っている。
・「TDDはテストから先に書くので、矛盾点とかに気づきやすい。」
　→ つまり、要求が洗練された。
・「実装工数が増えたのに、工数は減った」と5割の人が答えた。
　→　実装が増えたのに工数が減ったなら、何かが減ってるはず。
　→　減ったのは「デバッグの時間」。TDDで「デバッグ時間」が減る。
・デバッグの時間は読めないし時間がかかる。TDDをやると、ここの時間を減らせる。

■応用
●テストの無いコードが既にたくさんある。どうすればいいか。
　→ レガシーコード改善ガイドを読む。

レガシーコード改善ガイド (Object Oriented SELECTION) (2009/07/14) マイケル・C・フェザーズ 商品詳細を見る

・言語が何でかかれていようが、テストがないコードはレガシーコード。
・現場に1冊おいておくべき本。

●既にデータの入ったデータベースがある。どうすればいいか。
　→ データベースリファクタリングを読む。

データベース・リファクタリング (2008/03/26) スコット W アンブラー、ピラモド・サダラージ 他 商品詳細を見る

・DBのリファクタリングは、コードのリファクタリングよりも時間と慎重さが必要になる。

●テストが脆い
・Fragile Testsとは、壊れやすいテスト、内部に深く立ち入りすぎたテストのこと。
　→　開発の足手まといになる。
・Slow Testsは、黄金の回転が遅くなる。つまり、フィードバックサイクルが回らなくなる。
　→　スローテスト問題。
・これらの問題をどう改善していけばいいか。
　→　「xUnit Test Patterns」を読む。

xUnit Test Patterns: Refactoring Test Code (2007/05/21) Gerard Meszaros 商品詳細を見る

・この書籍は翻訳されていない。
・副題に「Refactoring Test Code」とある。
・壊れやすいテストコードをどうメンテしていくかについて言及している。
・900ページもある、鈍器。膨大な本。
・ほぼWikiの内容を書籍化した本なので、インターネット上で読める。


●どこまでテストすればよいのか。
　→　テスト技法の分野から1冊を選ぶとすれば、「ソフトウェアテスト技法ドリル」

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 (2010/10) 秋山 浩一 商品詳細を見る

・テスト設計について初歩から応用まで教えてくれる本。

●現実のシステムはもっと複雑だが、どうすればいいか。
　→　「実践テスト駆動開発」を読む。

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION) (2012/09/14) Steve Freeman、Nat Pryce 他 商品詳細を見る

・テスト駆動開発の2冊目のバイブル。
・テストを書きながらシステムを育てていくという思想。

■まとめ
・応用編として5冊の本を上げた。
・今日は「黄金の回転」を覚えて帰って欲しい。
・本を辿ること。
・TDDはスキルです。才能の世界ではない。練習すれば覚えられるし上手くなる。
・迷ったら写経をする。やり方は以下。

技術書の「写経」の方法。 1.ローカルで使える SCM を用意 2.「ほんたった」などで対象の本を固定 3.ひたすらサンプルコードを写して実行 4.実行するたびにコミット(コミットログにページ番号を含める) 5.疑問点があったらコミットログや本に書き込む 6.章ごとにタグを打つ

— Takuto Wada (@t_wada) February 12, 2010

・TDDの出会いは、「リファクタリング」の原著のレビューを読んだこと。そこで写経した。
・グリーンバンドを考えたのは、ボブ・マーティン。通称：ボブおじさん。
　→ 左手を見るとグリーンバンドがある。それで「プロなんだからテストかかなきゃ」と思う。一種の戒め。

---

■Steve Freeman氏による講演

この日のスーパー飛び入りゲスト、Steve Freeman氏による講演！
ちなみに和田さんの講演の中に出てきた書籍「実践テスト駆動開発」（通称：GOOS本）の著者です。


私の英語力が無いのが悔やまれる。。。
んでも、 @yattom さんがTwitterでリアルタイム翻訳を流してくださいました。
冒頭のTogetterから追えます。

あと、Steveが来る事をTwitterで事前情報をキャッチしてたので、私もGOOS本を持参しました。
もちろん狙うは、書籍への直筆サイン！休憩時間に無事いただくことができました。

---

■ペアプロ大会
午後からペアプロ大会です。お題「飲み物自動販売機 Ver 2.0」の詳細はこちら。

#tddbc お題: http://t.co/YRJ4iNIKUm 各言語毎のスケルトン: https://t.co/0mdzX00HBH

— Fumikazu Fujiwara (@freddiefujiwara) July 27, 2013

私は @megascus さんとペアで、Javaにて取り組みました。
確かステップ４かステップ５まで行けてたハズ。
コードはGithubに上げておきます。
https://github.com/makopi23/TDDBC_Tokyo_201307

@megascus さんからの有意義なアドバイスを戴きながらのTDDペアプロ、大変勉強になりました。

あと、Steveもペアプロに挑戦＆生コードを交えた解説タイムがありました。凄すぎてワロタｗ

@masaru_b_cl Steve & katzchang 組のペアプロ成果、ここに上がっています https://t.co/jH4tRamUxc #tddbc

— Takuto Wada (@t_wada) July 28, 2013

---

★感想：
ホント素晴らしいイベントでした！
基調講演も、飛び入りSteveも、ペアプロも、質疑応答も、TAも、何もかもが素晴らしい。
過去のTDDBCの参加者もおっしゃっていたんですが、今回は神回では無かろうか。。。
TDDBCに参加したことがない人は、是非参加をおススメしたいですね。TDDの真髄が1日に詰まっている。

ちょっとブログ書くまで日が空いてしまいましたが、これは書かざるを得ない、と思って今更ながら、復習の意味も兼ねて書きました。

関係者の皆様、ホント有意義なお時間ありがとうございました。