Neo.Yang的专栏

我要说的模块重构，不是描述具体的怎么拆分函数、怎么拆分上帝类，怎么封装变量，也不是介绍怎么搭建测试框架，构建重构的防护网。这些内容请参考《重构，改善既有代码的设计》、《修改代码的艺术》这些经典著作。我想描述的是如何从头开始做一个模块的重构分析。正好最近在做一个业务模块的重构工作，刚分析完成，趁此机会做一个总结。希望对在做类似工作的IT同仁有一些帮助。 先简单描述一下我做这一个模块重构的背景

说明：本文中描述的工作量是指人天、人月这样的人力投入量。不是狭义的代码量，用例数。 小规模的代码重构，如修改一个变量名，添加一行注释，在软件维护过程中，在添加新功能的时候随手就做了。没有单独做工作量估计的必要。但如果是做一个模块的重构，或一个子系统的重构，一下放倒上万行代码。没有估计，没有计划是不行的。 代码重构不同于新功能开发。它的需求是已经明确的，并且已经有实现代码，也不需要关

笔者惯用的开发语言是C++，和大多软件发人员一样，有代码整洁强迫症。看到一句代码没对齐，看到一个变量命名不考究，总想动一下；看到逻辑混乱的代码也会从心底发出一句Shit ! 当然，绝大多数情况还是克制一下，总要尊重一下代码作者的著作权，要考虑修改对版本造成的风险。  对于我自己编写代码，平时看到不爽的地方，或者函数职责不单一，或者函数名，类名，变量名未表达清楚，在确认不大会引入问题的情况下

如何写好代码注释是一个老话题，可以说一千个程序员就有一千种不同的理解。下面是从我自己工作中所看到的，所听到的，结合自己编码的体会谈一下自己的想法。对代码注释的态度大致有三种误区：注释很重要，每一行代码都要写注释。注释可有可无，为了应付公司的编程规范，QA的审查，开始拷贝一些函数头注释，拷过去什么都不改，连原作者名都不改，只为满足代码注释率的要求。无需注释，代码即注释。第一个种：新员工热情很高