A Philosophy of Software Design を読んだ

 本について
全編英語なのですが、かなり読みやすい英語で記載されていると感じました。
とにかくモジュールというのは情報を抽象化し、隠蔽してこそ意味があるというスタンスで、これを「深いモジュール」と命名しているのがユニークでした。
基本的にこういう設計関連の技術書はNotion上でメモをとりながら読むことが多いので、せっかくならこのメモをブログにも残しておこうと思い、各章のメモを残しておきます。
今後も何かいい技術書を見つけたら同じように記載していこうかなーと思います。
 各章のメモ Chapter 1 Introductionシンプルなデザインがより大きくパワフルなシステム構築を可能にすると言っている。
この本では 2 つのアプローチを説明していて
コードをシンプルに、より明らかにすることで複雑性を減らすアプローチ
複雑性を局所化するというアプローチ
オブジェクト指向など
この本では modular design と呼ばれている

継続的な開発とはつまり継続的な再設計を意味している
まず複雑性とはなにか？を述べた上で、それらを最小化する開発のアプローチを述べる
 Chapter 2 The Nature of Complexity 複雑性の定義システムを理解し変更することが難しくなった構造のことを複雑性と述べている。
複雑性を Isolating (孤立) させることで、全体的な複雑性を減らすことができる
コードを読む側の人間が複雑だと思ったらそれは複雑である
複雑性の症状として 3 つを上げている
Change Amplification: 変更箇所が多いということ
変更箇所が複数にまたがっている

Cognitive Load: 認知負荷
グローバル変数や一貫性の欠如、モジュール間の依存関係など

Unknowns unknown: 分からないことが分からない
これが一番悪いと述べている
知らないといけないことのにそれを知るすべがない状態
よい設計の重要なゴールに「明らかさ」がある

複雑性は依存性とあいまいさの 2 つによって引き起こされる
複雑性は徐々に生まれていくので、それを生み出さないようにするメンタリティが必要
 Chapter3 Working Code Isn't Enough 動くコードでは不十分Strategic Programming と Tactical Programming の対比
Tactical
可能な限り素早く動くものを作る

strategic
良い設計を求めて時間を投資する

strategic がいいと筆者は述べている
ソフトウェアは長い期間生存するため

いわゆる財政的な負債と違い、技術的負債は完全に返済されることはないと述べており、なので返済し続けろ ということを言っている
 Chapter4 Modules Should Be Deep モジュールは深くあるべしソフトウェアの複雑性を制御する 1 つに modular design がある。これは開発者が向き合わないといけない複雑性をできるだけ最小化するアプローチ。
この modular design のゴールは、モジュール間の依存関係を最小化することにある。よりモジュールは、実装よりもインターフェースがシンプルになっていること。

シンプルなインターフェースで居力な機能を提供するモジュールを deep （深い）と筆者は呼ぶ。
つまり狭いインターフェースで機能的に振る舞うメソッドがいいと言っている。広いインターフェースで大したことをしないモジュールは複雑性を隠蔽できていない。（こっちは shallow と呼ばれてたりする）
Unix I/O や GC を、deep module の代表例に上げている。多くの問題や複雑な問題を I/F を介して、あるいは I/F すらも隠蔽して実行している

LinkedList が shallow module の代表例。複雑性を隠蔽できていない
おそらくデータ構造をそのままマッピングしているだけ ということだろう

Classitis という言葉について
メソッドやクラスは小さく作れという教えがあるので、そうやりがちで、その状態を Classitis と筆者は呼ぶ
確かに 1 つ 1 つのクラスや関数は小さくなるが、全体的な複雑性は隠蔽できていない、むしろ複雑性が増える
小さいクラスは、より機能的に振る舞うことには貢献しない


筆者はメカニズムを知らなくても効果的に使える ということを重要視していそう。それを知らないとなにか不都合が生じることに異を唱えている感がある
モジュールを導入したとしても、情報の抽象度が変わっていない場合はむしろ複雑性が上がるというスタンス。なので deep なモジュールがいいと述べている

 5 章 Information Hiding 情報隠蔽知識がモジュールの実装に埋め込まれていてかつそれがインターフェースには表出していない状態を目指す
新しいモジュールを設計するときは情報（知識）がそのモジュール内に隠蔽されているか注意深く考えるべき
時系列で扱いたいデータを複数のクラスに分散させることは、その知識をクラス間で共有していることになり、好ましくないというスタンス。これを temporal decomposition と述べている
例えば HTTP サーバは temporal decomposition の例
リクエストヘッダーのパースやレスポンスヘッダーの構築は時系列に、かつレスポンスヘッダーはリクエストヘッダーに依存していたりするので、クラス設計として分けるべきではないと述べている

