Kent Beckが1990年代にエクストリームプログラミング（XP）を開発したときに、シンプルな設計の4つのルールを考案した。私なりに表現したものが以下になる[1]。

  • テストをパスさせる
  • 意図を明らかにする
  • 重複を排除する
  • 要素を最小限にする

ルールには優先順位がある。たとえば「テストをパスさせる」は「意図を明らかにする」よりも優先される。

このルールで最も重要なのは「テストをパスさせる」だ。XPが革新的だったのは、テストをソフトウェア開発におけるファーストクラスの活動に持ち上げたことである。このルールのなかでテストが最も重要な役割を担うのは当然だろう。ソフトウェアで何をするにしても、第一の目的は意図どおりにソフトウェアが動作することであり、テストはそれを確実にするためのものである。

「意図を明らかにする」は、Kentの言葉を借りれば、コードは理解しやすくなければならないというものだ。コミュニケーションはXPの中心的な価値である。多くのプログラマーは「プログラムは読まれるためにある」と主張する。このルールには、コードを理解しやすくするには、コードを書いた意図を表現すべきという意味が込められている。コードを書いたときの目的を読み手に理解してもらうのである。

「重複を排除する」は、おそらく最もわかりにくいルールだろう。これはDRYやSPOT[2]とも呼ばれる概念であり、Kentはすべてのことは「Once and only Once（ただ一度だけ）」言うべきだと表現している。多くのプログラマーが、重複を排除することで優れた設計につながることに気づいている[3]。

最後のルールは、それまでの3つのルールに当てはまらないものは削除すべきというものだ。このルールができた当時は、将来の要求に向けた柔軟性を確保するために、アーキテクチャには要素を追加すべきというアドバイスが巷にありふれていた。皮肉なことに、要素を追加するとさらに複雑になり、システムの修正が困難になり、柔軟性が損なわれてしまうのだった。

「重複を排除する」と「意図を明らかにする」は緊張関係にあるため、どちらを優先すべきかについて議論になることがある。私はコードを洗練させるためにお互いに影響し合うものなので、優先順位は重要ではないと考えている。たとえば、わかりやすくするために重複を追加すると、解決すべき問題を覆い隠してしまうことがある[4]。

私がこのルールが好きなのは、シンプルなのに覚えやすいところだ。また、ルールに従えば、これまでに私が扱ってきたどの言語やプログラミングパラダイムであっても、コードを改良することができる。一般的に適用可能でありながら、行動につながるほど具体的な原則を発見するという、Kentのスキルを示した一例である。

当時は「設計は主観的だ」「設計は好みの問題だ」などという戯言があふれていた。私はそうは思わなかった。設計には「良い設計」と「悪い設計」があるはずだ。その評価基準は完璧なものではないかもしれないが、明らかに悪いものを判別できるし、（こちらのほうが重要だが）すぐにでも評価に使うことができる。設計の真の評価基準は「ソフトウェアのライフサイクルにおいて、コスト（遅延コストも含む）を最小化し、ベネフィットを最大化する」であるが、それは事後的にしか評価できない。評価できたとしても、多くの認知バイアスに左右されてしまうだろう。この4つのルールは予測可能なものである。

– Kent Beck

さらに詳しく知るために

このルールについてはいくつかの表現がある。私が探索する価値があると思うものを紹介する。

謝辞

Kentに記事をレビューしてもらった。彼は有益なフィードバックを送ってくれた。その多くを本文でも使用させてもらった。

注記

1: 権威ある表現形式

このルールにはさまざまな表現がある。Kentが多くのメディアで触れていたり、それを好んだ多くの人たちが自分なりの表現をしていたりするからだ。そのため、ルールの説明もたくさんある。各自が工夫しているからだ。私もそのひとりである。

本家の権威ある表現形式を読みたいのなら、白本の初版の「シンプルな設計」のXPプラクティスのところを読むべきだろう。

  • すべてのテストを実行する。
  • ロジックの重複を排除する。並列したクラス階層などの隠れた重複に注意すること。
  • プログラマーにとって重要な意図をすべて記述する。
  • クラスやメソッドを可能な限り少なくする。

（なお、「すべてのテストを実行する」を削除して、最後のルールを「最小限のクラス」と「最小限のメソッド」に分割したルールもある。これはKentが白本を書きながら改良した初期の表現形式だったと記憶している。）

2: DRYは「Don’t Repeat Yourself（繰り返すな）」の略であり、『達人プログラマー』で紹介されたものである。SPOTは「Single Point Of Truth（単一真実点）」の略である。

3: この原則は、私がはじめてIEEE Softwareに寄稿した設計に関するコラムのベースになった。

4: Kentに記事をレビューしてもらったとき、彼は「コンフリクトが発生する稀なケースでは（私が思い出せるのはテストだけだが）、技術的な指標よりも共感のほうが勝る」と言った。共感について指摘するところが彼のいいところだ。コードを書くときには常に読み手のことを考えるべきだということを思い出させてくれる。

Kent BeckはXPとテスト駆動開発を開発した人物だ。地元の舞台のために生やしたヴィクトリア朝のヒゲを持つ男として常に信頼されている。