基調講演
和田卓人さんの基調講演では、TDDBC仙台の開催経緯、TDDBCについての紹介などの後、TDDの背景、サイクル、こころ、プロフェッショナルとしてこの先生き残っていくためになど、TDDを軸として、示唆に富んだ講演となりました。
TDDBCについて
TDDBCの名前の由来は、ビリーズブートキャンプからとったそうです。
ペアプログラミングとチーム全員のコードレビューはよく言及されるが、実際にやった経験のある人は少ない。その両方を体験できるのがTDDBCであると紹介されました。その意味で、午後の演習の方が基調講演より大事だといいます。
また、TDDBCの開催実績と開催予定が示され、各地で活発にTDDBCが開催されていることも紹介されました。
TDDの背景
TDDを語るには、まず地ならしが必要だそうです。それは、「テスト」という言葉で思い浮かべるイメージ、範囲が1人1人異なり、テスト駆動開発の議論がかみ合わないことがよくあるため。誰が、何のためにという目的に立ち返ると、「開発者のテスト」「顧客視点のテスト」「品質保証のテスト」と、再分類できますとのことでした。
現代ソフトウェア開発の三本柱
次に、現代のソフトウェア開発で重要な3つのスキルとして、「バージョン管理」「テスティング」「自動化」があげられました。3つのうちで一番大事なのはバージョン管理ですが、今回は対象外であること、TDDBCで取り上げるのは2つ目のスキルとしてあげられた、テスティングであることが語られました。
なお、バージョン管理と同じく対象外ではありますが、3つめのスキルである自動化について、「自動化して、人間にしかできないことに時間を使いましょう」と語っていたのが印象的です。
3本柱、三種の神器というと、1つ欠けてもなんとかなりそうなイメージがありますが、実際には三脚椅子のように、3つのスキルが支え合っている、一本でもなくなると駄目になる重要なスキルであると強調していました。
動作する、きれいなコードへ
続いて、和田さんは、動作する、きれいなコードについて語りました。
テスト駆動開発に至るまでの考えとして、もしくはそもそもプログラマーとして私たちが書きたいと思っている到達点は、動作するきれいなコードです。 この、動作する、きれいなコードへと至るためには、下図の赤い矢印が指し示すようにきれいな設計からコードへと落とし込む道があります。
しかし、きれいを求め続けると際限がありません。もっと良い設計があるのではないのかといった完璧主義が邪魔をして、どこまでいったらコードを書くのか、なかなか動作するコードに進めなくなってしまいます。
それに対して、動作する、きれいなコードに至るにはもう一つ別の道もあります。それが図の青い矢印が示す、汚くても、動作する方向にもっていって、動作するコードをきれいにする道です。コードを書いて動かすことによって、初めて分かることがものすごく多いのです。動くコードから多くのことを学び、フィードバックが得られます。ここで学ぶ物が多いのだから、それを動作するまま、きれいにしていってここに至る道もあるというのを考え出したのが、テスト駆動開発です。
TDDのサイクル：Red⇒Green⇒Refactor
- テストを書く
- そのテスト実行して失敗（Red）
- 目的のコードを書き
- 書いたテストを成功させ（Green）
- テストがとおるままでリファクタリングを行う（Refactor）
- 1～5をくりかえす。
TDDのサイクルは基本的にこの繰り返しです。テストが通り、綺麗になったらもう一個テストを書きましょうと述べていました。
