3行でいうと

  • 乱雑なコードは、長い目で見るとチームの生産性を下げ続ける
  • 名前、関数、コメント、テスト、クラスの各段階に、具体的な規範を示す
  • 実在のコードを段階的に直す実演で、原則の使い方を見せる

向いている人

数年ほど実務やコードを書いた経験があり、読みやすいコードの基準を身につけたい人。チームのコードレビューの共通言語がほしい人。

読む意味

コードの品質を、名前や関数の大きさといった具体的な水準で語る語彙が得られる。「ボーイスカウトルール」のように、レビューの共通言語として使われる考え方も学べる。

読むときの注意

極端に小さい関数や、コメントをできるだけ避ける姿勢には、後年の実務者から異論も出ている。絶対的な正解ではなく、議論のたたき台として読む姿勢が広く行われている。

どんな本か

この本は、読みやすく、直しやすい「クリーンなコード」を書くための原則と技法を、豊富なコード例とともにまとめた本である。著者のロバート・C・マーチン（通称アンクル・ボブ）は、アジャイルソフトウェア開発の提唱者の一人で、17歳から独学でプログラマとして働き、アジャイル・アライアンスの初代会長も務めた。長年のコンサルティング経験を集約した本である。

出発点は、乱雑なコードは短期的には開発を速めるように見えても、やがて泥沼を歩くような状態を招き、チームの生産性を下げ続けるという問題意識である。そのうえで、意味のある名前、小さく一つのことだけをする関数、自己説明的なコードを前提にしたコメントの考え方（コメントは「必要悪」）、オブジェクトとデータ構造の区別、エラー処理、単体テスト、クラスとシステムの設計、同時並行性までを、レベルごとに規範として示す。

特徴は、単なる規則集で終わらない点にある。コマンドライン引数のパーサ、JUnit、日付クラスSerialDateといった実在のコードを題材に、少しずつ書き直していく大規模な実演が含まれる。最後の章には、コードの「におい」と経験則の一覧がまとまっている。

中身の柱

あわせて読む本

書評データベースの全文を読む

概要

アジャイルソフトウェア開発の主要な提唱者の一人であるロバート・C・マーチン(通称アンクル・ボブ)が、可読性・保守性の高い「クリーンなコード」を書くための具体的な原則と技法を、豊富な実コード例とともにまとめた書籍。原著は2008年刊行。日本語版はKADOKAWA(旧アスキー・メディアワークス)より刊行されている。乱雑なコードは短期的には開発を速めるように見えても、時間の経過とともに「泥沼を歩く」ような状態を招き、チームの生産性を長期的に低下させ続けるという問題意識を出発点に、命名・関数設計・コメント・クラス設計・テスト・システム設計といった各レベルで守るべき具体的な規範を提示している。単なる規則集ではなく、実在するオープンソースコード(JUnitやSerialDateクラス)を題材とした大規模なリファクタリング実演を含んでいる点が特徴である。著者マーチンは17歳で独学のプログラマとしてキャリアを開始し、1991年にコンサルティング会社Object Mentorを設立、2001年には「アジャイルソフトウェア開発宣言」の起草者・署名者の一人としてアジャイルアライアンスの初代会長も務めた人物であり、本書はその長年のコンサルティング経験を集約したものである。

本の構成

全17章と3つの付録から成る。第1章「クリーンコード」、第2章「意味のある名前」、第3章「関数」、第4章「コメント」、第5章「書式化」、第6章「オブジェクトとデータ構造」、第7章「エラー処理」、第8章「境界」、第9章「単体テスト」、第10章「クラス」、第11章「システム」、第12章「創発」、第13章「同時並行性」、第14章「継続的改良」、第15章「JUnitの内部」、第16章「SerialDateのリファクタリング」、第17章「においと経験則」と続き、付録A「同時並行性II」、付録B「org.jfree.date.SerialDate」、付録C「経験則のクロスリファレンス」が収録されている。

主要な内容

クリーンコードの定義とボーイスカウトルール(第1章)

ビャーネ・ストロヴストルップ、グラディ・ブーチ、デイブ・トーマスら業界の著名な技術者による「クリーンコード」の定義を複数引用しながら、コードの品質が開発チームの長期的な生産性に直結するという主張を導入する。コードに触れるたびに、触れる前よりも少しだけきれいな状態にして残すべきだという「ボーイスカウトルール」がここで提示される。

意味のある名前(第2章)

意図が伝わる名前を選ぶこと、誤解を招く名前を避けること、発音可能・検索可能な名前を用いること、ハンガリアン記法のような型情報を名前に埋め込むエンコーディングを避けること、クラス名は名詞、メソッド名は動詞で表すことなど、命名に関する具体的な規則が列挙される。

関数(第3章)

関数は小さくすべきであり、一つの関数は一つのことだけを行うべきであるとし、関数内の抽象度のレベルを揃えること、引数の数を可能な限り減らすこと(フラグ引数を避けること)、副作用を持たせないこと、エラーコードよりも例外を使うことなどが論じられる。本章はケント・ベックのプログラミングスタイルを引き合いに出し、優れた関数はしばしば「わずか2行、3行、4行程度」の長さに収まり、それぞれが物語を語るように読めると述べている点も特徴的である。

コメント(第4章)

優れたコードは自己説明的であるべきで、コメントは「必要悪」であるとする立場を取る。合法的なコメント・情報を提供するコメント・意図を説明するコメント・警告のコメント・TODOコメントなどを良い例として挙げる一方、冗長なコメント・誤解を招くコメント・義務的に書かれたコメント・日記のようなコメント・ノイズになっているコメント、バージョン管理システムが存在するにもかかわらず削除せずに残されたコメントアウトされたコードなどを悪い例として挙げる。