この思想で作られるモジュールは自然と「深い」モジュールになっていくので、deep module のひとつの手段や考え方が情報隠蔽（information hiding) である
クラスをより大きいものにすることで情報隠蔽はより達成される
クラスを小さく、個別に分けるというスタンスに真っ向から異議を唱えている感じがある

 6 章 General-Purpose Modules are Deeper 汎用的なモジュールは深い過度に特別なケース（エッジケース）などはソフトウェアを複雑化させるひとつの要因
general purpose(汎用的なモジュール) はよりシンプルで理解することが容易となる
特別なケースが引き起こす問題と汎用性の利点を話す
特殊ケースは完全に取り除けないので、どう分けるかについても話す


より一般的なモジュールを追うスタンスは、 負債解消への投資のマインドセットに近い
元々筆者も YAGNI でいいのではという考え方だったが、いくつかの学生のプロジェクトを見て、どの場合においても general-purpose なクラスのほうがよかったということに気づいた
これはたとえそのクラスが再利用されなかったとしても


経験として、somewhat general-purpose がいい塩梅だと言っていて、インターフェースはより一般的であることを目指しつつ実装は YAGNI 的に実装するというもの
今欲しいものを実装はするが、インターフェースは一般的なものを目指して設計を進める

より一般的なユースケースで利用できるメソッドを実装することで、実装量は減るし、認知負荷を下げることができる
結局これも抽象度を上げるインターフェースを用意することで解決するアプローチ
これって information hiding(5 章のやつ) だよねという話
例えばテキストエディターの実装で、backspace の挙動を実装したい時に、そのまま backspace というメソッドを生やしても、それって情報の抽象化ができていないですよね？という話をしている
backspace が押された時の挙動ということはわかるが、じゃあそれってどういう処理をしてるんですか？というのがメソッドシグネチャからわからないので結局実装を見る必要があるよねという


今の必要なもの全てをカバーできる最もシンプルなインターフェースは何か？を問い続けることが重要
Questions to ask yourself

普遍的に扱えないか？という観点で考慮し設計に反映させることで特別扱いしないといけないケースを減らすことができる
if 文を減らすようなアプローチを検討したい

 7 章 Different Layer, Different Abstraction 異なるレイヤー、異なる抽象化似たような抽象化を隣接したレイヤが行うと、パススルーメソッドという形で問題が表出する
実際には何もしないパススルーメソッドは、綺麗な責務の分割ができていないことを示すことが多い。どういう責務分割なのか混乱を招くしクラス間の依存を生む
これはクラスを「浅く」する

同じインターフェースでもいい例として Dispatcher を挙げている
どのメソッドにディスパッチするかを選択する Dispatcher とその実際の処理となるメソッドは同じインターフェース（シグネチャ）を持つ可能性がある
これは提供している機能や抽象化のレイヤが異なるため許されるケース

Decorator には否定的な立場をとっている
特殊なケースを考慮した浅いクラスやモジュール、パススルーメソッドが大量に作られることになり、これは前章で述べた内容と相反している
デコレータは導入すると酷使されやすいということも述べている、わかる

デコレータの統合や、そもそもデコレータを使わないクラスを見つけるなどの手法を提案している

 8 章 Pull Complexity Downwards 複雑性を引き込むモジュールは開発者より使う人の方が多いので、実装が複雑になったとしても使う人にとってインターフェースがシンプルな方がいいと述べている
例外や設定(Config)についてもインターフェースを外部に公開しているので複雑性を上げる要因と言っている

configuration parameter（設定パラメータ） を正しい値に設定することは難しいあるいは不可能と述べている
ゆえに設定項目を外部に公開する前に、「正しいデフォルト値を我々（提供側）に設定できないか」を問うべき
設定パラメータは不完全なソリューションを提供していると述べている
それぞれのモジュールは個々で問題を解決すべき


 9 章 Better Together Or Better Apart? 一緒にするべきか分けるべきか細分化のやりすぎは良くない
コンポーネント、インターフェースの数が増えることになり、これは複雑性をうむ
細分化したコンポーネントをオーケストレーションする層が必要になる
分断を生む
完全に分離されているなら良い
依存があるとコンポーネント間を行ったり来たりする必要が出てくるので良くない

複製を生む

関係のないものは分けて、関連するものは一緒に扱った方がいいとしている
関連していることを示すもの
情報を共有している
データを読んで、パースして、のような処理はデータを読むところとパースするところで同じ知識を共有している
HTTP サーバの例など


一緒に使われる
概念が重なっている
他の箇所を見ないと理解が難しい


