Entries

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
この記事にトラックバックする(FC2ブログユーザー)
http://exphenomenologist.blog100.fc2.com/tb.php/292-4fc73ddf

トラックバック

コメント

コメントの投稿

コメントの投稿
管理者にだけ表示を許可する

フレデリック・ブルックスJr.『人月の神話』

人月の神話―狼人間を撃つ銀の弾はない (Professional Computing Series)人月の神話―狼人間を撃つ銀の弾はない (Professional Computing Series)
(1996/02)
フレデリック・P,Jr. ブルックス

商品詳細を見る


原著1975年。この変化の激しいプログラミング業界でいまだに読むに耐える古典は珍しい。もちろん、いまとなっては通用しない箇所はたくさんある。貴重なCPU時間やメモリをどうテストに振り分けるかという問題や、PL/Iに関する話など。だがこの本の主要テーゼは鋭く、いまだに検討に値する。

人月の神話はこの本以来、よく知られている。スケジュールの遅延に対して時期を延ばす(月の追加)のと、人を追加するのは等価ではない。人を投入する場合、その新たな人に教育が必要だし、他の人とのコミュニケーションで余計な時間がかかる(p.14)。これは確かにそうだ。だが見積りでは人月がいまだに使われるし、開発量についての人月に代わる基準はどれだけあるだろうか。人月の見積りを出すとき、たいがい人か月どちらかは投入できる最大限が決まっていることが多いのでは。3人月と言ったとき、たいがい3人で1ヶ月か、1人で3ヶ月か見積り者の頭に浮かんでいるものだ。自分の考えではむしろ、人月で見積りを出すことで隠されてしまうのは、個々の作業者の力量だ。IT系では個々の作業者の力量差があまりに大きいために、単なる人月では捉えられなくなる。本書にもそのことは触れられてはいるが。

また銀の弾の話もよく知られている。ソフトウェア構築において何よりも重要なのは、詳細設計まででいかに仕様を詰めて、要件を概念化するかだ。概念化、デザイン、そしてそのテストが本質であって、それをいかに表現するか(どんなコードを書くか)は偶有的な事柄である(p.168)。概念化のなかでもアーキテクチャが大事で、他の過程をそれに従わせる貴族政治を取るべきだ(p.38ff)とも。そしてソフトウェア業界の発展はたいがい、後者の偶有性の改善であって、本質部分の改善では既存パッケージの導入で人月を省く、といったことしかない。確かに。著者はプログラミングはプロジェクト全体の1/6だというが、感覚的にうなずける。

また、プログラムは構築するものではなく育てるものだ(p.187,258)という。建築やモノ作りの比喩から、生物の比喩へ。これが意味するのはプロトタイプモデルだ。でもいまだにモノ作りの比喩が強い。アジャイルとかはどうだろう。

プログラムのメンテナンスは、欠陥の修正をするとそれが別の欠陥を生み出す可能性があって、二歩前進して一歩後退することがあるという話(p.112)も身につまされる。個人的にもアドホックな修正でごちゃごちゃになったプログラムに、さらにアドホックな修正を加えたこないだばかり。次の文言が名言だ。
プログラムメンテナンスはエントロピーが増加する過程であり、どんなに器用に行っても、できるのはシステムが修正不能な陳腐化へと沈んでいくのを遅らせることだけである。(p.113)
スポンサーサイト
この記事にトラックバックする(FC2ブログユーザー)
http://exphenomenologist.blog100.fc2.com/tb.php/292-4fc73ddf

トラックバック

コメント

コメントの投稿

コメントの投稿
管理者にだけ表示を許可する

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。