贝克设计规则

肯特·贝克在 20 世纪 90 年代后期开发 极限编程 时提出了他的四条简单设计规则。我这样表达它们。 [1]

• 通过测试
• 揭示意图
• 无重复
• 最少元素

这些规则按优先级排序，因此“通过测试”优先于“揭示意图”。

其中最重要的规则是“通过测试”。XP 在将测试提升为软件开发中的一流活动方面具有革命性意义，因此测试在这些规则中发挥重要作用是自然的。关键是，无论你对软件做什么，主要目标都是它按预期工作，而测试就是为了确保这一点。

“揭示意图”是肯特表达代码应该易于理解的方式。沟通是极限编程的核心价值观，许多程序员喜欢强调程序是为了让人阅读。肯特表达这条规则的方式暗示着，使理解成为可能的关键是将你的意图表达在代码中，以便你的读者能够理解你在编写代码时的目的。

“无重复”也许是这些规则中最强大、最微妙的一条。它在其他地方被表达为 DRY 或 SPOT [2]，肯特将其表达为“只说一次”。许多程序员已经观察到，消除重复的练习是推动良好设计的强大方法。 [3]

最后一条规则告诉我们，任何不符合前三条规则的东西都应该被删除。在制定这些规则的时候，有很多关于在架构中添加元素以提高对未来需求的灵活性的设计建议。具有讽刺意味的是，所有这些元素的额外复杂性通常使系统更难修改，因此在实践中灵活性更低。

人们经常发现“无重复”和“揭示意图”之间存在一些矛盾，导致关于这些规则应该以什么顺序出现的争论。我一直认为它们的顺序并不重要，因为它们在完善代码时相互补充。例如，添加重复以提高清晰度通常是在掩盖问题，而解决问题会更好。 [4]

我喜欢这些规则的原因是它们非常容易记住，但遵循它们可以改进我在任何语言或编程范式中使用的代码。它们是肯特在寻找普遍适用的原则方面的技能的例子，这些原则足够具体，可以塑造我的行动。

当时有很多“设计是主观的”、“设计是品味问题”的废话。我不同意。设计有优劣之分。这些标准并不完美，但它们有助于筛选出一些明显的垃圾（重要的是）你可以立即评估它们。设计质量的真正标准，“在软件的生命周期内最大限度地降低成本（包括延迟成本）并最大限度地提高收益”，只能事后评估，即使如此，任何评估都将受到一大堆认知偏差的影响。四条规则通常具有预测性。

-- 肯特·贝克