---

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

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

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

何时需要重构

---

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

添加新功能时重构

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

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

修改问题时重构

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

有计划的对代码重构

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

Code Review时重构

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

何时不应该重构

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

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

---

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

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

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

❝ 为什么要进行这么严格的测试流程，因为要保证程序可靠性。如果一件事有可能出错，那么它一定会出错。❞

需要重构的Bad Code

---

糟糕的命名

整洁代码最重要的一环 就是好的名字，所以我们要深思熟虑如何给函数、模块、变量和类命名，使它们 能清晰地表明自己的功能和用法。

无意义的注释

学会只编写够用的注释，过犹不及，应当重视质量而不是数量

多层的if语句嵌套

if-else在程序设计中是不可避免的，作为程序员能做的就是减少嵌套，提升代码的可阅读性和质量

很酷却不宜理解代码

上面这种写法看起来是不是很酷，但是过一段时间再来看，你还能一眼看出这部分功能是做什么的吗？在我刚接触后端，使用python的时候写过这样的代码，结果就是在排查问题的时候相当头疼。代码写的别人看不懂并不厉害，而是写的谁都看的懂才是厉害。

❝ 调试在一开始就比编写程序困难一倍。因此，按照定义，如果你的代码写得非常巧妙，那么你就没有足够的能力来调试它。柯林汉定律 (Kernighan’s Law) ❞

不必要的继承写法

继承虽然是面向对象的四大特性之一，使用继承可以解决代码复用的问题，但也有其缺点: 继承层次过深、过于复杂会影响到代码的可维护性。如果子类中有方法依赖于父类中的 方法或属性，那么当父类发生改变时，子类很可能会发生无法预知的错误。

而组合的方式是把类中所有的接口功能单独实现，然后使用这些单独的对象组合在一起，完成和目标类一致的功能。继承是用来表示类之间的 is-a 关系,而组合是一种 has-a 的关系。使用组合+接口+委托的方式可以代替大多数的继承场景。

重构代码的设计原则

---

开闭原则 (The Open/Closed Principle)

❝ 实体应开放扩展并关闭修改。❞

实体（可以是类、模块、函数等）应该能够使它们的行为易于扩展，但是它们的扩展行为不应该被修改。

里氏替换原则 (The Liskov Substitution Principle)

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）

最后

资料过多，篇幅有限，需要文中全部资料可以点击这里获取前端面试资料PDF完整版！

自古成功在尝试。不尝试永远都不会成功。勇敢的尝试是成功的一半。

[外链图片转存中…(img-TlTGHMwR-1713007709161)]

[外链图片转存中…(img-gte7uDjS-1713007709161)]

资料过多，篇幅有限，需要文中全部资料可以点击这里获取前端面试资料PDF完整版！

自古成功在尝试。不尝试永远都不会成功。勇敢的尝试是成功的一半。