kidoOooOoooOOom

IT系で開発やってます

ソフトウェア開発の食物連鎖 〜Code Complete 上巻 読書メモ〜

コードコンプリート上巻を読んでいて面白いと思ったメタファがあったのでメモしておきます。

CODE COMPLETE 第2版 上

CODE COMPLETE 第2版 上

プログラマはソフトウェアの食物連鎖の末端にいる。アーキテクトは要求を取り込み、設計者はアーキテクチャを取り込む。そして、プログラマは設計を取り込む。
生態学的に健全な環境では、カモメは新鮮な鮭を食べる。酒は新鮮なニシンを食べ、ニシンは新鮮な水中昆虫を食べているので、カモメは鮭を食べて栄養分を得る。その結果、健全な食物連鎖が生じる。プログラミングでは、食物連鎖の各段階に健康に良い食物があると、幸せなプログラマによって書かれた健全なコードが得られる。
汚染された環境では、水生昆虫は放射性廃棄物の中を泳ぎ、ニシンはPCBによって汚染され、ニシンを食べる鮭は海上に流出した石油にまみれて泳ぐ。カモメは不運にも食物連鎖の末端にるので、汚染された鮭から石油を摂取するだけでなく、ニシンのPCBや水生昆虫の放射性廃棄物まで摂取してしまう。プログラミングでは、要求が汚染されると、それらによってアーキテクチャが汚染され、アーキテクチャによってコンストラクションが汚染される。こうして、栄養不足の不機嫌なプログラマと、放射能に汚染された欠陥だらけのソフトウェアが生じることになる。

ウォーターフォール型開発では基本的に後戻りをしないため、上流が汚染されていると最後までその汚染を引きずることになりかねません。それに対し、イテレーション型開発では少しずつ全体の汚染を取り除いていくスタイルであるため、上流での汚染のリスクが軽減されることが期待されます。


ウォータフォール型(逐次型)か、イテレーション型(反復型)のどちらを選択すべきかはソフトウェアの種類やプロジェクトの形式、メンバーのスキルなどによって異なります。
下記のような場合には、より逐次性の高い(事前に準備を済ませる)手法を選択した方が良いと考えられています。

  • ウォータフォール型(逐次型)が適している例
    • 要求がかなり安定している
    • 設計が比較的単純で、かなり理解されている
    • 開発チームがそのアプリケーション分野に精通している
    • プロジェクトのリスクが低い
    • 長期的な予測が風要である
    • 要求、設計、コードを下流で変更すると、高くつく可能性がある

一方、次の場合には、反復型(作業を進めながら作業する)手法を選択した方が良いと考えられています。

  • イテレーション型(反復型)が適している例
    • 要求が十分に理解されていない、あるいは他の理由により要求が変化しやすいことが予想される
    • 設計が複雑である、手間がかかる、あるいはその両方である
    • 開発チームがそのアプリケーション分野をよく知らない
    • プロジェクトのリスクが高い
    • 長期的な予測は重要でない
    • 要求、設計、コードを下流で変更しても、安価な可能性がある


現在のスピード感あふれるソフトウェア開発の潮流を考慮すると、反復型の方が開発スタイルとして適していそうですね。

反復型開発 Wilipedia