【编者按】本文作者为来自 SoftwareYoga.com 的软件架构师、敏捷与 开发流程践行者 Deepak Karanth，文章主要介绍了 DRY 原则的诸多优点。

本文系国内 管理平台 编译呈现。以下为正文：

“避免重复代码”(DRY) 是软件发展的一项原则，其主旨是减少代码重复现象。

“所有内容写两遍”(WET) 则是上述原则的反义缩写，意指不遵守 DRY 原则的代码。

开发人员应当以其中哪个原则为目标本应是显而易见的。但是，也许这个时候已经有人开始拿出证据来证明我是错的。

在本文中，我们会逐一讨论编写代码时遵循 DRY 原则的好处。首先，我们先举一个简单的例子来说明 DRY 原则的基本优势。

DRY 原则 - 简单例子

假设你的代码中有很多地方需要根据当前用户的角色来执行。比如：只有编辑或管理员才可以执行 createPage() 函数，只有管理员才可执行 deletePage() 函数。

在creatPage（创建页面）和 deletePage（删除页面）函数检查用户的角色时，我们可以使用下面这个 isPermitted() 单一函数，而不是分别开展用户角色检查的逻辑。

//get the current SubjectSubject currentUser = context.getSubject();if (isPermitted(currentUser)) {     //allow execution of deletePage}  else {     //block execution}

将 isPermitted() 的逻辑固定在一个地方，就可以避免重复，同时反复利用代码。另外一个优势就是逻辑的独立性，即 createPage() 和 deletePage() 无需知道如何检查权限。

当然，DIY 原则的优势远不止这样。

DRY 原则的优势

可维护性

DRY 原则的最大优势是可维护性。如果检查权限的逻辑在整段代码中重复很多次，在重复代码中出现的问题将很难修复。修复一段代码中的某个问题后，很容易忘记修复其他重复代码中同样存在的问题。同样，如果需要修改逻辑，就得四处复制粘贴。如果使用不重复的代码，只需在一处维护代码即可。新的逻辑和漏洞修复都只需在一处进行，不必再四处徘徊。通过这种方式开发的软件既稳定又可靠。

可读性高

大多数情况下，遵循 DRY 原则的代码更容易阅读。这并不是因为 DRY 原则本身，而是因为开发人员在代码中投入了更多精力，让它符合一定的原则（比如 DRY 原则）。

重复使用

DRY 原则始终提倡二次利用代码，这是因为我们会将2个或2个以上重复代码实例并入一个代码块。可重用代码缩短了开发时间，因此从长远看，可重用代码是有回报的。

成本合理

如果想说服管理层用更多的时间来提高代码质量，就可以用“成本”这个理由。代码越长，成本越高。代码越长，维护代码、修复漏洞所需的人手和时间也越多。代码越长，开发时间和漏洞也越多，结果就是客户非常不满。无庸赘述。

测试方便

这里我们讨论的是模块测试和集成测试，而不是手动测试。测试时需要覆盖的路径和功能越多，为测试而编写的代码就会越长。如果代码不重复，就只需要测试一个主路径。当然，不同的行为仍然需要接受测试。

注意事项

虽然 DRY 原则好处多多，但还是有几个小缺陷。

1. 不是所有代码都需要整合成一段。有时候2段代码看上去差不多，但却存在细微差异。什么时候应当将代码段整合成一段，什么时候又应当让它们保持分离状态，都需要仔细斟酌。
2. 如果代码太过简略，会让人难以理解。我曾见过开发人员在只有一个代码块实例时，还要贯彻 DRY
   原则。虽然我欣赏他们希望让代码更出色、可重用率更高的想法和远见，但是我只有在需要二次利用代码时才会去遵循 DRY 原则。
3. 人们经常会忽略的是，DRY 原则并不仅仅适用于代码，它还可以同等地应用到数据库设计、文档编写、代码测试等方面。

本文转自

原文地址：