ジョエル・テストを読んだ
上記エントリと関連して、読みたいな、読まなくては、と思っている IT/Programming の 本/文章 がたーんとある。
これもまた、ちょこちょこ読んでいこうと思う。
ジョエル・テストは読んだことがあったけど、もう一度読んでみた。
ジョエル・テストは以下の質問に Yes/No で答える。Yesなら1点になる。
ジョエル・テスト
- バージョン管理システムを使っているか？
- １オペレーションでビルドを行えるか？
- 毎日ビルドを行っているか？
- バグトラッキングシステムを持っているか？
- 新しいコードを書くまえにバグを修正しているか？
- 更新可能なスケジュール表を持っているか？
- 仕様書を持っているか？
- プログラマは静かな労働環境にあるか？
- 買える範囲で一番良い開発ツールを使っているか？
- テスト担当者はいるか？
- プログラマを採用するときにコードを書かせるか？
- 「廊下でユーザビリティテスト」を行っているか？
＜中略＞
ジョエル・テスト - The Joel on Software Translation Project
12点なら完璧、11点でも許容範囲内だ。だが、10点以下だったら、君のプロジェクトは深刻な問題を抱えているといえるだろう。実際のところ、大半のソフトウェア開発組織は 2点か 3点の状態で仕事をしている。そして、彼らは切実に助けを必要としている。なぜなら、マイクロソフトのような会社は常に 12点の状態でいるのだから。
これだけでも十分学ぶところがあるのだが(残念ながらと言うべきか…)、読み進めるとよい文章がたくさんある。
たくさんあるので、いちばんすきな部分だけ引用する、
実際のところ、「欠点０」とは、常にすべてのバグを修正するまではいかなる新しいコードも書いてはならない、という意味だった。以下がその理由だ。
一般的に、時間が経てば経つほど、バグを直すのにかかるコスト（時間とお金）は増える。
ジョエル・テスト - The Joel on Software Translation Project
例えば、コンパイル時にタイプか文法エラーが出たら、それを直すのはごく当たり前のことだ。
バグを抱えていて、プログラムを動かそうとした最初のときに見つけたとする。君はわけなく直せるだろう。なぜなら、君の頭の中でそのコードはまだ新鮮だからだ。
＜中略＞
でも、２，３ヶ月前に書いたコードの中のバグについては、君はそのコードについて多くを忘れているだろう。
＜中略＞
そして、すでに出荷されたコードのバグを見つけたら、それを直すには途方も無いコストを招くだろう。
コードを書いたことのある人なら、だれでも同じ思いではないだろうか。
実装中にコンパイルエラーがでたら、すぐに直せる。当たり前だ。
それがすでにリリースされたコードなら、いろんなドキュメントを修正して、障害管理して、いろいろな申請が必要なる。
必要となる手続きが圧倒的に増えてしまう。
バグがでるというのは、当たり前のこと。
だからこそ、さくっと直せるのなら、さくっと直しておきたいと思う。
