代码健康：不要过早使用 DRY 原则

关注我，每天收获一个新技能!

不过，我建议当你使用这一原则时，请停下来思考一下：重复是否真的是多余的，还是功能需要随着时间的推移而独立发展？  过于严格地应用 DRY 原则会导致过早抽象，使未来的变化变得比必要的更复杂。 

仔细考虑代码是否真正冗余或只是表面上相似。 虽然函数或类可能看起来相同，但它们也可能服务于不同的上下文和业务需求，这些需求会随着时间的推移而不同地发展。考虑函数的用途如何随着时间的推移而变化，而不仅仅是让代码更短。在设计抽象时，不要过早地耦合可能在长期内单独发展的行为。

什么时候引入抽象会损害我们的代码？让我们考虑以下代码： 

右侧的方法似乎违反了 DRY 原则，因为对 Task 和 Payment 的截止日期检查的代码恰好相同。

但是，Task 和 Payment 代表不同的概念，有可能存在不同的逻辑。如果付款日期稍后需要增加新的验证条件，您可以轻松地将其添加到右侧代码中；但是，如果使用左侧代码，那么对 Payment 日期的验证就会更具侵入性。

如有疑问，请将行为分开，直到随着时间的推移出现足够多的共同模式来证明耦合的合理性。

从小规模来看，解决代码重复问题可能要比解决那些因为过早抽象带来的复杂性更简单。在开发的早期阶段，应该容忍少量重复，并等待抽象。

未来的需求往往难以预测。想想“You aren't gonna need it（YAGNI ）“原则。

要么重复将被证明不是什么问题，要么随着时间的推移，它将清楚地表明需要经过深思熟虑的抽象。

原文链接：https://testing.googleblog.com/2024/05/dont-dry-your-code-prematurely.html