代码重构的艺术

原文出自：https://juejin.cn/post/6903054491273625614

什么是重构

所谓重构是这样一个过程：在不改变代码外在行为的前提下，对源代码做出修改，以改进程序的内部结构，从而使代码变得易于理解，可维护和可扩展。本质上来说重构就是在代码写好之后改进它的设计。

重构的目的是什么

首先，重构是时刻保证代码质量的一个极其有效的手段，不至于让代码腐化到无可救药的地步。项目在演进，代码不停地在堆砌。如果没有人为代码的质量负责任，代码总是会往越来越混乱的方向演进。当混乱到一定程度之后，量变引起质变，项目的维护成本已经高过重新开发一套新代码的成本，想要再去重构，已经没有人能做到了。

❝ 劣质代码可能会影响后续优化的效率，从而进一步造成代码劣化；随着时间的推移，这种效应将会导致代码质量大幅下降。破窗效应 (The Broken Windows Theory) ❞

其次，优秀的代码或架构不是一开始就能完全设计好的，就像优秀的公司和产品也都是迭代出来的。我们无法100%遇见未来的需求，也没有足够的精力、时间、资源为遥远的未来买单，所以，随着系统的演进，重构代码也是不可避免的。

何时需要重构

「第一次做某件事时只管去做；第二次做类似的事会产生反感，但无论如何还是可以去做；第三次再做类似的事，你就应该重构.」

添加新功能时重构

「种一棵树最好的时间是十年前，其次是现在。」重构的最佳时机就是在添加新的功能之前。再动手添加新功能之前，我们不妨先考虑一下，如果对现有的代码结构做些微调，是否会使加入新的功能变的容易的多。

❝ 如果你要给程序添加一个特性，但发现代码因缺乏良好的结构而不易于进行更改，那就先重构那个程序，使其比较容易添加该特性，然后再添加该特性 ❞

修改问题时重构

「扫去窗上的尘埃，才可以看到窗外的美景。」修改一个问题时，我们需要先理解代码在做什么，然后才可以着手去修改。这段代码可能是别人写的，也可能时自己写的，但无论如何，当你觉得这段代码逻辑糟糕，需要花费几分钟才能明白其中的含义时，你就要想着如何去重构才可以使代码变的更加简洁直观

有计划的对代码重构

「找寻重构和开发进度中适合自己的平衡点」但有些时候我们在准备重构的时会发现，之前的代码结构和依赖关系错综复杂，这时我们就要考虑当前是否有足够时间去很好的处理这些混乱的代码。尽管重构的目的是加快开发速度，但同时重构也会拖慢软件的开发进度。如果时间充足，那么当下就是进行重构最好的时机。当鱼和熊掌不可兼得的时候，应当保证软件的开发进度不受影响，其次才是进行重构。可以先把需要重构地方记录下来，整理出一个计划，在未来的一段时间内解决掉。

Code Review时重构

「处明者不见暗中一物，处暗者能见明中区事。」 Code Review有助于在开发团队中传播知识，也有助于让较有经验的开发者把知识传递给比较欠缺经验的人。Code Review对于编写清晰的代码也很重要，我写的代码也许对于我自己来说很清晰，但对于别人来说则不然。Code Review让更多人有机会提出有用的建议来对代码进行调整。三人行，则必有我师。

何时不应该重构

「有所为，有所不为。」并非所有的糟糕代码都需要重构，如果你不需要使用到这段代码，那么就不必花心思去重构它。只有你需要理解其中的工作原理时，对其重构才有价值。当然如果重写比重构更容易，那么就不需要重构了。

如何保证重构后程序的正确性

保证代码正确性最好的方法就是进行「单元测试（Unit Testing）」。当重构完成之后，如果新的代码仍然能通过单元测试，那就说明代码原有逻辑的正确性未被破坏，原有的外部可见行为未变。

测试驱动开发是非常完美的方案。但实际上大部分IT公司的程序由于种种原因并没有单元测试。这时需要一些工具用来帮助我们快速扫描代码中的问题。比如可以给代码增加Lint语法检查，使用SonarQube对代码进行质量和漏洞扫描，前端同学还可以使用TypeScript等等。把这些代码自动扫描工具集成到CI里面，可以大幅度减少出现bug的情况。目前我所在部门前端组的一系列产品包括项目，已经把这些功能集成在CI里面的，每次的代码更新，都会触发扫描代码的流程，CI失败就无法将代码合并到开发分支上面。

有了上述这些还不够，在重构完成之后，还要把改动部分的功能完整的自测一遍，以保证程序无误。当自测通过之后，就可以请测试同学来帮忙进行更加完整的测试流程。