メソッドの分割の基準として行数を採用することに反対している
メソッド分割を「しすぎだ」と述べている
シンプルなメソッドシグネチャで読むことが簡単なのであれば分ける必要がない
これは “deep” なメソッド

メソッドを分けることで行き来が増え、メソッドのインターフェースも増え、複雑性が増す

メソッドを設計する際のゴールは「抽象」を提供すること
メソッド間を行き来することは抽象を提供できておらず、red flag だと述べている
メソッドに切り出すということはその先で具体的に何をしているかを知らなくてもわかるようになっているはず

 10 章 Define Errors Out Of Existence 存在しないようにエラーを定義する例外はクラスが持つインターフェースの一部である
多くの例外はクラスを “shallow” にして、複雑なインターフェースとなる

例外を投げることは簡単だが、それを受け取ってハンドリングする側は難しい
すなわち呼び出し側でハンドリングしなければならない例外を減らすことが重要
なんならハンドリングが必要な例外をなくすことが一番いいと言っている
セマンティクスを再定義することで例外を減らすことができる
Java の文字列のメソッドの話

例外をマスクする
例外を投げたところでそれを受けるユーザにはどうしようも解決ができないこともある
ファイルシステムサーバのエラーなど
どうせ復旧したタイミングでリトライするんだから、例外は吐かずにハングさせておいたままにするのが合理的
例外を投げたかったらクライアント側でタイムアウトを設定して手動でエラーを投げればいい
デフォルトは一番使い勝手がいい状態にするべきという思想がここにも現れている





何が重要で何が重要でないかを見極めることが必要
重要でないエラーは隠されるべきだし重要なエラーは外部に通知できるようになっているべき
発生頻度がレアだったり、リカバリ不可能なエラーのハンドリングで複雑性を上げる必要はない


 11 章 Design it Twice 二度設計する色々なパターンをあげながら設計方針を考えるのがいい
一番いい設計だと思っていても別のパターンを考え、pros/cons を整理することで、よりベストな設計に近づくという話

インターフェースレベルの設計をしたら実装レベルでも複数のパターンを検討したい
実装レベルの場合は シンプルさとパフォーマンス性を重視する

 12 章 Why Write Comments? The Four Excuses なぜコメントを書く？4 つの言い訳コメントを書くプロセスは、システムへの理解だけでなく、設計をより向上させるものだと言っている
4 つの言い訳
良いコードはそれを見ればわかる（self-documenting)
クラスインターフェースやメソッドシグネチャはコードを見ればわかる
より抽象度の高い「メソッドが何をしているか」や「結果、返り値の意味」についてはコードでしか説明することができない
設計上の意思決定、特定のメソッドを呼ぶべき条件 など、コードでしか説明できない例はたくさんある
「コードを読めば分かる」と言って一つのメソッドをさらに分割していくようになると、「浅い」モジュールが出来上がっていく
コメントは抽象化を提供し、これはモジュール化が目指すものと同じことだ
そのメソッドを使う時コードを読まないといけないのであれば、それは何も抽象化がないということを表している
自然言語はこの抽象化に一役買うことができる


コメントを書く時間がない
これに対抗するには「investment mindset」長期的な思考が重要
コメントの記載は実装の 10%も時間がかからないが、利益はすぐに享受できる

コメントが追従できないとミスリーディングになる
大きいコメントの修正は大きい実装の変更に伴うものであり、どうやっても実装よりコメントの記載に時間がかかることはないのだから、より最新のコメントに追従させるのはそこまでの努力は必要としないだろう

見たことがあるコメントに価値を感じたことがない
よいドキュメンテーションとメンテナンスの方法を知ればいい


コードとして書くことのベースの考えは、コードでは表現できない設計者のマインドを記載する
ローレイヤーのトリッキーなクセのあるコードから、ハイレイヤーのクラス設計まで適用可能

 13 章 Comments Should Describe Things that Aren’t Obvious from the Code コメントはコードから明らかでないものを書くべき開発者は、コード読むよりも外部に公開された宣言（コメント含めて）から概要を理解するべき
良いコメントは、コードと別の粒度で抽象化されていることだと述べている

コメントに関する 4 つのカテゴリについて
Interface
クラスの意味やメソッドの振る舞い
実装とインターフェースを分けてコメントとして残せるかに着目する
残せない場合は「浅い」メソッドである

副作用は返り値からは判断できないのでインターフェースレベルのコメントとして残す

Data structure member
データ構造に関するもの

Implementation comment
実装に関するもの
実装に関して何をしているかを表すものでどうやっているかではない
how ではなく what を書く
トリッキーなことをしている場合は why も書く


Cross-module comment
依存するモジュールに関するもの

