A philosophy of software design 16 ~ 20章を読んだメモ

A Philosophy of Software Design の16章 ~ 20章を読んだので忘備録としてまとめていきます。

A Philosophy of Software Design

16章 Modifying Existing Code

• 最初の設計の出来よりも、その後システムがどのように修正されるかによってシステム全体の複雑さが決まっていく

• 既存のコードを修正するときに、修正範囲が増える事を恐れて、なるべく少ない修正をしようとするのは間違い。

• コードの近くにコメントを書く。コードから離れれば離れるほどコメントを抽象的にする。

• 外部モジュールの詳細についてコメントとして書くべきではない。外部でドキュメント化されているなら、外部のドキュメントのリンクを書く。

17章 Consistency

• 一貫性のある設計 ⇨開発者がシステムを容易に理解できる⇨時間と労力の削減

• 一貫性の種類

  • 名前
  • コードの形式
  • インターフェース
  • デザインパターン
  • 不変条件

• 一貫性を実現するために

  • ドキュメントを書く
  • lintを入れる
  • 既存のコードに合わせる
  • 既存のルールを変更しない
  • コード規約を導入する
  • 冗長な処理を見つける
  • コードレビューで教育する

18章 Code should be obvious

• わかりやすいコードを作るテクニック

  • いい名前をつけること
  • 一貫性のあるコードを書くこと
  • 空白や空行を使ってまとまりを作ること
  • コメントを使って情報を補うこと

• わかりづらいコードが生まれる要素

  • ジェネリクスを扱うクラスでは、メソッド名が曖昧なものになるので、JavaのMapやListをそのまま使うのではなく自前で専用のクラスを作る

19章 Software trends

OOP

• 実装と継承によってコードを明確にする。

• 継承は、親クラスのメソッドやフィールドを子クラスが利用できるので、親クラスと子クラスで依存関係が生まれる。

• 良い設計を実装する手助けはしてくれるが、OOPを使っているからといっていい設計になるわけではない。

アジャイル開発

• incrementalでiterativeな開発によって小さい改善を繰り返すことで、シンプルな設計を作り出すことができる

• 動くものを作るという考えがあるためtactical programmingになってしまうことがある

TDD

• 理解しないままTDDをおこなってしまうとテストを通すことが目的になってしまい、より良い設計を考えることをおろそかにしがち

• 修正が保証できるのでbug fixの前にはTDDをおこなうこと

その他

• デザインパターンを使っているからといって良い設計とは限らない。

• getter, setter自体が機能をあまり持たないメソッドなのでなるべく使わないようにする。

20章 Designing for performance

• 基本はシンプルな設計をおこなっていく

• どうしてもパフォーマンス要件を満たせない場合は、問題が起きてから設計に変更を加えるようにする。

• 原因を特定したり、基準となる値を作ることができるので、パフォーマンス修正する前に測定する。