書籍 プリンシプルオブプログラミング 第1章 まとめ

前提 ~プログラミングの変わらぬ真実~

1.1 プログラミングに銀の弾丸はない

ソフトウェアは本質的に困難

プログラミングの成果物である「ソフトウェア」は、本質的に以下の4つの性質を持っている。

  • 複雑性

ソフトウェアの構成は、規模が大きくなるにつれて非線形に増大していく

  • 同調性

ハードウェアやネットワーク、他のソフトウェアなどと同調し続けなければならない

  • 可変性

ユーザの要求に対し、変化をし続ける必要がある

  • 不可視性

ソフトウェアは概念の集積であり、実物やプロセスを見ることはできない。見れるのはせいぜい抽象化された図面くらい

これらは本質的に取り除けないものであり、すべてを確実に解決するような特効薬は存在しない

ソフトウェアの偶有部分の改善

偶有とは、付随的でそれがなくても物事が成り立つという性質のことであり、ソフトウェア開発における、ビルド環境、言語、ライブラリ、フレームワークなどといったことである。 例えば、フレームワークは無くても開発は出来るが、利用できれば開発効率の向上が期待できる。

偶有的な部分を最適化したり作業を自動化することで、より多くのリソースを本質的なことに割ける。

1.2 コードは設計図である

ソフトウェア開発においては、上流から下流の全ての作業が『設計』であり、そのアウトプットが『コード(設計図)』になる。 (UMLやCASEツールはあくまで補助)

そのためプログラミングによってコードが完成しなければ、それより上位の設計も確定されない。

コードを早めに書き始めることで、設計の明確化して早めに設計を終わらせることが出来る。

保守においては、ソフトウェアの開発環境やアーキテクチャを理解するための『ロゼッタストーン』というドキュメントが重要になる。

主にビルドやテストのプロセス、コードからは読み取れない全体像などを記述することで、後任の保守担当者が躓きにくくなる。

これに「何故この仕様にしたか」といった記述をすることで、保守担当者の修正材料として役に立つ。

1.3 コードは必ず変更される

コードは修正や機能の拡張などによって必ず修正や変更が行われるため、変更されることを前提にコードを作成すべきである。

そのため、読みやすいコードを記述することがが最も重要 (変更時に読む時間を短縮できる)