这里所提的代码复用，是指编写可以在项目内复用的公共代码或者创建可以跨项目复用代码的独立代码库。我们常理所当然的认为重复的代码应该被复用，有利于后续维护，因为功能变化或bugfix时只需要改动一处代码。而当面临技术决策时，很少思考代码复用的代价是什么。
第一，编写公共代码或代码库特别耗时。公共代码或代码库需要更多的精力来打磨，包括文档、单元测试以及设计理念的思考，需要耗费几倍的精力才能使其达到良好运行、方便拓展的状态。根据项目经验总结，并参考《人月神话》，编写可复用代码需要3倍编写普通代码的时间。所以我们不会在项目最紧张的时候讨论把业务逻辑抽取出来做一个通用的框架，原因很简单：时间不够用。
第二，编写公共代码或代码库需要更有经验的开发者。编写普通代码，我们只需要解决当下的问题，而编写公共代码或代码库，我们却需要预测未来，在做接口设计时需要为未来的可能性预留足够的拓展空间，即使很有经验的开发者也只能基于过去推测未来，而往往会出现各种各样的意外。
第三，业务逻辑本身要有极强的功能收敛性才能提取为公共代码或代码库。良好的接口设计需要业务逻辑的边界可以清晰的被定义，不能无限拓展。
提高代码质量，方便后续维护，往往是我们决定复用代码时理所当然的理由，但我们还需要在“single source of truth”的理想情怀之外考虑现实的问题。大多数情况，项目最终目的是能按时交付符合需求的产品，而不是代码质量。而编写可复用的代码，大多数情况下甚至连代码质量都不能提高。请思考，当考虑代码复用的时候，有没有投入3倍的精力来打磨和思考，有没有足够的文档和单元测试做支撑？ 有没有经验更丰富的开发者来执行？我见过很多不良设计的可复用代码，最终会给项目带来很负面的影响。所以，是否要编写可复用代码，需要权衡时间、资源和所要解决的问题本质，谨慎作出决定。而大多数情况下，copy不失为最明智的选择。
参考文章：
-
code-reuse-or-redundancy：www.innoq.com/en/blog/cod…
-
decoupling-or-learning-to-live-with-code-redundancy：medium.com/@lgelfan/de…
