合久必分，分久必合。
模块拆分通常并非架构 RD 因重构而自发的，新的业务需求或产品线要求快速上线，从现有成熟模块迁移过来，稍加改动就能实现目标，这常常皆大欢喜。然而，随着不同产品线架构的迭代和调整，两个同源模块的差异越来越大，但各个模块内部似乎仍能保持良好的框架和模块。
也许是 RD 固有的处女座自虐倾向，或许是对架构统一的偏执，在经过各自发展后的两个模块现在提出融合要求，不管是对人力成本的考虑还是对形成僵尸代码的担忧，总之，一旦融合提上日程，这对两个模块以及负责融合的 RD 来讲，都是一场灾难。融合是一项吃力不讨好的工作，容易背锅，没有“收益”。
本文是这个悲惨的 RD 在融合过程中的一些思考和总结（待融合模块 10w+ 代码行）。
1、融合需要对模块有极为细致的理解。
融合需要对两个模块都有较为深入的理解，融合通常由其中一个模块的 RD 负责，对另一模块并不一定十分了解，那么就需要特别注重融合前期的准备工作。一方面，对模块的架构模型、关键流程、实现方式进行理解和分析（全局）；另一方面，对模块的实现细节、内部结构、流程分支进行梳理和记录（细节）。这个过程是十分耗时的，但是对后续融合工作的开展提供了坚实的基础。
2、融合的原则是什么？
融合的原则总结为以下几点：1）能够复用的结构、功能和流程尽量复用，避免添加特有逻辑破坏模块架构的统一性；2）相对独立的流程尽量保持代码的独立性，避免模块后续调整带来的高耦合问题；3）合理屏蔽融合过程中不需要的流程和函数，避免添加一堆 if/else，合理利用现有条件空转过滤。
3、推荐的开发方式。
融合常常是一个漫长的过程，同时，在融合过程中模块还会不断进行架构的迭代开发，因为，融合工作推荐采用快速迭代开发方式。开发、测试、上线、开发……，合理划分出每个阶段的边界，不管是对开发者、评审人、QA 来说都更加清晰，上线风险也能够有效管控。而被融合的模块在融合工作完成后，再由 QA 进行全面的系统、性能测试，保证两者的功能均能达到预期。
4、融合对模块的影响。
首先，融合后最基本的要求是原有功能不受影响，相互独立实现各自功能；
需要格外关注的是，待融合的两个模块的性能变化。一般情况下，融合后由于模块中处理流程更加复杂，处理时延会有明显增加；另外，内存使用量、CPU 也将会有性能上的损失，一方面要和融合前独立模块时的性能进行比较，另一方面，要考虑如果部署集群也统一运维，集群在接入新流量后是否还能扛住。