- Robert “Uncle Bob” MartinとJohn Ousterhoutが、2024年9月から2025年2月まで行ったソフトウェア設計に関する対話
- 2人ともソフトウェアデザインに関する著書を執筆している
- 3つの主要テーマ（メソッドの長さ、コメント、Test-Driven Development）で見解の違いを示した
- 対話の核心は、コードの複雑さを減らして可読性を高める方法と、適切なテストの書き方にある
メソッドの長さ
- Uncle Bob（以下UB）は、「短い関数がよく、可能ならさらに短く分割する」という立場を強調する
- 1つのメソッドは1つの「仕事（One Thing）」だけを行うべき
- ただし、これを極端に適用すると過剰な分解（over-decomposition）につながりうる
- Johnは、小さすぎるメソッドはかえって全体の流れを理解しにくくすると指摘する
- 「浅い（shallow）メソッド」が増えると、1つの機能を理解するために関連するメソッドをすべて見なければならない問題が生じる
- メソッド間の相互依存（「entanglement」）が高まり、コードを読む負担が大きくなる
PrimeGenerator の例
- UBの元のコードは8個ほどの小さなメソッドに分かれており、メソッド同士が絡み合っていて理解しにくかった
- Johnのバージョンは1つのメソッドに十分なコメントを付け、全体の流れをひと目で把握できるように書かれていた
- UBも「過剰な分解があった点」はある程度認めた
- 結論として、2人ともコード分解の重要性は認める一方で、「細かく分けすぎること」と「大きすぎるままにすること」の間でバランスを取ることが重要だとしている
コメント
- UBはコメントについて「必要悪（necessary evil）」という見方をしている
- コメントは更新されにくく、誤った情報を含む危険があると考える
- コードによって意図を最大限に表し、必要なら非常に長い名前を使う方法を好む
- Johnはコメントが不可欠だと主張する
- インターフェース（メソッド）の目的や実装意図を英語で明確に書いておけば、他の開発者が不要にコードを掘り返す時間を減らせる
- 「最も危険なのは、コメントがないためにコードを直接解釈しなければならない状況」だと見る
PrimeGenerator を例に、Johnは「アルゴリズムがなぜそのように動くのか」を説明するコメントがなければ非常に理解しにくいと指摘する- UBは「コメントが正確でなければかえって害になる」という立場だが、Johnは「誤ったコメントよりコメントがないほうが有害だ」と考える側である
- 2人とも「チームと状況に応じて適切な水準のコメントを付けるべき」という点ではある程度合意したが、全体としてJohnのほうがコメントの価値をはるかに高く評価している
JohnのPrimeGeneratorリファクタリング
- Johnは、もともと8個のメソッドに分かれていたコードを、単一メソッドまたは2〜3個のメソッド構成へ再編した
- 必要な箇所に豊富なコメントを付け、「なぜこの方式で実装するのか」を説明した
- コメントで主要変数（
multiples、primes）の意図とアルゴリズムの動作方法をあわせて記述し、コード理解を素早く助けようとした
- UBは、このコードも完全に直感的だったわけではないと述べている
- 複雑なアルゴリズムを説明するには依然として時間が必要で、作者自身も再検討の過程で難しさを感じた
BobのPrimeGenerator2リファクタリング
- UBがJohnのコードを少し修正したバージョン
- いくつかのメソッドをさらに分割し、「後続のリファクタリング」を適用した
- ループ部分の可読性は高まった一方で、性能低下が一時的に発生した
- Johnは「小さすぎるメソッドへの分割は性能問題を招くことがある」と指摘し、UBは再度修正して性能を改善した
- ただし、コメントは最小限にしたいというUBの好みのため、Johnは依然として「説明をもっと加えたほうが理解しやすい」という立場を保っている
Test-Driven Development
- UBは、短いサイクルで先にテストを書き、失敗するテストを通すためのコードを少しずつ追加していくTDD方式を強く推奨する
- この方式により、コードは常にテストカバレッジを維持し、複雑なデバッグを避けられると主張する
- コードは頻繁にリファクタリングされ、段階的にクリーンになるという立場である
- Johnは、TDDが過度に「戦術的アプローチ」に流れることを懸念する
- 「設計が先行すべきなのに、TDDは先にコード（テストのための最小実装）を書かせる方向に導く」という指摘である
- 良い設計では、もう少し広い範囲を一度に考え、そのコードに対するテストをまとめて書く（bundling）ほうがよいと考える
- UBは、「TDDの誤った適用によって生じる問題」はありうるが、正しく実践すればテストカバレッジと再設計（リファクタリング）に役立つと主張する
- Johnは、「TDDは初心者にとって、かえってコードが急速にぐちゃぐちゃになる危険が大きい」と懸念を示す
- 最終的に2人は、「TDDもbundlingアプローチも、うまくやればどちらも優れたコードを生み出せる」ことには同意しているが、どちらがより良いかについては立場が異なる
結び
- John:
- 『Clean Code』は、小さすぎる関数分割とコメント抑制を強調しすぎており、読者が極端に追従してしまう危険があると懸念している
- 十分なコメントがなければコードは理解しにくくなり、結果として開発者がより多くの時間を費やすことになる
- TDDについても、大局的な設計を見失うおそれがあると指摘する
- UB:
- 『Clean Code』第2版である程度補完し、Johnの意見も一部取り入れたと述べている
- 異なる経験と観点を尊重しつつ、最終的には「誰もがクリーンで保守しやすいコードを目指すべきだ」という共通点を強調する
- 結論として、2人はソフトウェア設計の重要性と「コードを読みやすくすること」を最優先の価値に置いている
- ただし、メソッド分割の基準、コメント活用の方法、テストを書く順序などでは立場の違いがある
- 要点は、チーム環境とコード構造に合わせてバランスを取り、設計を継続的に改善しようとする努力が必要だという点である
14件のコメント
クリーンシリーズの本を何冊か持っていますが、メタ認知的なレベルで参考にするくらいがちょうどいい気がします。原則や法則のように振る舞うとものすごく疲れるし、実用的でもありません。いつもSOLID原則を語るアンクル・ボブですが……個人的には実用的な内容はそれほど多くないと思います。
Code CompleteとClean Codeは、過大評価された本ランキングで同率1位だと思います『ソフトウェア哲学』は翻訳版が出ていますか？ 検索してみましたが、見つけられませんでした。
逆説的ですが、良いコードとはこういうものだという本よりも、保守しにくいコードの書き方のような反語的な本のほうが、かえってすっと頭に入ってきそうです。
最近はクリーンコードそのものより、特定の技術スタックやアーキテクチャの信奉者が、それを導入しないと大変なことになるかのように語るせいで、そちらのほうで多く言い争ってきた気がしますね。状況を見て適用するのが正しいのであって、無条件に良いものはないのだと思います
素晴らしい議論ですね。
私もそういえば、ジュニアたちにはJohnの philosophy of sw design は勧めても、clean code は特に勧めていませんでしたね。
何であれ見出しだけを盲目的に追うのではなく、文脈をよく理解して適用することが重要だと思います。
コーディング系の自己啓発書は、技術や実装方法に対する価値観がまだない初級者には悪くないものの、経験を積むほど効用は薄れていくと思います。すべてのプロジェクトや環境に当てはまる絶対的な真理はありませんし、一般論が通用しない状況もあるからです。ほかの一般的な分野の自己啓発書の助言と同じように、適度に距離を置きつつ状況に合う助言だけを取り入れ、盲目的に助言を追い求めないほうがよさそうです。
Johnの言葉にもう少し共感します。
重要なのは、二人の言葉をドグマのように無条件で従うのではなく、なぜそうなのかを理解して前に進むことではないかと思います。
クリーンコードは目的ではなく手段であることを忘れてはいけないのです
やはり、ほどほどが大事ですよね
有益です 👍🏻
Hacker Newsの意見
特定の事柄について非常に教条的になる人がいる。こうしたものを福音のように受け入れる理由が理解できない
Uncle Bobの勧めを盲目的に従うプロジェクトを経験すると、その価値がどれほど低いかわかる
Clean Codeは、優れたソフトウェアエンジニアの道具箱の中の一つにすぎない
関数が再利用されたり論理的に意味を持つときに分離するのではなく、単に近くにある行をまとめて「リファクタリング」する人もいる
コメントの重要性について触れていない重要なケースがある
"A Philosophy of Software Design"を強く勧める
Clean Code運動以前の、ソフトウェア業界の実際の問題に対する反応だった
Bobのコメントに関する意見は奇妙だ
Uncle Bobの本は、時間が経つと卒業していくものだ
Clean Codeという名前そのものへの不満がある