27 | 理论一：什么情况下要重构？到底重构什么？又该如何重构？

重构最难的还是领导不支持

我自从入职到现在一直都是维护老项目。“我很怀念我自己写的代码。"，为什么加双引号了？因为现在的项目代码跟屎一样臭，我自己写的只能说尽量写好点，但是也不完美，完全达不到我心中的目标。为什么呢？因为大环境所致。现在项目已经烂的一P了，结果还没时间给重构的机会。难受的亚匹。我所谓的烂不只是代码烂，就连无用代码也不删掉，都注释掉，git提交comment：123，345，代码开发完不合并到master。这篇文章不是学知识的，是比惨的...... 另外，精选留言越来越少，难受。

我觉得在工作中做好重构，需要有以下几点准备： 1. 领导支持，如果领导不支持，可以试着从非功能需求以及降低运维成本的角度去说服。 2. 重构是渐进迭代的，不是一步到位的。 3. 重构需要有测试用例支撑，没有完善的测试覆盖就去重构，无异于给自己挖坑。 4. 重构需要code review，这不仅是为了保证代码质量，也是很好的团队内技术分享的机会。

不管是重构，开始开发设计，都是为了让代码粒度适中，在理解的范围内。

有时候确实是想重构，边开发边重构，那么也需要测试重新测一下之前改动过的逻辑，这成本不是很高吗？而且测试也不一定会配合你的代码重构而重复去测试。

编程世界也存在热力学第二定律，在自然过程中，熵总是不断增加的。 我自己有一个小项目，随着代码量的逐渐增多，维护起来越来越吃力，用来提防出问题的精力已经超过了开发新功能的精力，所以看到这个专栏时我毫不犹豫就买了。重构我的项目就是我给自己的大作业。 不过，真的不想写单元测试啊😭😭😭

就拿我们公司的系统来说，之前两个团队开发整合，就是因为没有进行好的规范，并且没有进行持续重构，再加上人员的走动，导致之后的人在接手的时候碰到新的需求，也不知道是否有可复用的代码，就直接再写新的接口，最终导致整个系统变得异常笨重，重复的接口越来越多。后来因为要迁移部署环境，进行了一次大型的重构，公司安排了新来的员工来负责，结果业务不熟悉，也就只能按照新部署要求，做了一些简单的调整，代码依旧越来越复杂，所以我觉得持续重构的意识真的很重要，看了争哥的专栏之后，赶紧对以前的代码重新再优化一遍

数据库字段乱复用，对话数据和操作数据放同一个表，接口耦合，大量doEveryThing方法，命名几乎看不懂，层级循环调用。节后要作为公司重点规划的项目去做，五个人一年的开发量。我心里慌得一逼！这种项目是不是该重写了？

我也是像改以前的垃圾代码，进行重构，但现在我们项目中没有单元测试，有点不敢做太多的改动，怕影响功能，是不是重构后需要测试进行一下测试？我只能在修改功能的时候忍不住小重构一下，这样我也不怕引来bug，本来也要测试←_←

前段时间刚重构了一个功能模块。该模块可以说是祖传代码。里面堆砌着各种判断条件，就是所谓的箭头型代码。我接手这个功能重构的 1.把代码读一遍和跑一遍，理解里面的需求。尽量画一个流程图。 2.建立防护网。将需求拆分之后，针对每个拆分的业务点写单元测试。 4.开始重构，解耦逻辑，设计方法的时候尽量让职业单一，类与类之间尽量符合迪米特原则，有依赖关系的类尽量只依赖类的特定方法。我觉得比较基础也是比较重要一点。不要有重复代码。命名要规范，类的各个职业要清晰。重构过程中，其实也要时不时的识别代码的坏味道。尽然是重构，那么肯定要比不重构之前肯定要更好。 5.重构完成之后，通过防护网的测试。 当天重构代码上线之后，基本上没有问题。运行了几天之后有一小段逻辑隐藏的比较深没有写这个逻辑测试，后面补上了一直都没有出过问题了。还是比较稳定的。 我这里只是做了中小规模的重构，后面跟着小争哥继续系统的学习大规模重构，以及重构的技巧和思想。