重构

什么叫重构？

百度百科上说：重构就是通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。

改代码是行为，质量性能的提高是愿望。

实际上改代码未必能使软件变得更好，也可能软件大规模改动之后，反而变得更差了

故重构的也的将就方法和技巧

 

1.不懂重构，为了重构而重构

那么重构是什么，它解决什么问题呢？

所谓重构是对软件内部代码及其结构的调整，期望改善代码质量，促使程序设计架构更趋合理。说白了，重构解决的就是代码和代码结构的问题，它开始自坏味道，其目标就是要消除坏味道，消除那些“不合我意”的因素，让代码的意图更清晰。

Martin在《重构》一书中提到了22个常见的代码坏味道，都可以作为我们重构的目标，来指引我们的重构。如：

• 消除同一类两个方法之间的重复代码

• 消除某一类中的长方法

• 重命名

• 删除A类中的死代码

• 简化复杂的条件语句

同时，重构的范围也应是那段坏味道的代码，在重构过程中对其，也仅对其进行修改。

 

2.一些常用的技巧

。在《重构》一书中Martin明确提出了68个代码级别的重构手法，这些手法都是等价的。在重构的过 程中即使错了也没关系，都可以安全回退，重新开始。其中比较常用的手法就是桥接，如当我们要删除一个方法的时候，会新添加一个方法，然后将它的引用逐一的 迁移过去，直到旧方法成为孤岛，就可以将它删除了。它能保证重构前与重构后的程序代码功能完全一致，从而实现安全重构。

 

 

3.不要没有策略，一味地追求完美主义

重构过程中，经常出现为了消除一个坏味道，改了A类的方法，又改了B类的变量，不得不改了C类；最后发现这三者之间还有依赖，导致进行不下去了，波及面越来越广，时间越来越长，项目经理在催，最后不得不放弃所有的代码。

调整一个正在运行中的系统也如治国，不要期望一次性调整到漂亮的代码或架构，而是要遵循“小步前进”的方法。从问题着手，每次重构一小步。针对一个 问题有目的修改，修改完后测试，测试通过后提交代码，再进入下一轮重构。如果在改动过程中发现了其他需要修改的地方，不要顺便重构，你可以把它记下来，作 为下一轮重构的内容。

这种做法在代码和模块层面都是相对比较容易实践，而针对架构层次的调整就相对比较复杂。这也是很多架构师需要去思考的问题，如何渐进式重构。不搞一下子半年一年的重构，而是以周以月为单位，快速的迭代，能够很快的验证结果获得收益。

 

4.结果品测于评估

一个可以衡量重构的指标就体现它的价值：能时刻检验我们的成果，确认我们的重构还在解决当初的问题。目前常见的量化指标有如下四类，可供参考。

• 数量：代码的行数

• 质量：代码复杂度、重复读、缩进等级、架构依赖复杂度等

• 时间：花费的天数

• 成本：投资回报率

同时也可以借助于Sonar、Structure101这样的一些成熟工具度量和管理这些结果。

 

4.有较强的理论指导，提过自身的修养

《重构》是Martin和Kent对他们多年以来整理代码的实践的总结，然这背后体现的是他们对软件技术的深层次思考和经验。很多新人执着于学习重构手法而疏于学习背后的心法，有些可惜。

Robert C Martin的《代码整洁之道》和《敏捷软件开发：原则、模式与实践》、《设计模式》、Eric的《领域驱动设计：软件核心复杂性应对之道》、《架构之 美》等都是帮助大家修炼心法的不错选择，他们可以让你更深层的了解代码，更高层面看待系统，锻炼你的嗅觉，提升你的代码能力。

5.不了解上下文，不与团队沟通

   我们不得不承认对代码的重构是有风险的，尤其是模块或架构级别。这段代码的业务是什么，为什么当时这么设计，测试覆盖率是多少，如果这样改会不会影 响到其他模块？对其他角色有什么影响？这些问题都要逐一回答。在风险相对较大的改动更要如此，需要和团队成员，各个角色，包括项目经理和客户进行沟通，谈 论这次重构的好处和风险，获得足够的评估，从而能够做出合适的重构决策，将风险降到最低。

       重构和做其他事情一样，要有目标有方法有策略有结果。我们在进行的时候需要以终为始，不忘本心。最重要的 是要提升技术能力，学习安全重构手法，小步前进，渐进式的重构，不断验证重构的收益，才能迎接一个一个的重构任务，真正的成为清理代码的高手。

希望有帮助！