失敗を想定しろ

ソフトウェア開発において、大事なことは「失敗すること」を理解すること。

システムコンセプトないし新技術が使用される場合、システム一つは駄目にするつもりで作成しなければならない。というのは、最高のプランニングでさえも、一回目で成功するほどには計算し尽くされていないからである。 - p106

不変なものは、変化そのものだけである - p107

ソフトウェア開発の世界では、今だに日進月歩で新しい技術が開発されています。もちろんそのような新しい技術は使用経験もないため、うまく予測もできなく、失敗へとつながっていきます。いまだに失敗プロジェクトが多数ある現状を考えると、この失敗はそうそうなくなるものでもないようですね。

大事なのは、「失敗しない」ことではなく、「失敗することを想定しておく」こと。

生産性を上げるツール

本書では生産性を上げるものとして、多数のツールが挙げられています。その中でも特に現在成功しているものは「高水準言語」でしょう。

高水準言語を使うおもな理由は、生産性とデバッグのスピードである。
<中略>
定量的に実証する例は多くはないが、単なる足し算的割合ではなく、積分的な向上がそこには見てとれる - p123

さらには、それに付随するデバッガなんかの高性能化もあり、非常にプログラミングそのものの生産性は上がっているように感じます。

必要な文書

良い文書というのは良いプログラミング並に必要であるということは、いろいろなところで言われています。この本ではさらに、「必要のない文書」にまで踏み込まれています。具体的には「フローチャート」。

フローチャートは、プログラム文書作成のうちで全く過大評価されてきたものの一つだ。多くのプログラマはフローチャートを全然必要としないのだ。何しろフローチャートが一ページ以上必要になるプログラムはほとんどないのだから。 - p155

このように、「必要だ、必要だ」というだけでなく、「これは必要ない」と言ってくれるのも本書の面白い点かと。とは言っても、本書も基本的には文書化は必要だということ。人のプログラムを読んでいても、ドキュメントが付いているか付いていないかで、読みやすさが圧倒的に変わるので、僕的には大賛成ですね。

次回

今回は取り留めのない内容でしたが、次回はこの本の副題にもなっている「銀の弾などない」という話です。この本で最も言いたかった部分ではないかと。