程序员为什么要重构代码？

Part.1

为什么程序员一言不合就重构代码？

? ? ? ?当你看到前任写成一团毛球的代码块；新添加几行代码需先捋半天逻辑的超级大函数；好不容易在迷宫里找到方向，小心翼翼地增加上新代码，却将别的调使用系统给弄垮时；还有运行缓慢的老系统……

此时程序员只有两个选择：要么忍，要么重构。

? ? ? ?忍是有极限的，重构的“三次法则”表示：程序员第一次看到乱代码可以绕过去，先将手上的代码堆好；第二次再碰上这块，心里虽反感但再一次勉强绕过；第三次一定忍不住动手。

以下的场景是不是很熟习：

测试：这么小的功能，你为什么改动300多个文件？

开发：嘿嘿嘿，我顺便将老代码挪了地方。

测试：你知道这给我添加多少测试工作量吗？那些我都得回归一遍。

开发：不使用测试，没有风险的，我就整理下代码。

测试：你上次也这么说，结果偷偷改了某接口，影响到下游系统。还有那次啊你……

产品：你又在弄重构？我这还有一大堆需求没人开发。

开发：我这的重构系统也非常重要的。

产品：哪里重要了？你白费这么多人力重构，使用户也看不出来系统有什么变化，搞不好还弄坏老功能。求求你别重构了。

开发：我……

? ? ? ?尽管重构不被其余角色认可，但你的程序员同事会了解和感谢你的，重构是优化代码设计，使代码可读性更强。

? ? ? ?只是重构是个大坑，不小心就掉坑里。

Part.2

“等重构完这个系统，我就提离任。”龙哥说。

? ? ? ?因为核心系统初期设计不当，权责界限模糊，只需沾点边的代码都往上堆，造成系统过于庞大，逻辑混乱，一出现问题，造成核心业务瘫痪。

? ? ? ?过老过大过中心的系统像个不定时炸弹，吃过几次亏后，业务组决定拔掉这隐患：将系统重构，按照业务解决逻辑拆分成各功能单一的子系统，降低耦合度。

? ? ? ?大伙把这事当作季度最重要的计划来展开：热火朝天的开会划分系统，梳理代码逻辑，安排测试，公告注意事项。

各人领了任务后，开始埋头苦干起来。

? ? ? ?但是重构系统像从一个大迷宫捋线路，捋的过程耗费巨大，而且极易遗漏。产品后来提的新需求直接在重构后的系统里新添加。开发团队进入恶性循环：新添加功能有的人在老系统分支改，有人在新的改，导致提交的代码分支混乱，搭建过程缓慢，计划的任务delay，最后测试人员发现很多遗漏点，又返工重构。

? ? ? ?大家不断埋头地捋代码，重构，测试，想百分百完美地完成任务，而忽略整体项目进度的把控。

? ? ? ?上线时间从9月份延迟到12月份，再到年后，最终来年6月份系统才上线完成，耗时一年多。

? ? ? ?每个人被重构折磨得疲惫不已，还短时间看不出来效果，可已经投入人力物力，大家只好硬着头皮往下走。后来大家已经想不起当初为什么要重构，究竟要重构到什么样子，只想着这重构何时到头，什么时候才能解放。从重构半年时开始有人离任，到上线时仅剩一个原项目组的产品，他说这项目终于结束，我也该走了。

Part.3

? ? ? ?上面的重构没有正当的项目规划，还犯了重构的大忌：边重构代码边新添加功能，这样相当于将原系统推翻重做，风险极大。

那么该如何正当的安排重构呢？

1.遵循“两顶帽子”重构准则

? ? ? ?在重构时，两个不同的操作分开进行：重构代码和新添加功能。

先在不改变原系统功能的基础上修改现有代码的设计，这样采使用原有的测试方法可以轻松地验证这些修改的正确性。

再在已重构好的基础上添加新功能，使得新功能与老功能正当解耦。

上述例子里，业务组边重构边在上面新开发功能，给测试人员的压力巨大，原有的测试方法全不适使用，添加回归测试工作量。

2.用“小步快跑”的重构策略

? ? ? ?重构避免用“大布局”规划项目进程，假如从整理需求、设计接口、开发联调、测试上线，经历几个月的时间，假如其间有问题，整个团队又得人仰马翻地去调整方向，试错成本过高。“小布快跑”是让我们重构时只关注一个问题点，只处理这一个问题。小改动，小局部优化，耗时短，奏效快。

这便需要我们将重构当作一个习惯，融入在每一次代码修改中。

3.测试驱动开发

? ? ? ?上文例子里将代码的质量保证全丢给测试人员，光是对整个系统接口的性能测试就耗费大半个月的时间，等测试人员将问题列表整理后又得重新改代码，不单白费时间，还可能引入大风险。

? ? ? ?正确的重构姿势是将测试融入在每一次重构中，小步快跑，修改一块代码便自测这块，等调通后再继续往下走。重构有风险，开发测试两手捉。

? ? ? ?《重构》一书里说道：任何一个傻瓜都能写出计算机可以了解的代码，唯有写出人类容易了解的代码，才是优秀的程序员。