Beck 設計規則

Kent Beck 在 1990 年代後期開發 ExtremeProgramming 時，提出了四項簡單設計規則。我以這種方式表達它們。 [1]

• 通過測試
• 揭示意圖
• 不重複
• 最少元素

這些規則的優先順序，因此「通過測試」優先於「揭示意圖」

這些規則中最重要的規則是「通過測試」。XP 在軟體開發中將測試提升為一級活動的方式具有革命性，因此測試在這些規則中扮演著重要的角色。重點在於，無論您對軟體執行什麼其他操作，主要目標都是使其按照預期運作，而測試的存在就是確保這件事發生。

「揭示意圖」是 Kent 表達程式碼應該容易理解的方式。溝通是極限程式設計的核心價值，許多程式設計師都強調程式是供人閱讀的。Kent 表達這項規則的方式暗示，啟用理解的關鍵在於在程式碼中表達您的意圖，以便您的讀者在撰寫程式碼時了解您的目的。

「不重複」可能是這些規則中最有力且微妙的規則。它是一個在其他地方表達為 DRY 或 SPOT [2] 的概念，Kent 表達它的方式是說所有事情都應該「只說一次」。許多程式設計師都觀察到，消除重複的練習是驅動出良好設計的有力方法。 [3]

最後一項規則告訴我們，任何不符合前三項規則的事物都應該被移除。在制定這些規則時，有許多設計建議圍繞著在架構中新增元素，以增加未來需求的靈活性。具有諷刺意味的是，所有這些元素的額外複雜性通常會使系統更難修改，因此在實務上靈活性較低。

人們常發現「沒有重複」和「揭示意圖」之間存在一些緊張關係，導致關於這些規則應以何種順序出現的爭論。我一直認為它們的順序並不重要，因為它們會互相影響，進而改善程式碼。例如，為了增加清晰度而增加重複，通常只是掩蓋問題，而更好的做法是解決問題。[4]

我喜歡這些規則的原因在於它們非常容易記住，但遵循它們可以改善我使用過的任何語言或程式設計範例中的程式碼。它們是 Kent 在尋找一般適用且具體到足以塑造我的行為的原則方面的技能的一個例子。

當時有很多關於「設計是主觀的」、「設計是品味問題」的胡說八道。我不同意。有更好的設計和更差的設計。這些標準並非完美，但它們有助於整理出一些明顯的廢話，而且（重要的是）你可以立即評估它們。設計品質的真正標準「最小化成本（包括延遲成本）並最大化軟體生命週期中的效益」，只能在事後評估，而且即使如此，任何評估都將受到一大堆認知偏見的影響。這四個規則通常具有預測性。

-- Kent Beck