Conslusion
- 本書のテーマはひとつ: 複雑性
- 複雑性に取り組むことは、ソフトウェア設計における最も重要な仕事である
-
複雑なソフトウェアは…
- 構築・保守しづらい
- 実行時速度が遅いことさえある
-
複雑性の原因について述べた:
- 依存
- 不明瞭
-
不必要な複雑性を特定するための危険信号も挙げた:
- 知識の漏出
- 本来無くて良い例外フロー
- 名前が汎用的すぎ
- etc.
-
単純なソフトウェアシステムを作るための一般論も示した:
- 深くて汎用なクラスを追求する
- 例外をそもそも定義しない
- インタフェースのドキュメンテーションと実装のドキュメンテーションとを分離する
- 単純な設計を生むために必要な、投資の姿勢についても論じた
-
これら共通の欠点: プロジェクト早期に余計の工数を生ずること
- 設計の問題について考え慣れていないと、設計テクニックを学習するのにも時間がかかり、開発が遅くなる
- 可能な限り早く、今取り掛かっているコードを動かしたいだけならば、設計について考えることは、目標の達成の邪魔になる骨の折れる仕事に感じられるだろう
- 設計があなたにとって重要な目標ならば、本書のアイデアによって、プログラミングが楽しくなるはず
-
設計は魅力的なパズルである
- 特定の問題をいかにして可能な限り単純な構造で解決するか?
- 異なるアプローチを探るのは楽しい
- 単純かつパワフルな解法を見つかるととても気分が良い
- 綺麗でシンプルで理解しやすい設計は美しいものである
-
良い設計のための投資はすぐに元を取れる
- プロジェクト初頭に注意深く定義したモジュールは、あとで再利用され時間を短縮してくれる
- 6ヶ月前に書いた明快なドキュメントは、今日そのコードに戻ってきて新機能を追加する際に時間を短縮してくれる
-
設計スキルを磨くのに費やした時間もまた、それ自体元を取れる
- 良い設計をより素早く生み出せるようになる
- ひとたびやり方が分かれば、「良い設計」は、「速くて汚い設計」と比べてもそれほど時間がかからない
-
良い設計者であることへのご褒美
- 多くの時間を楽しい設計に割ける
- cf. 良くない設計者は、多くの時間を壊れやすいコードの不具合修正に費やす
- 設計スキルを磨くことで、高品質のソフトウェアを素早く提供できるようになるのみならず、ソフトウェア開発がより楽しくなるのである