最初の 2 つが特に重要と述べている。すべてのクラスやメソッドはコメントを持つべき
きっとここら辺は「deep」なクラスやメソッドであることが暗に前提になっているんだろう


コードを読んだことがない人が、コメントだけで書けるようになるか？を問うとよい
メソッド名や変数名などと違う語彙を使ってコメントで補足するといいコメントの最初のステップになると言っている
コメントは動詞ではなく名詞に対してフォーカスすると冗長なコメントになるのを避けることができる
このコードは何をしているのか？コードを説明するシンプルな語彙は何か？このコードで最も重要なことは何か？これらを問い、コメントとして残すことで抽象や概要を提供するコメントを書くことができる

読み手が曖昧だと感じたらそれは曖昧なので、そういう指摘に対して、どこが曖昧かを議論することを恐れてはいけない
 14 章 Choosing Names 命名「まあまあ」な命名に甘えてはいけない
時間をとって、正確で、曖昧さがなく、直感的な名前をつけるべき

命名も抽象化の一つの形式だと言っている
命名に困るということは、変数の定義や目的が曖昧ということを表しており、設計の弱みを特定し、向上するいい機会と捉えることができる
それが一貫しているなら短い変数名でも良いが、短い変数はコンフリクトしがちで、同じ変数が異なるコンテキストで使われるならやめた方がいい
i, j はループ変数、とか、そういうのなら良い

 15 章 Write The Comments First 最初にコメントを書くコメントを書くのに最適なタイミングは、コードを書き始める最初だと述べている
後からコードを書こうとすると後回しにした結果、書かないということが起こりがち

コメントを最初に書くことの恩恵は 3 つ
設計に関する記憶がフレッシュなので、忘れることがないこと
実装に集中すると設計に関連した意思決定の内容を忘れてしまうことがある

コメントを最初に書くことは良い設計を提供する
コメントを書く行為によって自身に対するレビュー作用が働く
実装の前にコメントを書くことで、より抽象な事柄を対象にしたコメントを書くことができ、それがいいコメントにつながる
コメントで表現する内容がファットな場合は、うまく責務分割ができていないことを示唆していたりする

コメントを書くことが楽しい
良い設計の指標となるため、それを使ってさらに設計に関する探究ができるということで筆者は楽しいと述べている


 16 章 Modifying Existing Code 既存コードの改修tactical と strategic の話で、strategic のアプローチをとるべきという話が再び登場する
実装と近い位置にコメントを記載することで、コメントが変更に追従されない問題を解決できる
コミットログまで見ることは少ないので、コミットではなくそれをコードコメントに書けないかを問うべき
コミットログにはなぜその変更が必要だったのか等の背景情報を記載するといい

コメントが重複して複数箇所に記載されると、必ず片方が追従できなくなるので避けるべき
コミットする際に、差分をセルフチェックし、コメントの最新化が漏れていないかをチェックする
そもそも抽象度が高いコメントであれば実装のたびに頻繁に修正する必要がなくなるので、そういうアプローチも検討したい
 17 章 Consistency 一貫性一貫性が適用できるもの
命名
コーディングガイド
インターフェース
デザインパターン

一貫性の維持に必要な要素
ドキュメント
強制力
違反チェックのツール

郷に入っては郷に従う
周囲のコードを見渡して理解する

既存のルールを変更しない
better idea では十分でない


 18 章 Code Should be Obvious コードは明らかであるべき不明瞭さは新しい開発者にとってシステムが明らかでない時に生まれる
不明瞭さはコードの読み手が判断するものなので、コードレビューがそれを判断するいいプロセスになる

明瞭さを実現するために重要なテクニックは 2 つ
良い命名
一貫性

 19 章 Software Trendsオブジェクト指向について
親と子で依存関係ができるような実装はやめるべき
例えば、親側でデフォルトの振る舞いを定義していて、子クラスでそれをオーバライドしたりしなかったりするケース
共有できる振る舞いは composition ベースなアプローチを検討したい


アジャイル開発について
注意したいのは、tactical programming に収束してしまう可能性があること
個々の機能実装だったりイテレーションの時間制約だったりで、短期的な視野に陥りがち

イテレーティブに、抽象されたものを開発していく

テスト駆動開発について
「テストを通すこと」が最優先となって、ベストな設計を見つけるような力学が働かなくなる懸念があると述べている

 20 章 Designing for Performance パフォーマンスのための設計既存のコード上でパフォーマンス改善をする場合
まず仕様を満たす最小限のコードを書く
この際に既存のコードがどうなっているかは気にしない

その最低限の仕様を満たすコードと現在のコードとを突き合わせて、ギャップを埋めていくことをする
エッジケースの考慮等で遅くなっている場合があるので、分離できないかを検討する