ベックのデザインルール

ケント・ベックは、1990年代後半にエクストリームプログラミングを開発していた際に、シンプルなデザインに関する4つのルールを考案しました。私はそれらを次のように表現します。[1]

• テストに合格する
• 意図を明らかにする
• 重複がない
• 要素が最小限である

これらのルールは優先順位に従っており、「テストに合格する」が「意図を明らかにする」よりも優先されます。

ルールの中で最も重要なのは「テストに合格する」です。XPは、ソフトウェア開発においてテストを第一級の活動に高めた点で画期的でした。したがって、テストがこれらのルールで重要な役割を果たすのは当然です。重要な点は、ソフトウェアで他に何をするにしても、主な目的はソフトウェアが意図したとおりに動作することであり、テストはそれを確実にするために存在することです。

「意図を明らかにする」は、コードが理解しやすいものであるべきだというケントの言い方です。コミュニケーションはエクストリームプログラミングの中核的な価値観であり、多くのプログラマーはプログラムは人が読むために存在することを強調しています。ケントのこのルールの表現方法は、理解を可能にする鍵は、コードに自分の意図を表現することであり、それによって読者がコードを書いたときの目的を理解できることを示唆しています。

「重複がない」は、これらのルールの中で最も強力で微妙なルールかもしれません。これは、DRYまたはSPOT[2]としても表現されている概念ですが、ケントはすべてが「一度だけ、一度だけ」言われるべきだと言っています。多くのプログラマーは、重複を排除する行為が優れたデザインを生み出す強力な方法であることを観察しています。[3]

最後のルールは、前の3つのルールに役立たないものはすべて削除する必要があることを示しています。これらのルールが策定された当時は、将来の要件に柔軟性を持たせるために、アーキテクチャに要素を追加することに関する多くのデザインアドバイスがありました。皮肉なことに、これらの要素の余分な複雑さによって、システムは通常、変更がより困難になり、実際には柔軟性が低下しました。

人々はしばしば「重複がない」と「意図を明らかにする」の間に緊張関係があることに気づき、それらのルールをどちらの順序で表示すべきかについて議論につながります。私は常にそれらの順序を重要ではないと考えてきました。コードを洗練する際に互いに影響し合うからです。明快さを増すために重複を追加するようなことは、問題の解決を先送りしていることが多いので、解決した方が良いでしょう。[4]

これらのルールについて私が気に入っているのは、非常に覚えやすいのに、それに従うことで、私が扱ってきたどの言語やプログラミングパラダイムでもコードが改善されることです。これらは、一般的に適用可能でありながら、私の行動を形作るのに十分なほど具体的な原則を見つけるケントのスキルの例です。

当時、「デザインは主観的なものである」「デザインは好みの問題である」といったくだらないことが蔓延していました。私はそれに反対しました。デザインには良いものと悪いものがあります。これらの基準は完璧ではありませんが、明らかなくだらないものを整理するのに役立ちます（そして重要なこととして）いますぐに評価できます。デザインの品質に関する真の基準である「ソフトウェアのライフサイクル全体にわたってコスト（遅延のコストを含む）を最小限に抑え、利益を最大化する」は、事後的にしか評価できず、その場合でも評価は認知バイアスの大きな塊に左右されます。4つのルールは、一般的に予測可能です。

-- ケント・ベック