Code Complete１人読書会その１

早速ですが第１回目。

　皮肉なことに、コンストラクションは焦点が当てられていないにもかかわらず、実行されることが保証されている唯一のアクティビティである。要求は策定されるのではなく想定される可能性があるし、アーキテクチャは設計されずにうやむやにされる可能性がある。テストは十分に計画されてから実行されるのではなく、短縮されたり省略されたりすることがある。だが、プログラムが存在する限り、コンストラクションは必ず実行される。したがって、コンストラクションは開発プラクティスを改善するうえで、ほかに類を見ないほど実り多い領域なのである。
《Code Complete 第2版上, 2005/03/28, 日経BPソフトプレス, はじめに(27)》より

なるほどそういう視点がありましたか。なんか新鮮。確かに設計やらテストやらは省こうとすれば省けちゃうもんね*1。
最近だと、どんどん著者の言うコンストラクション自体も行わない方向性になりつつあるので、未来永劫この考え方ってわけにもいかないんだろうけど、少なくとも後５年ぐらいはなくならなそうだもんね。きっと。

　プロのプログラマならばだれでも準備の重要性を認識していて、コンストラクションを急がずに準備が整っていることを確認することくらい知っていると思うかもしれない。残念ながら、実際はそうではない。
　準備が不十分になる一般的な原因は、上流の作業を担当する開発者が、与えられた仕事をこなすための専門知識を持っていないことである。プロジェクトを計画する、説得力のある業務分析を行う、包括的で正確な要求を開発する、高品質なアーキテクチャを作成する、といったスキルは、並大抵のものではない。だが、ほとんどの開発者は、これらを実行する方法について訓練を受けていない。開発者が上流の作業を行う方法を知らないとしたら、「上流の作業を増やす」というアドバイスは無意味である。そもそも作業がきちんと行われないとしたら、それを増やしたところで意味がない。
《Code Complete 第2版上, 2005/03/28, 日経BPソフトプレス, p.30》より

ぐさっ。
自分のことを言われてるようでアイタタな感じ。専門知識を持っていないことを言い訳にしちゃ駄目なんだけどね。

と言ったところで１人読書会、今日はおひらき。

*1:省くことの良し悪し自体は、もちろん別の話。