積んでいたのをなんとなく今読んだ。

前提

具体例は多少古いものも多いが、考え方は参考になる本。

たびたび言われる話だが、例の図 (The Clean Architecture) について学ぶ本ではない。いろいろ出てくる原則の名前とかも別に覚えてなくてもいいと思っている。この本で大事なのはもっとマインド的な部分である。

フロントエンドエンジニアが読む場合は このあたり を副読本にしてもよいかも。

ためになったところ

最初から最後まで、手を変え品を変え一生以下のようなことを言い続けているところ。

• 依存関係とその向きを意識しよう
• 「同じ理由、タイミングで変更されるコードを密結合にする」vs「関係のないコードを疎結合にする」のバランスを取り続けよう
• 安定したものに依存し、変更が多いものに依存しないようにしよう
• 詳細の決定をできるだけ遅らせよう
• 強い境界と弱い境界を使い分けよう

感想

いきなり座学として読むというよりは、現場でコードを設計して悪戦苦闘した経験のある人が読むと効果が高い本だと思う。たとえば Humble Object Pattern という名前だけを頑張って覚えても仕方ないが、「なんかテスト書きづらいな、どうやって書けばいいんだ」とか少しでも悩んだことがあると一発で考え方がインストールされるはず。そういう本。

AIメインでコードを書くときにも治安を保ちやすくなる考え方が満載である。今新しく買う本ではないのかもしれないが、積んでいるのなら読む価値は間違いなくある。