書いたコードの量が増えれば、増えるほど、比例してバグが増えていきます。
予期せぬバグはスケジュールに致命的な影響を与える。
手を加えたソースの量が増えてからバグを特定するのには多くの時間や労力を費やすことになります。
 |
アンドリュー ハント￥ 3,990
 |
達人プログラマーはどうするのか？
p.241 第8章 達人のプロジェクトより
早めにテスト、何度もテスト、自動でテスト
書いたコードが少ない段階で、少ないテストをして、小さなバグをできるだけ早く解決していく。製品コードとテストコードを同時に書いていくのです。仮にバグを埋め込んでしまったとしても、バグになっている箇所はすぐに特定できるでしょう。
このテストをあながた手を動かしてやっている暇はありません。
あなたは新たなバグを埋め込むために製品コードを書かなければなりません。絶対に自動化しましょう。
自動化してテストを何度も、何度も、繰り返しおこなえるようにしましょう。結合テストも含めて、絶え間ない結合化と容赦ないテストを実施しましょう。チームのルールとして、バージョン管理システムにコミットする前にはテストをしましょう。
こうすることにより、できる限りバグの少ない製品コードがつくられていきます。あなたが担当する部分を「できた！」といえるときは、テストコードが存在してすべてのテストが通過しおり、仕様通りに動作していることなのです。
もう一度伝えます。絶え間ない結合化と容赦ないテストを実施しましょう。優れたプロダクトのソースコードは、製品コードよりもテストコードの方が多いのです。
HIROCASTERの経験から
テストコードは絶対に書くべき。そして、できればテストファーストでプロダクトコードを書くべき。ハッキリ言って、こういったアプローチをとらないと、スケジュールの途中で大きなバグが見つかったり、リリース後にバグが見つかったりして、バグという不具合と予期せぬスケジュールの変更と同時に戦うことになる。
そして、外野からのプレッシャーを受けてチームは疲弊していく。そして、デスマーチへ…。
このアプローチをとったチームは、スケジュールが安定する。書いたプロダクトコードには大量のテストをパスしているという保証があるので、自信を持ってデプロイやリリースができる。これは非常に精神衛生上良い。リリース日が迫って、胃を痛くする日々は無くなる。メンタルは生産性に影響する。
達人プログラマーへの質問：テストコードを書けば、書くコードの量が増え工数が増えない？
そんなことはない。
１．スキルのレベルにかかわらず、プログラマーは全時間のおよそ１０～２０％をコードを書くのにあてており、たいていのプログラマーは完成品ができるまで一日あたりおよそ１０～１２行のコードを書いています。優秀なプログラマーは残りの９０％のうち大部分を、考えること・調べること・最高の設計を見つけるための検証作業に費やします。ダメなプログラマーは残りの９０％のうち大部分を、やみくもに変更と検証を繰り返すようなデバッグ作業に費やします。
90%のやみくもに変更と検証を繰り返す時間がへるのだ。むしろ、生産性はあがる。プロダクトコードよりテストコードの方が量は増えていくが、テストコードは簡潔であるケースが多く、サクッと書いていける。90％の余計なことがなくなって、エレガントなプロダクトコードを生産することに集中できるのである。
あなたは今年、どれだけテストコードを書きましたか？
 |
アンドリュー ハント、デビッド トーマス、Andrew Hunt、David Thomas、村上 雅章 |
 |
ケント ベック￥ 3,150
 |
 |
Christian Johansen、長尾高弘 |
 |
ポール・M・デュバル￥ 3,360
 |
 |
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化 David Farley、Jez Humble、和智 右桂、高木 正弘 |
