コードは人間のために書く：Robert C. Martin『Clean Code』の原則と論争

ソフトウェアのコードは、機械が実行する時間よりも、人間が読み、保守し続ける時間の方がはるかに長い。Robert C. Martin の『Clean Code』は、この前提に立って「他人が意図を正確に読み取れるコード」を書くための具体的な原則をまとめた一冊だ。一方で、その原則をどこまで適用すべきかをめぐっては明確な反論も存在する。賛否の両方を知っておくことで、原則を道具として使い分けられるようになる。

1. 意味のある名前で「メンタルマッピング」をなくす

本書が多くのページを割くのが命名だ。

読み手が変数名や関数名から「これは結局何を指すのか」を頭の中で別の言葉に翻訳しなければならない状態を、本書は「メンタルマッピング」と呼び、認知負荷とバグの温床だと指摘する。tmp や1文字の変数のような汎用的な名前を避け、発音でき、検索でき、役割が伝わる名前を付ける。一つの概念にはシステム全体で同じ単語を割り当て、型情報を名前に埋め込む古い記法は使わない。

名前そのものが仕様の説明になっていれば、読み手はコードの周辺を調べずに意図を理解できる。

2. 関数は小さく、一つのことだけをする

本書のもう一つの柱が関数設計だ。

巨大な関数はテストを難しくし、変更の影響範囲を広げる。本書は関数を小さく保ち、「一つのことだけを行う」単一責任を求める。さらに一つの関数の中では抽象レベルを揃え、「ビジネス上の判定」と「低レベルの文字列操作」を混在させないことで、処理が上から下へ物語のように読める構造を目指す。

引数は可能な限り減らし、状態を変える処理と値を返す処理を分ける「コマンド・照会分離」を守る。これにより、呼び出し側が予期しない副作用に悩まされにくくなる。

3. コメントは「なぜ」を語る

本書はコメントに対して禁欲的だ。

コードを見れば分かることをコメントで言い換えるのは二重管理を生む。さらにコメントはコード変更時に取り残されやすく、事実と食い違う「誤った情報」へと劣化するリスクを抱える。だからこそ、コメントを書く労力があるなら、まず名前や関数の構造を改善してコード自体に語らせるべきだ、と説く。

コメントが本当に必要なのは、コードに表れない「なぜ」——設計判断の意図、警告、非自明な前提——を残すときだ。

4. クリーンなコードの代償：パフォーマンスと教条主義への批判

本書の原則は「人間にとっての読みやすさ」を強く志向するが、実務に適用するうえでは反論も知っておきたい。

ゲームエンジン開発者の Casey Muratori は「Clean Code, Horrible Performance」と題した議論で、ポリモーフィズムや細かく分割されたオブジェクトがメモリ上に散在すると、現代のCPUのキャッシュ効率が落ち、実行速度を大きく損なう場合があると指摘した。高い性能が要求される領域では、データを連続したメモリに並べる「データ指向設計」の方が有利になりうる、という立場だ。

加えて、原則の適用が自己目的化する危険も指摘されている。「美しい構造を再現すること」が目的にすり替わり、まだ起きていない変更に備えた過剰な抽象化でコードを複雑にしてしまう、というパラドックスだ。本書の価値を認める読者の間でも、提示された原則を絶対視せず、自分が解くべき問題に照らして取捨選択する姿勢が必要だという見方は根強い。

DevBookPath のマップで確認する

この本の前後の読書順は、DevBookPath のグラフで確認できます。

👉 ソフトウェア設計の地図を見る

---

本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。