DRY原则（Don't Repeat Yourself）已经深入人心。重复的代码在不同地方出现，是程序隐患之一。比如你因为某个原因修改了其中一处就提交了，那么就会造成没有修改彻底，进而造成问题。但在按照DRY原则对代码进行重构的时候，要谨慎区分重复和巧合。如果不加以区分，仅仅从代码上看重复，随着业务的推进，可能会给你带来更大的问题。
为什么会这样呢？有些时候的代码重复，仅仅是巧合。在时间上，仅仅在某个时间上，这两部分代码看起来差不多。但如果两边业务相差巨大，那么随着时间的推移。这两边代码就变得越来越不相似。如果你按照DRY原则把他们进行了抽象，那么抽象的部分就需要兼容了两块业务。随着时间的推移，两块业务变得越来越不同，你不得不在抽象的业务层进行多种业务的兼容。里面充斥了各种判断代码，用来判断不同业务场景下如何处理。两个或者多个业务通过这个紧紧耦合在了一起。改动一个业务的特性，可能导致另外个业务不可用。
区分重复还是巧合。最重要的是从业务角度来考虑，这是否是两个不同业务，还是相同业务在不同服务上的体现？如果是相同的业务，那么毫无疑问我们应该把它们放一起，遵守DRY原则。如果不是，还是分开吧，各自考虑自己的。