いっそ「リズム駆動開発」とか。
TDDに関する議論がアツイですが・・・デブサミ2010のTDDのトラックを実際に聞いてきて、正直TDDにはついていけなくなったな〜という感じがデブサミ直後はありました。
完全に外野席からになってしまいますが、「テスト」「品質」、言葉一つ取っても十人十色の解釈で、「うえ〜〜〜、TDDをきちんと理解しようとしたら、こうした言葉の定義から厳密に理解しないと駄目なの〜〜〜？？しかもみんな解釈がばらばらで、どれを信じればよいのかさっぱりだ〜〜」状態です。
数日経ち、「そもそも何でTDDが取りあげられてきたんだろう？」という疑問が出てきました。
TDDでは「RED→GREEN→REFACTORING」が「マントラ」として重視されており、このテンポというかステップを細かく繰り返すことでプログラミングに集中し、生産性を向上させる・・・というのが「そもそもの」TDDのキモなのかなと自分なりに想像したのですが如何でしょうか？(実際、「テストを先に書く」＝「クライアント側の使い方を先に考えて、実装コードは後に書く」というのは昔から使われていたテクニックのようですので技法としては昔からのもののようです)
・・・そう、テンポ・・・つまりリズムですよ！・・・多分。
xUnitを使ってテストコードを書くなんて、きっと「おまけ」みたいなものなんですよ！・・・多分。
テストコードを書くのはあくまでも「リズム感」「テンポ」を維持する為のものなんですよ！・・・多分。
こうして「多分」を三つほど重ねた上で、でっち上げてみました！名付けて「リズム駆動開発(Rhythm-Driven-Development)」！！
ごめんなさい・・・！！真面目に最前線でTDDやBDDの議論をしている皆さん、本当にごめんなさい・・・。
一応、自分の5年間に渡る雑多なシステム開発の経験をベースに書いてみました。メーカー(工場内)のシステムや決済情報の中継システムなどに主に携わっていたのですが・・・ご想像の通り、「ガチガチのウォーターフォール開発」です、ええ。
でもですね・・・それでも、自分なりに「テンポ良く」コーディング出来てたな〜とは思うのです。
何でだろう・・・と振り返ると、やっぱり、テストコードこそ書いたりはしませんでしたが、「細かくコーディングして、頻繁に動作確認」を繰り返していたからではないかな〜と思うのです。
自分の場合はJavaの担当が多く、結構自分一人で好きなテンポで作れる環境があったので、こうしたやり方で殆ど通してきました。
ところがですね、隣のC言語のチームとかを見ると、「コードを100%書ききるまで実行しない」「実行するのはテスト仕様書に基づくテスト作業から」というのが一般的だったんです。まぁ生産性やバグ密度は自分のJavaも、隣のCもどっこいどっこいであんまり変わらなかったんですが、それでも「ノリの良さ」というのはやっぱり違った気がします。
あるいは・・・別の現場の話ですが、「完成しました〜」と手渡されたJavaコード。「コンパイルは通ったけど一度も実行していなかった」・・・動かしてみたら正常系すらまともに動作しない(泣)。そう、そのプログラマにとっては、「コーディング完了 ＝ コンパイル完了」で、動作確認はテストフェーズという意識だったんですね。
だから一番の目的は「リズミカルに開発することで、生産性を向上させる」、コレではないかな〜と思うんです。
で、リズムさえ整えられれば、別にTDDを使わなくても良いんではないかな〜とも思った次第です。
TDDでもテストコードを書いて自動化するのが難しい部分があるじゃないですか。並行/並列処理、非同期I/O、通信、ハードウェア制御。そうした部分のテストコードを書こうとして何時間も頭を悩ませたりライブラリを探すのは「リズム感」を崩してしまう。
それならいっそ、「ここは自動化テストに組み込むのが難しいので、まぁ手動で従来通りテストでも良いんじゃない？」と妥協しても良いんじゃないかなーと。
従来通りの手動によるテストでも、リズム感さえ保てればそれでOKじゃね？というのがRDDの妥協案です。
RDDの詳細は、前掲の個人のBlogエントリにまとめてあります。こちらではRDDを思いついたmsakamoto-sfの背景や、妥協の産物としてのRDDの要点をまとめてみました。
半分はネタですが、半分は本気です。
