A philosophy of software design

Interface comments と Implementation comments

前者は抽象化した説明を記載する。実装についてここで説明をしない。

後者は how てはなく what, why を書く

名前（変数名、関数名など）は正確で簡潔に書く。
何を表していて、逆に何を表していないかを名前に含める。

簡潔な命名が思い浮かばない場合、そもそも設計が悪い可能性がある。

一貫性のある命名をするべき。
また、スコープが短い場合は短い命名でもよい。

同一システム内の一貫性について述べられていたが、ソフトウェア開発全体で慣習的に使われている命名に従うと言った一貫性も重要そう。

コメントを先に書くことのメリット

1. 設計したあとすぐにコメントを書くことになるので、良いコメントが書ける。後から書くと重要な設計思想などを忘れてしまう。
2. コードを実装する前にコメントを書きながらレビューと調整ができるのでシステムの設計がより良いものになる。
3. 早く書いたほうが楽しくコメントが書ける。設計フェーズの楽しさをそのままコメントに落とせる。

「良い設計をする」と「良い設計を保つ」の両面があり、ここからは後者の話。
コードのリファクタリングをする際には「その時点の制約の中で最も良い設計になっているか」を常に考える。
「動くコードを素早く書く (tactical programming)」ではなく、「良い設計で改修・追加がしやすいコードを書く (strategic programming)」を目指す。

重複したコメントは不要なので書いてあることが最も明らかな場所（変数だったら定義されている場所）のみに書くようにする。

一貫性により複雑性を排除し、認知負荷を軽減し、実装工数を下げることができる。

一貫性を担保する方法としては、ドキュメンテーションやツールの利用が挙げられる。

それまでの慣習を崩してまで新しい方法を取り入れたい場合は、本当にその価値があるのかを十分に検証した上で、過去の慣習に従っている部分を全て置き換えて一貫性を担保しながら実施する必要がある。

コードが明確ではなくなる要因として、

• イベントドリブンなプログラミング
• ジェネリックコンテナ
• 宣言時と代入時の型が違う

等がある。
ソフトウエアは書き手のやりやすいようにデザインするではなく、読み手にとってわかりやすくなるようにデザインすべき

アジャイル開発はインクリメンタルに開発するという思想は良いが、ともすれば tactical になってしまうのでそこは注意が必要

ユニットテストを書くことで修正時の自信度を高める

TDD は tactical になりがち。
ただ、bug fix のときにはテストから書くと良い。

ここまでは複雑性の話をしてきたが、chapter20ではパフォーマンスの話

パフォーマンスを向上させるために複雑性が増す場合、本当にそれが必要かを考えるべき。
最初は複雑性を減らす開発をして、パフォーマンスは本当に問題になったときに対処するという流れで良さそう。

パフォーマンスの改善は直感ではなく計測すること。
計測によって

• どこがボトルネックかわかる
• 対応後に本当に改善したかを測るベースラインになる

ということが期待できる。

critical path を基礎的なところ（アーキテクチャ的な）から直すべき。
特殊ケースは脇に避けて（処理自体を別のブロックにして if 文を減らす）一般的なケースの改善をする。