Kanazawa.process に参加しました

今回はid:katzchang主催によるTDDの読書会です。ターゲットとなる本はケントベッックのテスト駆動開発入門です。進行はid:Nagiseid:shozzyによる写経です。
本の写経なので音読したりライブコーディングを行いながら進んでいくのですが、ケントベックの文学的な言い回し(美だの罪だの勇気だの)によって、笑いの絶えない場になりました。部屋の大きさもちょうど良く、他の参加者との距離感もよく、話しやすく聞きやすい環境でした。
まずこの本を読む前に前提となる知識が必要となります。それは、リファクタリングデザインパターン・不変、可変オブジェクト・ユニットテストなど。じゃないとケントベックの独特な言い回しについていけません。可変オブジェクトのことを副作用があると表現されてますからね。
ここでは参加者と議論しこの本において大切だと感じたことを書いておきます。全体を知りたい方は、議事録がこちらにあります。→はてなグループ

■TDDにおける手順

まずはインターフェースを決めてテストを書き、コンパイルが通らないところからスタートです。そして次に行うべきことは、そのテストを通すということです。単に通せばいいのです(戦略として仮実装*1と明白な実装*2がある)。その後のリファクタリングの過程で重複を取り除いたりすることになります。

■TDDにおけるテストは品質を保証するためのものではない

一般的にテストというと品質を保つために行うものですが、TDDはあくまでプログラムを駆動させるために行うものです。プログラムを順番に組み立てるために使う手法です。それが結果的に品質を保証するものになるかもしれませんが、それが第一義ではありません。

■これからやろうとすることを徹底的に書き出す

例えばあるテストをしなければならないと気が付いたら、必ずTODOに書き出してからテストの変更を行います。それが頭の中で瞬時に解決できる問題であってもです。


この辺りがこれまで開発してきた経験と比べて気になった点です。まだ1/4しか終わっていないのでTDDの本質について、さらに掘り下げた議論になりそうです。


ここからは横道です。id:NagiseさんがEclipseをベタ褒めだったw Visual Studioもそんなに悪くないですよ!

統合開発環境について

id:Nagiseさんの言う通り、最近の統合開発環境(Eclipse)を利用すれば、静的な解析が進んでいるので、コードを補完してくれたりエラーの箇所を指摘してくれるのでコンパイルして動かす前にコードの正しさが分かるため、コンパイルしてエラーをチェックする必要がなくなる分だけ、開発スピードは上がっていると思います。さらに強力なリファクタリング機能が付いているのでソースコードの変更はほぼ機械的に行えるし、コンンパイルも一瞬で済んでしまうので、そういう無駄なところに時間がかからなくなって本来考えなければならない問題のみに当てる時間が増えていると思います。
スクリプト言語と比較しても、サクサク感という面で、統合開発環境も含めてしまえば、スクリプトが有利であることを全面に出すにはもう弱いと思います。

■mutable(可変)とimmutable(不変)

基本的な設計はimmutableが良いという話。途中で変えることができてしまうとこの本の通り、副作用が起こる危険性が伴います。特にマルチスレッドな処理を行うと変数の不変性を保証できなければどこで変わるか分からなくなるので非常に危険。
この辺は個人的にもうちょっと勉強が必要。コレクションなどを頻繁にコピーしたときのコスト(スピード)が気になる。



と、まぁいろんな経験ができました。自分が参加する立場になると聴衆者とは違ったものが得られますね。いろんな人のいろんな体験を聞けるのは非常に貴重な機会だと思います。次回を楽しみに、そして自分も体験してきたことを話せればいいなぁ。

*1:定数を返し、本物のコードを得るまで、定数を変数で徐々に置き換えること p13

*2:実際の実装を記述すること p13