本書の主張は、次の一文に集約されます。
良い設計とは、壊そうと思っても壊せない構造を作ることである。
ここで言う「壊れない」とは、 バグが一切出ないという意味ではありません。 気合や注意力、経験年数に依存しないコードである、という意味です。
良い設計がされたコードは、 間違った使い方をしようとすると、
- そもそもコンパイルできない。
- あるいは、実行する前の段階で違和感として現れる。
これは、 構造そのものが人を正しい方向に導くから成り立つものです。
多くの現場では、 「速く書けること」が価値として評価されがちです。 短期間で動くものを作れること自体は、確かに意味があります。
ただし本書では、 速さそのものを価値だとは定義しません。
なぜなら、 速く書かれたコードは、 将来の時間を消費することが多いからです。
一方で、良い設計は、
- 読めば意図が伝わる構造
- 変更点が局所に閉じる構成
- 間違ったコードを書けない制約
- 引き継ぎ時の説明コストの低下
- 未来の時間を買う
といった性質を持ちます。
これらは、 設計という構造の力によって生まれます。
本書では、シニアエンジニアが 「センス」や「経験則」として扱ってきた設計を、 明確に言語化された「文章」として記し、 設計するための思考の土台 としての役割を果たします。
例えば、設計の土台には次のようなものがあります。
- 判断をどこで完了させるか
- 状態に嘘をつかせないこと
- 責務の境界を明確にすること
- 変更理由が一つになるように構造を作ること
設計とは、 未来の自分や他人の行動を、構造によって制限すること だと考えています。
ドキュメントをどれだけ丁寧に整備しても、 時間が経てば読まれなくなります。 コードとの乖離が起き、 存在していないのと同じ状態になることもあります。
一方で、良い設計は、 ドキュメントを必要としません。
コードそのものがルールであり、 コンパイラがそのルールを強制する からです。
本書では、 この「コンパイラに仕事をさせる設計」を重視します。
設計がきれいなコードは、属人化しません。
特定の人がいなければ回らない状態は、 人の問題ではなく、設計の問題です。
後から参加した人が、 コードを読み、構造を理解し、 安心して変更できる。
その状態を作ることが、 設計に責任を持つということ だと考えています。
本書は、 特定の言語やフレームワークを解説する本ではありません。
Android、iOS、サーバーサイドなど、 分野が違っても共通する 設計の本質 を言語化することを目的としています。
早く書くための本ではなく、 壊れない構造を作るための本です。