首先要说一句老话，拷贝是万恶之源，是最差实践之首。
前段时间，组里有个同事实现某个新功能，其实挺简单的，前后大约做了两周。最后在Code Review的时候，发现有很多没调用到的方法和变量，代码逻辑很奇怪，然后发现代码是从另一处Copy过来的，只是稍作加工。再然后，我就让另一名工程师加入一起清理代码，又花了4天才把逻辑理清楚。清理之后的代码比之前少了60~70%，更易于维护。这一切都是Copy Code惹的祸。
为什么拷贝代码？
省工夫省时间？
Copy/Paste, so fast! 这是非常非常短视的想法，甚至有时连短期的工夫和时间都没有节省到。因为老代码里有大量逻辑，不一定拷贝过去可以直接使用。这时必然Bug漫天飞，怎么能过的了QA那关。长远看就更加不可取，无数血泪的经验，大量重复代码是项目的灾难，不可能有好的设计，后期维护的工程师会叫苦连天，工期不断延后，质量只能是垃圾，不要期盼有什么保证。垃圾的代码也留不住好的程序员，学不到任何东西，他们的青春为什么拿来给别人擦屁股。
时间和工夫有时不能省的，要耐着性子看老代码里的逻辑，”慢就是快“。
”某种项目需要“！
还有另一种可能-项目需要！一些稍大的公司或组织会同时进行几个项目，新的项目可能会在老项目的代码上扩展。为了节省工期，有些Team就直接把老项目的代码在新项目的Branch上拷贝一份。开始一切很祥和，可新老项目同时继续，同时在修Bug，加Feature。时间长了，就有可能在不同的代码Branch做Merge，也是要花大量的时间和精力。究其根源有很多，可能真是工期紧，可能是老代码的设计太差。
我觉得设计的问题大一些。这不是理想的做法，应该把需要依赖的代码做提取，对于不同行为做抽象，再以注入等方式改变所依赖代码的行为。
如何避免代码里的Duplication？
- 做为工程师应该了解，Code不单是为别人写的，也是给未来的自己写的。不想六个月之后砸键盘吧！时刻牢记”Duplication is evil!”
- 做好培训，尤其是新手。大多新手带着从学校实验室的“恶习”（想想那些教授老板也被坑的不轻，还不自知），入职后老员工的”传帮带“很重要。
- 鼓励做代码重构，罗马不是一天建成的，代码也不是一天就能变好。
- 制定Team里的Coding Guideline，加强Code Review。大家都知道”破窗理论“，有规则才能遵守，不然只能越来越糟。
- 组织里要有分享代码的意识，多做独立于产品的可复用的代码模块。假以时日就可形成客观的代码“资产”，大大加速日后的开发和团队效率。
- 使用SonarQube实时掌握重复代码的情况。SonarQube是个非常强大的工具，帮助团队实时的监控代码质量的变化，Duplication就是其中的一个维度。
总结
不要拷贝代码。That’s it!
