你的代码是干的还是湿的?
原创本篇目录
DRY 代码是一种软件原则,代表不要重复自己 (Don’t repeat yourself),其目标是减少代码的重复。DRY原则上是要求系统中的每一部分,都必须单一、明确、权威地表达。其实就是可靠地开发软件、并让开发项目更易于理解和维护。与之相反的,WET (Write Everything Twice) 则是一个厚颜无耻的缩写,表示相反的意思,即不遵守 DRY 原则的代码。
显而易见,程序员写代码时需遵循DRY原则,而尽量避免WET。
在这篇文章中,我们将探讨将 DRY 原则应用于您的代码的好处。首先,我们将从一个简单的例子开始,说明 DRY 原则的基本优势。
我们可以使用一个函数 isPermitted(),而不是在 createPage 和 deletePage 中分散检查用户角色的逻辑,如下所示。
通过将 isPermitted() 的逻辑保留在一个地方,就可以避免重复,还可以重用代码。额外的优势是逻辑分离,即 createPage() 和 deletePage() 不需要知道如何检查权限。
写好一段代码需要时间,但写一段好代码需要更长时间。把优秀的软件设计原则变成习惯,会节省很多开发时间,更利于维护和扩展软件项目。DRY原则,从现在做起吧。
显而易见,程序员写代码时需遵循DRY原则,而尽量避免WET。
在这篇文章中,我们将探讨将 DRY 原则应用于您的代码的好处。首先,我们将从一个简单的例子开始,说明 DRY 原则的基本优势。
DRY示例
假设代码中有很多地方需要根据当前用户的角色执行。例如,createPage() 只能在用户是编辑者或管理员时执行,deletePage() 只能在用户是管理员时执行,等等。我们可以使用一个函数 isPermitted(),而不是在 createPage 和 deletePage 中分散检查用户角色的逻辑,如下所示。
//get the current Subject
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原则,从现在做起吧。
Q: 什么是DRY代码原则?
A: DRY代码原则是"不要重复自己"(Don't Repeat Yourself)的缩写,旨在减少代码重复,提高代码的可维护性和可读性。
Q: WET代码与DRY代码有什么区别?
A: WET代码意味着在多个地方重复相似的代码,而DRY代码则集中相似代码以避免重复。
Q: 应用DRY原则有什么注意事项?
A: 应用DRY原则时,应避免过度合并不同代码,保持代码的可读性和适当的重用性。
评论列表
💍
确实,DRY原则推广到数据库设计也很有意义。
上一页11/1下一页
推荐阅读
敏捷自组织团队真的存在吗?
在团队人员到了一个新的人数规模情况下,需要更理性地看待管理上的各种问题。不做幻想,不走极端,认认真真地总结各种最佳实践和规范,认认真真地贯彻执行,然后再认认真真地迭代它们,不断地做这个破而后立的持续改进。
2023-07-10
2022-12-27 15:30:00
45904

Erin520 





精品资料包
1V1产品演示
免费试用增强功能
专属顾问答疑支持


