DRY 代码是一种软件原则，代表不要重复自己 (Don’t repeat yourself)，其目标是减少代码的重复。DRY原则上是要求系统中的每一部分，都必须单一、明确、权威地表达。其实就是可靠地开发软件、并让开发项目更易于理解和维护。与之相反的，WET (Write Everything Twice) 则是一个厚颜无耻的缩写，表示相反的意思，即不遵守 DRY 原则的代码。 显而易见，程序员写代码时需遵循DRY原则，而尽量避免WET。
在这篇文章中，我们将探讨将 DRY 原则应用于您的代码的好处。首先，我们将从一个简单的例子开始，说明 DRY 原则的基本优势。
DRY示例
假设代码中有很多地方需要根据当前用户的角色执行。例如，createPage() 只能在用户是编辑者或管理员时执行，deletePage() 只能在用户是管理员时执行，等等。
我们可以使用一个函数 isPermitted()，而不是在 createPage 和 deletePage 中分散检查用户角色的逻辑，如下所示。
Subject currentUser = context.getSubject();
if (isPermitted(currentUser)) {
//allow execution of deletePage
} else {
//block execution
}通过将 isPermitted() 的逻辑保留在一个地方，就可以避免重复，还可以重用代码。额外的优势是逻辑分离，即 createPage() 和 deletePage() 不需要知道如何检查权限。
DRY的优势
可维护性
使用 DRY 的最大好处是可维护性。如果在整个代码中重复检查权限的逻辑，则很难解决重复代码中出现的问题。当解决了一个问题时，会很容易忘记在其他事件中解决这个问题。此外，如果必须修改逻辑，就需要到处复制粘贴。通过使用非重复代码，只需在一个地方维护代码即可。新的逻辑和错误修复可以在一个地方而不是多个地方进行。这可以带来健壮和可靠的软件。
可读性
通常情况下，DRY 代码更具可读性。这并不是因为 DRY 原则本身，而是因为开发人员在代码中付出了额外的努力，使其遵循更多代码规范、代码可读性的原则。
重用
DRY 本质上促进了代码的重用，因为我们正在将 2 个或更多重复代码实例合并到一个代码块中。从长远来看，可重用代码是值得的，因为它加快了开发时间。
测试
这里说的是单元测试和集成测试，不是手工测试。使用测试覆盖的路径和函数越多，要为测试编写的代码就越多。如果代码不重复，只需要测试一条主路径即可。当然，不同的行为仍然需要进行测试。
DRY注意事项
尽管使用 DRY 有所有优点，也要注意一些使用细节：
- 并非所有代码都需要合并成一个片段。有时两段代码看起来相似但有细微差别，那么何时将这些代码合并为一个，何时将它们分开需要仔细考虑。
- 如果代码“过度干燥”，就会变得难以阅读和理解。有时仅有一个代码块实例还试图应用DRY原则，，虽然很欣赏他们使代码更好和可重用的想法和远见，但在需要重用它的情况之前，并不需- 要费心让代码遵循 DRY 原则。
- 经常被遗漏，DRY 不仅仅局限于代码。它同样适用于数据库设计、文档、测试代码等。
写好一段代码需要时间，但写一段好代码需要更长时间。把优秀的软件设计原则变成习惯，会节省很多开发时间，更利于维护和扩展软件项目。DRY原则，从现在做起吧。
