A Philosophy of Software Design ch21 Conclusion

APoSDソフトウェア設計勉強メモ

出典: 


Conslusion

  • 本書のテーマはひとつ: 複雑性
  • 複雑性に取り組むことは、ソフトウェア設計における最も重要な仕事である
  • 複雑なソフトウェアは…

    • 構築・保守しづらい
    • 実行時速度が遅いことさえある
  • 複雑性の原因について述べた:

    • 依存
    • 不明瞭
  • 不必要な複雑性を特定するための危険信号も挙げた:

    • 知識の漏出
    • 本来無くて良い例外フロー
    • 名前が汎用的すぎ
    • etc.
  • 単純なソフトウェアシステムを作るための一般論も示した:

    • 深くて汎用なクラスを追求する
    • 例外をそもそも定義しない
    • インタフェースのドキュメンテーションと実装のドキュメンテーションとを分離する
  • 単純な設計を生むために必要な、投資の姿勢についても論じた
  • これら共通の欠点: プロジェクト早期に余計の工数を生ずること

    • 設計の問題について考え慣れていないと、設計テクニックを学習するのにも時間がかかり、開発が遅くなる
    • 可能な限り早く、今取り掛かっているコードを動かしたいだけならば、設計について考えることは、目標の達成の邪魔になる骨の折れる仕事に感じられるだろう
  • 設計があなたにとって重要な目標ならば、本書のアイデアによって、プログラミングが楽しくなるはず
  • 設計は魅力的なパズルである

    • 特定の問題をいかにして可能な限り単純な構造で解決するか?
    • 異なるアプローチを探るのは楽しい
    • 単純かつパワフルな解法を見つかるととても気分が良い
    • 綺麗でシンプルで理解しやすい設計は美しいものである
  • 良い設計のための投資はすぐに元を取れる

    • プロジェクト初頭に注意深く定義したモジュールは、あとで再利用され時間を短縮してくれる
    • 6ヶ月前に書いた明快なドキュメントは、今日そのコードに戻ってきて新機能を追加する際に時間を短縮してくれる
  • 設計スキルを磨くのに費やした時間もまた、それ自体元を取れる

    • 良い設計をより素早く生み出せるようになる
    • ひとたびやり方が分かれば、「良い設計」は、「速くて汚い設計」と比べてもそれほど時間がかからない
  • 良い設計者であることへのご褒美

    • 多くの時間を楽しい設計に割ける
    • cf. 良くない設計者は、多くの時間を壊れやすいコードの不具合修正に費やす
    • 設計スキルを磨くことで、高品質のソフトウェアを素早く提供できるようになるのみならず、ソフトウェア開発がより楽しくなるのである