TDD Boot Camp 名古屋（1日目）に参加しました。

二日続きのTDD(Test-Driven Development: テスト駆動開発)ワークショップに参加しています。
ワークショップはいろいろなプログラム言語のプログラマーの人たちが参加しています。Java, Ruby, C#, C++, Scala, OCaml(!), VB, e.t.c. 僕は仕事でよく使うC++で参加しています。けど、勉強を兼ねて、RubyかScalaにしてもよかったかな、と思ったりもしました。ワークショップはペアで（ペアプログラミングで）課題を解いていくのですが、ペアプロは教育効果がとても高いといわれてますもんね。

初めに和田さんのTDD概説の講義。和田さんの説明は原典「テスト駆動開発」に忠実で、それでかつ、実践している人のリアル感が強いのでいいですね。ただ、僕は「スティール・ボール・ラン」を読んでいないのが悔やまれました。

ワークショップの課題はハッシュテーブルのようなクラスの作成。途中で仕様変更なんかもあって、結構時間足りない感じでした。でも、キーワード置換で時刻と置き換える機能の作成では、モックがきれいに書けたのでよかったです。

今回のワークショップに向けて、なぜ僕はテスト駆動開発にこんなにもこだわるのか、考えてみました。
テスト駆動開発は、

コードをかみしめながら書ける
ほら動くでしょ、と誇りながら書ける
複雑にするとテストが面倒なので、自然にシンプルになる
書けた！と同時にほぼ動くものになっているので、なにかと都合がいい

こういったメリットがあると思っています。最初のふたつは心情的なもの、みっつ目は設計への効果、最後のは品質的なものです。どれも大切なものです。
ただ、これらのメリットを、個人のたしなみとして習慣化しようとするのは、なかなか楽しい取り組みなのですが、これらを会社組織での取り組みにしていくのは、難しいことだと感じています。みんなの習慣を変えさせるほどのメリットを僕は示せるのか。
それを可能にしていくのは、ペアプロや常時結合といった他のプラクティスと組み合わせていくこと、さらに、プロジェクトファシリテーションのような場作りを通じて、フィードバックとカイゼン（新たなトライ）を実践していく、そういうことが自然とできるようにしていくこと、そういったさまざまなことの合わせ技だと、和田さんや、他の参加者の方々にも相談して、思いました。

さて、明日はレガシーコード改善編です。こちらも楽しみです。