コード・シンプリシティ
コードを管理してく上では複雑性が問題となる。その為には簡潔でなくてはならない。
まえがき
- Bugzillaというコードが汚いことで有名なプロジェクトがあった
- 放り出すことも出来たがたくさんのユーザを無視することは出来なかった
- 新しく作り直す欲求を抑えて、既存のコードを機能毎に修正していく改善を繰り返した
- 結果うまくいき今までの2倍の速さ、1/4の人数で新機能の追加ができるようになっていた
- 「ソフトウェアの世界では意見がおおく、事実(fact)がたりなすぎる」
- この本に書かれていることは事実である
良いプログラマーと悪いプログラマーの違いは理解力
- 自分が今何をしているのかをきちんと理解することで見える世界が変わってくる
第1章 はじめに
なぜ簡潔が必要なのか
- 「ソフトウェアにはバグがつきものだ」という考えに慣れすぎた
- それは肥大化していき、最後には作りなおすしかないというように思われている
- でも本来はそうではない
- 問題は複雑性
- 頭の中では把握できないほどにおおきなる。そういうもの。
- 実際に使えるシステムはそういうもの。
- プログラミングは複雑性をそぎ落として簡潔性を導かなければならない
- 新しい技術は、コードの量が増えてはいけないということではない。
- 簡潔性、読みやすさを重視するためにたくさんコードを書くこともある
人が読めるように、メンテナンスできるように簡潔にする必要がある。 複雑なものは管理できなくなる。
ソフトウェアデザイン
- ソフトウェアを書く人は誰でもデザイナ
- コードのデザインの責任は実際に作業をしている者がもつべきである
第2章 なぜソフトウェアをつくるのか
人を助けるため。
- 「金を作ること」でも「知性をひけらかすこと」でもない
- 金儲けは、個人、組織の目的だが、ソフトウェアが存在する目的ではない
- なので「これはどのようにユーザの役に立つのか」というのはとても良い質問
実際のアプリケーション
- 作成するソフトウェアの目的を決める
- そうると必然的に優先度が決まり、いらないものは削除される
- 誰にとって何が便利なのかを常に考えること
- より重要なものがみえてくる
- 機能が肥大化した場合でも、このことを考えることで削除すべき機能が見えてくる
第3章 未来
ソフトウェアの価値方式は
欲求度(Desirability)=変更の価値(Value)/作業量(Effort)
で計算できる。
- 僅かな作業量で多くの価値をもたらすものは、多くの作業量が必要で価値が引いものよりは効率的 * 「今」ではなく「未来」に対して最適な答えを求めること
- でも未来は不確定なものでもある
第4章 変更
- いらない変更はしない
- 必要以上に一般的(汎用性の高い)なコードにする必要はない
- かといってまったく拡張性がないのも困りモノ
第5章 不具合とデザイン
- プログラムに不具合を作ってしまう確率は、そのプログラムに加える変更の大きさに比例する
- ソフトウェアは変化するものだが、変化することで不具合が生まれる矛盾
- 最高のデザインとは、環境の変化に最大限対応しながらもソフトウェア事態の変更は最小にするものである
- 早すぎる最適化は悪
- プログラム上での動作スピードに気をつけるべきなのは、実際にユーザにとってパフォーマンスの問題が出たとき
第6章 簡潔性
- どのようなソフトウェアも、その管理のしやすさは個々の部分の簡潔性に比例する
- シンプルであることが管理しやすく、変更しやすい
- どこまでシンプルにするか
- アホでも分かる程度
- 一貫性を保つ
- 簡潔性の大部分を占めるのは一貫性
- 読みやすさ
- 名前の付け方
- コメント
- 簡潔性にはデザインも必要
第7章 複雑性
- 要望に対して開発が追いつかなくてなってくる
- 複雑性が原因
- 要件が複雑すぎて最初のバージョンを永遠にだせない
- 機能を絞ること
- 複雑性を増す要因
- ソフトウェアの役割を拡大する
- 開発者を増員する
- 変更する必要のないものを変更する
- 間違った技術にロックインする
- 誤解
- 邪悪なデザイン、あるいはデザインがまったくない
- プログラムの目的を明確にする、複数の目的を持たないことで、複雑性がなくなる
- 間違った技術を使う
- 生き残る確率の低いものは使ってはいけない
第8章 テスト
- テストがなければ動作を保証できない