A Philosophy of Software Design の16章 ~ 20章を読んだので忘備録としてまとめていきます。
A Philosophy of Software Design
- 作者:Ousterhout, John
- 発売日: 2018/04/06
- メディア: ペーパーバック
- 16章 Modifying Existing Code
- 17章 Consistency
- 18章 Code should be obvious
- 19章 Software trends
- 20章 Designing for performance
16章 Modifying Existing Code
最初の設計の出来よりも、その後システムがどのように修正されるかによってシステム全体の複雑さが決まっていく
既存のコードを修正するときに、修正範囲が増える事を恐れて、なるべく少ない修正をしようとするのは間違い。
コードの近くにコメントを書く。コードから離れれば離れるほどコメントを抽象的にする。
外部モジュールの詳細についてコメントとして書くべきではない。外部でドキュメント化されているなら、外部のドキュメントのリンクを書く。
17章 Consistency
一貫性のある設計 ⇨開発者がシステムを容易に理解できる⇨時間と労力の削減
一貫性の種類
- 名前
- コードの形式
- インターフェース
- デザインパターン
- 不変条件
一貫性を実現するために
- ドキュメントを書く
- lintを入れる
- 既存のコードに合わせる
- 既存のルールを変更しない
- コード規約を導入する
- 冗長な処理を見つける
- コードレビューで教育する
18章 Code should be obvious
わかりやすいコードを作るテクニック
- いい名前をつけること
- 一貫性のあるコードを書くこと
- 空白や空行を使ってまとまりを作ること
- コメントを使って情報を補うこと
わかりづらいコードが生まれる要素
19章 Software trends
実装と継承によってコードを明確にする。
継承は、親クラスのメソッドやフィールドを子クラスが利用できるので、親クラスと子クラスで依存関係が生まれる。
良い設計を実装する手助けはしてくれるが、OOPを使っているからといっていい設計になるわけではない。
アジャイル開発
incrementalでiterativeな開発によって小さい改善を繰り返すことで、シンプルな設計を作り出すことができる
動くものを作るという考えがあるためtactical programmingになってしまうことがある
TDD
理解しないままTDDをおこなってしまうとテストを通すことが目的になってしまい、より良い設計を考えることをおろそかにしがち
修正が保証できるのでbug fixの前にはTDDをおこなうこと
その他
デザインパターンを使っているからといって良い設計とは限らない。
getter, setter自体が機能をあまり持たないメソッドなのでなるべく使わないようにする。
20章 Designing for performance
基本はシンプルな設計をおこなっていく
どうしてもパフォーマンス要件を満たせない場合は、問題が起きてから設計に変更を加えるようにする。
原因を特定したり、基準となる値を作ることができるので、パフォーマンス修正する前に測定する。
