码农的自我修养-如何做模块重构的方案分析
一、背景
这里说的模块重构，不是描述具体的怎么拆分函数、怎么拆分上帝类，怎么封装变量，也不是介绍怎么搭建测试框架，构建重构的防护网。这些内容请参考《重构，改善既有代码的设计》、《修改代码的艺术》这些经典著作。我想描述的是如何从头开始做一个模块的重构分析。正好最近在做一个业务模块的重构工作，刚分析完成，趁此机会做一个总结。希望对在做类似工作的同行有一些帮助。
二、方案相关人
拿到模块重构方案分析的任务时，我连续问了自己三个问题，并试着自己回答。
1、我首现要搞清楚的是分析需要输出什么？ --模块代码重构分析文档。
2、怎么的输出件才是合格的？--满足输出件各关注方的要求。
3、我的工作输出件谁关注？ -- 部门领导、项目经理、模块维护人员、参与重构实施的其他工程师。
核心归结到第三个问题，我的工作就是为了让他们满意。我又试着细化一下这几类人群的关注点：
部门领导：背负公司级领导的KPI指标。领导关注投入和产出，通俗的讲就是投入多少人力，能达到怎样的效果。领导是不关注具体方案的，你怎么做他不关心，这也不是他擅长的。
项目经理：关注投入和效果，需要说服他投入力量重构是有价值的，且产出大于投入，部分参与重构实现的人力需要从项目组抽取。
参与重构的工程师：会投入模块重构的具体实施和分析，关注具体实施的方案，也关注效果。重构得怎么样影响到大家的绩效。
三、具体分析措施
基于以上的背景分析，我就开始了我的具体分析工作：
1、描述重构模块的背景和范围。
毕竟参与者不是所有人都对该模块很熟悉，先介绍一下模块的核心功能很有必要。再画一个圈：本次重构主要是针对哪一个部分，超出圈之外的部分不在本轮重构的范围内。避免领导后面拿超出工作范围的内容考核你，也避免大家思维发散。
2、重构要达到怎么样的目标。
管理者一般都很关注你的目标，目标具体可量化是很重要的，量化的目标对管理者有两个好处：1：说明你思考过，想法已经比较成熟。2：任务完成后，领导就拿这个目标比对，评价你。省事。但只有量化目标也不够，没有宏图大愿，老大又觉得你格调有点低。所以这块的目标分两部份：
实的：如果公司有代码评价标准，那么重构后的代码满足这个标准的最高标准，这个必须的；有重复代码，重复代码减少多少；输出多少自动化用例，覆盖率是多少。圈复杂度降到多少；输出指导流程，文档等。这些都是实际好衡量的。
虚的：树立什么什么标杆；如何如果发扬光大等等。尽管吹吧。
3、分析一下这个模块的质量状况。
分析一下以往2~3个版本，这个模块的质量状况怎么样。统计一下发现问题数量，代码增长量是怎么样的趋势，折线图，柱状图画一下。这部分就是想说明一下这个模块质量有多糟糕，对部门领导和项目领导说：“你看，这么烂。重构很有必要”，说服你的投资人，投人投钱。说明这个模块已经烂泥扶不上墙，火烧眉毛了，再不重构就要死人了。
人民群众的眼睛是雪亮的。光有数据还不够，再实际采访一下维护过这个模块的同事，新员工，老员工。重点描述一下新员工如果维护困难，添加功能如何痛不欲生，老员工如何痛斥后来人把模块架构搞烂了。云云。
总之就是要告诉相关人，你选这个模块重构是对的，一定要重构，非重构不可。
4、阐述一下模块重构分析的几个方面。每一点的内容比较多，在本章中不展开详细描述，后面开辟独立的文章分析。
4.1、站在模块外面看模块的接口是否清晰
模块作为一个独立的单元，它与周边模块的接口是否清晰。模块提供的接口体现了设计师对它的定位，模块使用的接口描述了它的外部依赖。
4.2、进入模块的里面看层次结构是否清晰
麻雀虽小，五脏俱全。模块大致可分解为消息转发层、业务操作层、数据管理层、实体操作层、底层适配层。常见的问题是接口与实现不分，业务与数据管理不分，外部接口不清晰。
4.3、模块是否有清晰，高内聚的业务领域模型
一个模块是为处理某一特定业务逻辑而存在的。基于这一业务领域构建专属的领域对象模型，对模块的扩展性，可维护行至关重要。以数据为中心的软件设计是面向对象软件设计的核心。可以说是否有一套完备，高效的业务领域建模是模块乃至整个系统成败的关键。
4.4、是否存在完善的自动化测试体系
如果模块已经存在完善的自动化测试机制，模块重构时就能放开手脚。对于某些历史版本不重视自动化的系统，需要搭建自动话框架，补充用例。这部分要考虑到工作量里面。
4.5、代码是否存在超大函数，上帝类
这个不用说，肯定得拆。问题是怎么拆，把大函数拆成小函数不难，难的是把易变的部分与不变的部分分离。
4.6、模块内部是否存在不同的状态
这些状态是否和业务处理逻辑耦合在一起，是否有太多的if else。要想办法把它们分理开来，通过一些多态，策略模式把业务和状态分离开来，让业务不关注状态能更好的重用。
5、工作量估计
尽量详细些，越是大的领导越是关注这一部分。