オブジェクトとデータ構造・エラー処理・境界(第6〜8章)

データを隠蔽し振る舞いを公開する「オブジェクト」と、データを公開し実質的な振る舞いを持たない「データ構造」とを明確に区別し、直接知っているオブジェクトのメソッドのみを呼び出すべきとする「デメテルの法則」を扱う。エラー処理では戻り値のエラーコードではなく例外を使うこと、nullを返す・渡すことを避けることが説かれ、外部のサードパーティ製APIを扱う「境界」の章では、ラッパーやアダプタで外部コードを包み込み、外部ライブラリの挙動を確認するための学習用テストを書くことが推奨される。

単体テスト・クラス・システム(第9〜11章)

単体テストが備えるべき性質としてF.I.R.S.T.(高速・独立・再現可能・自己検証可能・タイムリー)の原則が示され、テストコードにもプロダクションコードと同等の品質意識を持つべきだとする。クラス設計の章では、変更理由が一つだけであるべきとする単一責任の原則(SRP)をはじめとするクラスの整理指針が扱われる。これはマーチン自身が2000年の論文で体系化し、2004年頃にマイケル・フェザーズによって頭字語化された「SOLID」原則(単一責任・開放閉鎖・リスコフの置換・インターフェース分離・依存性逆転の5原則)の一部をなすものであり、本書のクラス・システムの各章は、このSOLID原則の考え方を実コードレベルで示す内容になっている。システムの章ではオブジェクトの生成とその利用を分離する(依存性注入など)ことで、クリーンコードの原則をシステムレベルにまで拡張する視点が示される。

創発・同時並行性(第12〜13章)

ケント・ベックによる「シンプルな設計の4つのルール」(すべてのテストを通過する、意図を明確に表現する、重複を排除する、要素を最小限にする)を、優れた設計を段階的に創発させるための軽量な指針として紹介する。同時並行性の章では、並行処理に関わるコードを他のコードから明確に分離すべきといった原則が扱われる。

継続的改良・JUnitの内部・SerialDateのリファクタリング(第14〜16章)

コマンドライン引数パーサーを題材にした大規模な段階的リファクタリングの実演(第14章)、JUnitフレームワーク自体のソースコードを題材にしたクリーンさの分析(第15章)、実在するオープンソースの日付クラスSerialDateを題材にした本格的なリファクタリングの実演(第16章)が、それぞれ実コードのビフォー・アフターとともに示される。第16章では、JFreeChartプロジェクトの一部として公開されていたSerialDateクラスの実際のソースコードに対し、命名の改善、冗長なコメントの削除、責務の分割といった本書全体で説かれてきた原則を一つずつ適用していく過程が、変更の理由とともに逐一解説される。

においと経験則(第17章)

コメント・環境・関数・全般・名前・テストといったカテゴリーに整理された、コードの「におい(smell)」と経験則の一覧が収録されており、付録Cによって本文の各章と相互参照できるようになっている。

具体例

第2〜3章では、意味の乏しい"getThem()"という関数を、変数名をより具体的なものに置き換え、抽象度を揃え、条件式を意味のある関数へと切り出すという段階を経て、最終的に読みやすいコードへと書き換えていく実例が示される。第14章のコマンドライン引数パーサー、第15章のJUnit、第16章のSerialDateクラスは、いずれも実在するコードを対象にした大規模なリファクタリング実演として本書の中心的な具体例を構成している。特にSerialDateの章では、リファクタリング前後のクラス全体のソースコードが並べて掲載され、単なる断片的なコード例にとどまらず、一つのクラスがどのように段階を追って改善されていくかを読者が最初から最後まで追体験できる構成になっている点が、本書を単なる原則集にとどまらせない大きな特徴となっている。

実践への応用

社内のコーディング規約・コードレビューのチェックリストとして命名規則(第2章)や関数設計の指針(第3章)を採用すること、コメントを書く前に自己説明的なコードで表現できないか検討する運用ルールを設けること、テストコードにもプロダクションコードと同等のレビュー基準を適用すること、第17章の「においと経験則」一覧をコードレビューのチェックリストとして活用すること、コードに触れるたびに少しずつ改善する「ボーイスカウトルール」を日常のプルリクエスト運用に組み込むことなどが、実務上の応用として挙げられる。

位置づけ・評価

コード品質・ソフトウェアクラフトマンシップに関する議論において業界内で最も広く参照される書籍の一つであり、「ボーイスカウトルール」をはじめ本書由来の語彙がコードレビューの共通言語として定着している。著者ロバート・C・マーチンによる『Clean Architecture』『Clean Agile』『Clean Coder』といった一連の「クリーン」シリーズの中核をなす一冊でもある。一方で、極端に小さい関数や「コメントはできる限り避けるべき」とする姿勢など個々の主張については後年の実務者から異論や批判も提起されている。とりわけソフトウェア工学者ジョン・オウステルハウトは、著書『A Philosophy of Software Design』の中で、関数を数十行未満にまで切り詰めても可読性の向上は限定的であり、かえってインターフェースの数が増えてモジュール間の独立性が損なわれると指摘し、コメントを避けようとする姿勢やテスト駆動開発への傾倒についても異論を唱えている。本書の規範を絶対的な正解としてではなく、議論のたたき台として参照する読み方も広く行われている。