DRY原则下区分重复还是巧合
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
老邓聊开发
扫码关注公众号
扫码阅读
手机扫码阅读
DRY原则(Don't Repeat Yourself)强调避免代码的重复,但在实践中,区分真正的重复与表面的巧合性重复非常重要。不恰当地应用DRY原则,将外表相似的代码片段抽象化,可能会随着业务的发展导致更多的问题。
代码的重复有时仅是暂时的巧合,尤其是当两部分代码服务于迥然不同的业务逻辑时。随时间推移,业务发展导致原本相似的代码逐渐背离,若早期根据DRY原则进行抽象,可能会造成这些业务逻辑强制捆绑在一起。这种耦合导致后续的业务修改变得复杂,因为任何一个业务的改动都可能影响到另一个。
例如,将不同业务逻辑的“单据”抽象化,最初看似解决了重复问题,但随着业务的差异化发展,导致在处理不同单据时必须编写大量特定的代码,最终使得系统变得难以维护和更新。
在应用DRY原则时,关键在于从业务角度判断是否面对的是真正的重复,还是仅仅是巧合的相似。对于确实属于相同业务的重复代码,应当遵循DRY原则进行合理抽象。而对于巧合性的重复,更明智的选择是保持它们的独立性,分别处理,以避免未来潜在的耦合问题。
老邓聊开发
老邓聊开发
扫码关注公众号
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
老邓聊开发的其他文章
成本效率还是业务响应
在一次敏捷的活动中,有个小伙伴提了一个问题想让大家帮他参考:为什么他的团队里都不愿意听他的。经过详细
如何提升代码质量
好的代码都有一些共同的特征,如可读性、较少的方法行数、高内聚低耦合、职责单一。但这只是一个结果,作为一个工程
软件项目中几大幻觉
幻觉一:需求分析完成了产品辛辛苦苦花了很长时间对用户需求进行分析,画了原型图、出了PRD文档,长出一口气,总
解决产品经理和开发团队撕逼
有个问题很有趣:有一块蛋糕两个人分,如何保证公平?很简单的答案是,让切的人后选。那么,在开发团队中,产品经理
敏捷退化
敏捷已经不是个新鲜词了,现在很多团队都实现了某种形式的敏捷。Scrum是其中最为流行的一种方式。但随着时间的
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线