DRY 是 Don't Repeat Yourself 的缩写，即不要重复自己

原因

重复代码是开发中经常会遇到一个棘手的问题。发生这样的原因有很多

1. 为了不影响原来同事写的代码，自己又复制了一份（毕竟改别人的代码，出了问题算谁的）；
2. 代码很短，所有自己又写了一遍（3句代码，有必要用个方法吗？最后发现这 3 句代码复制的次数还挺多）
3. 有一段神奇的代码，在线上运行的很稳定，虽然感觉有问题，但不敢改，新做的需求还是复制一份再改吧（随着开发周期和人员变动，这种现象很很常见的）
4. 同一个接口版本迭代后，有个钉子户一直不升级，不得不复制代码保证老接口能用了
5. 项目周期不够了，重构是来不及了，赶紧复制一份改改
   ...

总之原因很多，但最终都导致了相同或者相似代码片段或者逻辑大量重复，难以维护。

重复代码的坏处

代码难以修改

在我工作中接触一个项目，其中计算用户逾期罚金的方法散落在项目各处，为了加一套新的计算算法，开始在项目中全局搜索关键字，当自己感觉已经全部改完的时候，测试开始进行测试。

测试：你这个逾期金额是不是算错了，应该是 xx
我：你抓包看看，从哪里调用的
测试：xxx/xxxx/xxxxx 这个接口，你看下
我：我艹，这里没改，我改下，等下你发布试试

然后陷入了死循环，测试找一处，我改一处

测试：你这逾期应该用老版本的算法，你是不是改错了
我：用老版本吗？我看看。我艹，这里不应该改。

当代码重复多遍时，很难将相似代码全部覆盖，甚至有的代码可能不需要改

代码可读性下降

毕竟重复代码可能只是相似，甚至看上去极度相似，能抓耳挠腮看到峰回路转之后，才知道眼前一片漆黑

无法测试

很难知道哪些重复代码是测试通过的，哪些是没有测试通过的或者疏漏的，甚至你无法分辨哪份复制才是正常的

怎么做

1. 停止重复代码
2. 当代码重复 3 次时，立刻停止并考虑是否需要抽象代码或者做成工具类
3. 对历史遗留代码增加测试程序，梳理逻辑，增加说明文档并通知同事
4. 适当给同事讲解项目，让他们知道原来已经有了 xx 功能，xx 代码，减少因为不了解造成的重复
5. 对于大量重复魔法值使用统一的常量

当然写好代码需要时间，写好代码需要更长的时间

DRY 不仅仅适用于代码，在开发中大量重复的手工操作，能否替换为标准的自动化操作呢？

我是一个头发茂密的程序员，欢迎关注双鬼带单