【编者按】本文作者为来自 SoftwareYoga.com 的软件架构师、敏捷与 DevOps 开发流程践行者 Deepak Karanth，文章主要介绍了 DRY 原则的诸多优点。
本文系国内 ITOM 管理平台 OneAPM 编译呈现。以下为正文：
“避免重复代码”(DRY) 是软件发展的一项原则，其主旨是减少代码重复现象。
“所有内容写两遍”(WET) 则是上述原则的反义缩写，意指不遵守 DRY 原则的代码。
开发人员应当以其中哪个原则为目标本应是显而易见的。但是，也许这个时候已经有人开始拿出证据来证明我是错的。
在本文中，我们会逐一讨论编写代码时遵循 DRY 原则的好处。首先，我们先举一个简单的例子来说明 DRY 原则的基本优势。
DRY 原则 - 简单例子
假设你的代码中有很多地方需要根据当前用户的角色来执行。比如：只有编辑或管理员才可以执行 createPage() 函数，只有管理员才可执行 deletePage() 函数。
在creatPage（创建页面）和 deletePage（删除页面）函数检查用户的角色时，我们可以使用下面这个 isPermitted() 单一函数，而不是分别开展用户角色检查的逻辑。
//get the current Subject
Subject 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 原则好处多多，但还是有几个小缺陷。
- 不是所有代码都需要整合成一段。有时候2段代码看上去差不多，但却存在细微差异。什么时候应当将代码段整合成一段，什么时候又应当让它们保持分离状态，都需要仔细斟酌。
- 如果代码太过简略，会让人难以理解。我曾见过开发人员在只有一个代码块实例时，还要贯彻 DRY
原则。虽然我欣赏他们希望让代码更出色、可重用率更高的想法和远见，但是我只有在需要二次利用代码时才会去遵循 DRY 原则。 - 人们经常会忽略的是，DRY 原则并不仅仅适用于代码，它还可以同等地应用到数据库设计、文档编写、代码测试等方面。
本文转自 OneAPM 官方博客
