The King's Museum

ソフトウェアエンジニアのブログ。

Chapter2. A Pragmatic Approach【The Pragmatic Programmer】

Pragmatic Programmer の Chapter 2. A Pragmatic Approach を読んだ。

内容は次の通り。

  • 7 The Evils of Duplication
  • 8 Orthogonality
  • 9 Reversibility
  • 10 Tracer Bullets
  • 11 Prototypes and Post-it Notes
  • 12 Domain Languages
  • 13 Estimating

曳光弾開発とプロトタイプ開発の違いについての話は興味深かった。

Tracer Bullets と Prototypes

モジュールごとではなく、システムを貫通するように機能を中心に作ることを曳光弾開発という。この言葉は前から知っていた。プロトタイプ開発と曳光弾開発と何が違うのか?

プロトタイプ開発はあくまでプロトタイプ。製品リリースに向けてコード自体を1から書き直す前提。プロトタイプのコードをベースにして開発を進めてはいけない。

一方、曳光弾開発は製品レベルのコードで一部の機能を実装する。実装したコードは作り直すことがなくほぼそのまま製品として利用できる。この点が大きな違い。

プログラムとプログラム製品

『人月の神話』に『プログラム』と『プログラム製品』の違い、という話がある。

『プログラム』を作るのにはそれほどコストはかからない。それは単一の環境で、簡単なデータの組み合わせに関して動作すれば良いものだから。エースプログラマが徹夜して数日で『プログラム』を作り上げた、なんて話はよく聞くだろう。

でも、多様な環境で動作して、様々なデータに対応した『プログラム製品』にするには『プログラム』を作る3倍のコストがかかる。というのが『人月の神話』に書かれた話。加えて『プログラム』を、コンポーネントに分離された拡張可能な『プログラムシステム』(フレームワークとか OS に該当)にするには 3 倍のコストがかかり、もし『プログラム』を『プログラムシステム製品』にするなら 9 倍のコストがかかる。

プロトタイプの危険性

プロトタイプを作るということは『プログラム』を作ることであって、決して『プログラム製品』を作っているわけではない。プロトタイプができてもリリースまでにはさらに数倍のコストがかかる。

プロトタイプをマネージャーや経営陣に見せる時は注意が必要だ、と Pragmatic Programmer には書かれている。

動くものがあると、リリースはすぐそこだと勘違いしてしまいやすい。『プログラム』を『プログラム製品』にするには3倍のコストがかかるという事実を忘れてしまう。

それを防ぐため、正しい情報を伝えるのもエンジニアの役目なのだろう。

(c) The King's Museum