DRY(Don‘t Repeat Yourself )原则
凡是写过一些代码的程序猿都能够意识到应该避免重复的代码和逻辑。我们通过提取方法，提取抽象类等等措施来达到这一目的。我们总能时不时的听到类似这样的话：”把这些公用的类放到shared项目去，别的项目还要使用。。。“，什么算是公用（重复）的代码？是不是公用（重复）的代码就要放到一个叫shared的地方？
为什么说重复的代码和逻辑会带来问题呢？
你从一个类中复制了一段代码到另一个类中，但是这段代码足够的稳定，百年不变，这样的重复会带来问题吗？
也许不会。
如果这段代码需要时不时的修改，那么你就要花时间去修改所有包含这段逻辑的代码，这样无形中增加了维护成本和发生bug的几率。这时候就要着手消除和抽取重复的代码。
对于消除重复的代码有一个三次法则（rule of three）：
1.第一次先写了一段代码。
2.第二次在另一个地方写了一段相同的代码，你已经有消除和提取重复代码的冲动了。
3.再次在另一个地方写了同样的代码，你已忍无可忍，现在可以考虑提取和消除重复代码了。
这一法则也适应于对重构时机的把握，过早的重构可能会引入新的问题，三次法则给了你一个重构依据。当然，随着你经验的增长，你可能在第二阶段已经能非常有信心的预料到问题所在。
什么样的代码算是重复的？
DRY is about Knowledge一文中给了这样一个实例：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
这两段代码中都有一个相同的方法addProduct，这两段代码算是重复的吗？他们违反DRY原则吗？
作为一个领域驱动的实践者，我们可以从业务的角度来分析这一代码，第一段代码似乎是一个用户在购物，但是我们最多允许用户购买三件商品。在第二段代码的场景中，我们想要给所有用户提供相同的机会并限制用户最大购买数量。
这一分析说明了这两段代码所描述的领域（Domain）、业务（Business）、知识（Knowledge）、边界（Boundary）、职责（Resposibility）不同，这两段代码之所以相同完全属于巧合。对这样的代码进行提取和消除重复是错误的。
我之前待的team维护了一个北美的项目，如果让我指出这一项目最大的设计问题，就是将一些本不应该提取的代码（各种Model、数据访问）抽取到了一个叫做Shared的工程中，这一举动导致开发人员在后期不敢再修改Shared工程中的任何代码，以至于开发人员宁可重新添加一个方法也不敢修改之前的代码。
DRY看似初级人员都要掌握的能力，如果使用不当会造成非常严重的后果，正是因为我维护了这样的项目才有感而发，希望大家引以为戒，当然大家若是有不同的看法可以一起讨论。