重构：开篇

作为《重构计划》的开篇，今天我们一起来探讨关于重构的一些理论，然后我们在后面再介绍一系列的重构手段。

1. 什么是重构

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

先说我的结论，对于百度百科的这个定义，个人认为还不够严谨。首先，重构的前提是在不改变当前代码的业务逻辑下对代码内部结构进行调整；其次，重构的结果并不一定在性能上有很大的提高，相反，有些重构可能还会比重构前的代码性能更低一点。

但总体来说，重构的目的是在不改变代码外部结构的情况下，提高良好的扩展性，降低维护成本，使其更加好理解。

重构与性能优化有很多相似的地方：两者都需要修改代码，并且两者都不会改变程序的整体逻辑和功能。但两者也有差别，重构的目的是为了让代码更加容易理解，更加容易扩展和修改，这可能使程序的性能得到提升，也可能性能不升反降。而性能优化的目的只关心让程序如何运行得更快，占资源更少，最终得到的代码有可能更难理解和维护。

2. 为什么要重构

为什么要重构，重构的重要性相信大家看完下面的一段话就不言而喻了。

大部分的项目团队在初期进展迅猛，且团队成员的工作积极性极高，但当这样的团队发展到三四年的时候，很有意思的一个现象是整个团队的工作效率开始变得慢如蜗牛。每一个功能需求的开发都要影响其他的好几个地方，因为各个模块的耦合度太高，不得不很小心很谨慎的修改。而当这团乱麻越来越大，再也无法理清里面的逻辑，最终束手无策。

而随着混乱的增加，团队生产力也持续下降。而当生产力下降时，管理层就只有一件事可做了：增加更多的人力到团队中，期望提高生产力。可是新员工并不熟悉整个系统的设计，他们搞不清楚什么样的代码符合代码规范。而且，他们以及团队中的每个人都背负着提升生产力的可怕压力。于是，他们制造更多的混乱。

假设你正在经历或者已经经历过我说的这种情况，那么你一定知道，花时间保持代码整洁不但有关效率，还有关生存。

这正是我们为什么要重构的原因，更是因为：

• 重构使得我们的业务逻辑更加容易理解。
• 重构也是在找bug的过程。
• 重构提高开发效率，提高开发质量。

3. 何时重构

所以何时重构，是不是像上面说的，当一个团队项目发展到三四年之后，才考虑进行重构？显然不是。重构应该是无时无刻都在进行的一件事，当我们一而再再而三的做一件事时，那就重构；当我们很难去理解一段看似不复杂的代码片段时，那就重构；当我们觉得这段代码还可以写得更好时，那就重构。

重构不需要安排一个专门的时间，而是在日常工作中很顺其自然的一件事，也应该是一件长期坚持的一件事。不管是添加新功能还是修复bug，重构对我们当下的任务都有帮助。很多人认为新增一个功能最快的方法是此时此刻就开始写这段代码，而更优秀的程序员知道，添加新功能最快的方法往往是先修改现有的代码，使新功能的这段代码能够很容易的加入进来。

4. 重构带来的挑战

重构给我们带来很多的好处，但同时它也带来一些挑战。

重构的唯一目的就是让我们开发更快，用更少的工作量创造更大的价值。但重构也会使我们延缓新功能的开发进度，有一些情况我们确实需要权衡取舍，比如增加这个新功能的工作很小，那么此时就不宜花费几倍的经历去重构，而是先实现功能，再找时间做重构。

不改变程序原有的业务逻辑是重构的一个很重要的特征，我们应该做到百分之九十九的逻辑和原有的保持一致（还有百分之一是万一发现了bug，那就得修复），但应该没有任何人敢百分百保证这件事。所以我们每次重构完，自己都要花时间去写单元测试，如果是改动比较大的话，我们还要专业的测试人员介入做功能测试。

当然重构带来的挑战不只是上面说得两点，但应该没人反对，我们都喜欢赏心悦目的代码。所以……一起加入《重构计划》吧。

——End—— 更多精彩分享，可扫码关注微信公众号哦。