模块融合中的一些思考

0

合久必分,分久必合。

模块拆分通常并非架构RD因重构而自发的,新的业务需求或产品线要求快速上线,从现有成熟模块迁移过来,稍加改动就能实现目标,这常常皆大欢喜。然而,随着不同产品线架构的迭代和调整,两个同源模块的差异越来越大,但各个模块内部似乎仍能保持良好的框架和模块。

也许是RD固有的处女座自虐倾向,或许是对架构统一的偏执,在经过各自发展后的两个模块现在提出融合要求,不管是对人力成本的考虑还是对形成僵尸代码的担忧,总之,一旦融合提上日程,这对两个模块以及负责融合的RD来讲,都是一场灾难。融合是一项吃力不讨好的工作,容易背锅,没有“收益”。

本文是这个悲惨的RD在融合过程中的一些思考和总结(待融合模块10w+代码行)。

1、融合需要对模块有极为细致的理解。

融合需要对两个模块都有较为深入的理解,融合通常由其中一个模块的RD负责,对另一模块并不一定十分了解,那么就需要特别注重融合前期的准备工作。一方面,对模块的架构模型、关键流程、实现方式进行理解和分析(全局);另一方面,对模块的实现细节、内部结构、流程分支进行梳理和记录(细节)。这个过程是十分耗时的,但是对后续融合工作的开展提供了坚实的基础。

2、融合的原则是什么?

融合的原则总结为以下几点:1)能够复用的结构、功能和流程尽量复用,避免添加特有逻辑破坏模块架构的统一性;2)相对独立的流程尽量保持代码的独立性,避免模块后续调整带来的高耦合问题;3)合理屏蔽融合过程中不需要的流程和函数,避免添加一堆if/else,合理利用现有条件空转过滤。

3、推荐的开发方式。

融合常常是一个漫长的过程,同时,在融合过程中模块还会不断进行架构的迭代开发,因为,融合工作推荐采用快速迭代开发方式。开发、测试、上线、开发……,合理划分出每个阶段的边界,不管是对开发者、评审人、QA来说都更加清晰,上线风险也能够有效管控。而被融合的模块在融合工作完成后,再由QA进行全面的系统、性能测试,保证两者的功能均能达到预期。

4、融合对模块的影响。

首先,融合后最基本的要求是原有功能不受影响,相互独立实现各自功能;

需要格外关注的是,待融合的两个模块的性能变化。一般情况下,融合后由于模块中处理流程更加复杂,处理时延会有明显增加;另外,内存使用量、CPU也将会有性能上的损失,一方面要和融合前独立模块时的性能进行比较,另一方面,要考虑如果部署集群也统一运维,集群在接入新流量后是否还能扛住。

图片描述


如果觉得我的文章对你有用,请随意赞赏

你可能感兴趣的

载入中...