DRY原则下区分重复还是巧合

DRY原则（Don't Repeat Yourself）已经深入人心。重复的代码在不同地方出现，是程序隐患之一。比如你因为某个原因修改了其中一处就提交了，那么就会造成没有修改彻底，进而造成问题。但在按照DRY原则对代码进行重构的时候，要谨慎区分重复和巧合。如果不加以区分，仅仅从代码上看重复，随着业务的推进，可能会给你带来更大的问题。

为什么会这样呢？有些时候的代码重复，仅仅是巧合。在时间上，仅仅在某个时间上，这两部分代码看起来差不多。但如果两边业务相差巨大，那么随着时间的推移。这两边代码就变得越来越不相似。如果你按照DRY原则把他们进行了抽象，那么抽象的部分就需要兼容了两块业务。随着时间的推移，两块业务变得越来越不同，你不得不在抽象的业务层进行多种业务的兼容。里面充斥了各种判断代码，用来判断不同业务场景下如何处理。两个或者多个业务通过这个紧紧耦合在了一起。改动一个业务的特性，可能导致另外个业务不可用。

我曾经碰到一个系统。他把系统几乎所有的业务，都抽象为一个“单据”。因此分成了基本单据、销售单据、入库单据等业务层次。最后的业务都从这里一层层继承。看起来似乎是解决DRY原则。但不同单据业务逻辑相差越来越大。导致在每一层都大量代码处理不同业务的各种情况。系统到最后想做一个修改都极为困难，可谓牵一发而动全身。

区分重复还是巧合。最重要的是从业务角度来考虑，这是否是两个不同业务，还是相同业务在不同服务上的体现？如果是相同的业务，那么毫无疑问我们应该把它们放一起，遵守DRY原则。如果不是，还是分开吧，各自考虑自己的。