動くけど誰も触りたくない、自分が書いたコードに自分でもうんざりする——そういった状態は、コードの「良し悪し」を判断する軸が育っていないことが原因だ。この本はその判断軸を、具体的な対比で体系的に育てる。
書いた瞬間から技術的負債になっていく
コードは書いた瞬間から「資産」にも「負債」にもなりうる。テストしにくい、変更に弱い、意図が伝わらない——こういった特性は積み上がり、やがてチームの開発速度を根底から奪っていく。
しかし「良いコード」の基準を学ぶ機会は少ない。実務で育った感覚はあっても、それが体系化されていないと判断にブレが生じる。本書『Good Code, Bad Code』はその問題に直接向き合う。
対比で理解できる設計の原則
本書はタイトル通り、「良いコード」と「悪いコード」を対比しながら、なぜ違いが生まれるのかを解説する構成だ。Google出身のソフトウェアエンジニアが、実務で積み上げた設計思想を432ページにわたって体系化している。
現場の判断が変わった5場面
- 関数・クラスの責任範囲の引き方: 「なんとなく分ける」ではなく、変更の理由が一つになるように設計する意識が持てるようになった
- エラー処理の設計観点: 例外を投げるか、戻り値で伝えるか、nullを返すかの選択基準が明確になり、実装の迷いが減った
- テスタビリティを前提とした設計: コードを書きながら「これはテストできるか」という視点が自然に入るようになった
- 命名の力: 変数名・関数名ひとつが読み手の理解速度を大きく左右するという事実が、多くの具体例で実感できた
- 再利用性とカプセル化のバランス: 何でも共通化すればいいわけではない、という実用的な判断基準を得られた
コードの質は、意識の質で変わる
良いコードを書くのに天才的なセンスは要らない。本書が示す考え方を身につけ、意識的に適用し続けることで、自然と質が上がる。コードレビューで自信を持ちたいすべてのソフトウェアエンジニアに、本書を手に取ってみてほしい。