Clean CodeとA Philosophy of Software Designの共通点と相違点

Clean Codeの著者:Robert C.Martin氏（以下、UBと呼ぶ）とA Philosophy of Software Designの著者:John K. Ousterhout氏（以下、JOHNと呼ぶ）の対談がGitHubで公開されていた。そこで、両者の言い分を整理してみる。

TL;DR

両者ともに 「開発者が理解しやすいコード書こう」という点において認識は一致している。ただ、アプローチが異なるだけ。

共通点

• モジュール化は重要である
• コードの可読性を向上させることが重要である

相違点

1.全体的な設計哲学

JOHN

• ソフトウェア設計の目標は、理解と変更を容易にすること
• 複雑性（Complexity）を減らすことが最優先
• 開発者が頭の中に保持しなければならない情報の量を減らすこと
• 重要な情報がわかりやすく、すぐアクセスできる状態にすることが望ましい

UB

• ソフトウェア設計の目標は、コードリーディングを楽にする
• 開発者は、コードを読むことに一番時間を費やしている
• 他者がスムーズに理解できる設計が望ましい

2.メソッドの長さ

JOHN

• メソッドの長さは単純な基準ではなく、「深さ」が重要
• 深いメソッドはシンプルなインターフェースで多くの機能を提供する
• メソッドを短くしすぎると情報が分散し、かえって理解しづらくなる
• 「One Thing Rule」は曖昧で、場合によっては過度な分解につながる

UB

• メソッドは、できるだけ短くする
• 短いメソッドは理解しやすく、適切な命名により意図が伝わりやすい
• if文やwhile文のブロックは1行の関数呼び出しにすべき
• 極端に短くする必要はなく、適切な「One Thing Rule」の適用が重要

3.コメント

JOHN

• コードでは表現できない情報（意図、背景、暗黙的なルールなど）を伝えるためにもコメントが必要
• コメントがないと、抽象化やインターフェースの理解が困難
• コメントの陳腐化リスクよりも、情報不足による時間の浪費のほうが問題

UB

• 適切なコメントよりも適切なコードを書くべき
• コメントの多くは不要で、陳腐化し誤解を招く
• 有益なコメントなら残すべき

4.テスト駆動開発（TDD）

JOHN

• TDDは設計を軽視するため、最適な設計を生みにくい
• 戦略的な設計が後回しにされがちで、悪いコードが積み重なりやすい。
• バンドル方式（コードをある程度書いたあと、まとめてテストを書く）ほうが設計を重視できる
• TDDでリファクタリングを怠ると設計が崩れる

UB

• TDDは設計を妨げるものではない、むしろサポートする
• TDDは常にリファクタリングが行われるため、設計が自然に改善される
• テストが徹底され、結合を減らし、設計の質を高めることができる
• バンドル方式でも良いが、TDDのほうがバグを早期発見しやすい

感想と自分の考え

両者ともに同じ方向を向いているにも関わらず、アプローチの仕方に違いがある。また、Robert C.Martin氏は理想論、John K. Ousterhout氏は現実論でいった印象を受けた。私はどちらの原典も読んでいないため正確な判断はできないが、対談を読んだだけでも双方の言い分は理解できるし、納得感もあった。

結局、「場合による」としか言えないのかもしれない。

「お前ならどうする？」と聞かれた場合、いろいろ考えたすえに以下のように答えるだろう。

1. 設計哲学

• 可読性、変更容易性を重視する
• 文章を読むようにコードが読めるようにする
• 「適切な命名」ができれば「適切な設計」になる（それが最も難しい）

2. メソッドの長さ

• 短すぎるメソッドは、メソッドではなく説明変数を使いたい
• 意味のある塊で戻り値を返せる程度の長さに分割したい
• シンプルなインターフェースにすることで、文章のように読める

3. コメント

• 基本的にコメントは不要派
• 「Why」、または「Why not」はコメントを書きたい
• 「How」は、AIが教えてくれるのでいらない
• コメントを書くなら、アノテーション（TODO:やNOTE:、FIXME:など）でなぜコメントを書いているかを示したい

4. TDD

• 理想はTDDだが、現実はバンドル方式をとってしまう
• Utilityのような汎用性の高いコードは、インターフェースこそ命なのでTDDで開発したい
• Domainに関する複雑なコードは、ある程度コードを書いて、頭の中を整理してからテストを書きたい