前端架构师应该如何成熟的思考项目重构

这篇文章主要的内容是结合我自己过去十来年的工作经验，为大家分享一下，一个靠谱的前端架构师，应该如何成熟的思考项目重构。

一、现状

由于老项目的重构，对个人能力的要求非常高，特别是主导项目重构的架构师，你不仅要对新的解决方案有充足的把握，还要求你对老项目非常熟悉。除此之外，最难做好的一件事情是： 重构之后不能出现意料之外的问题 ，最怕的就是出现一些重大事故，或者出现一些超出预期的重大技术问题迟迟无法解决而卡住。

基于这样的难度，现状就是，许多大厂的陈年老项目，随着时间的推移，虽然大家都知道技术已经过时落后了，但是还是不敢随意重构。也正因为如此，一个很有意思的现象就是，我的许多学生兴高采烈的进入到大厂之后，看到项目里还在用 jQuery，感觉天都塌了...

二、为什么项目总是需要被重构

这里就会引出一个疑问，既然我们都知道重构这么困难，能不能就在一开始就设计好方案，然后就再也不重构了呢？

当然可以，基本上每一个架构师在项目立项之初，都是带着这个目标在努力的，但是过早的过渡设计，往往会让项目开始变得非常困难。除此之外， 事情是发展与变化 的。这里我们假设大家都拥有较高的编码水平，总能写出高质量的代码。但是即便是如此，随着时间的推移，有许多状况的出现，会导致项目有重构需求。

1、业务需求的调整

一旦现有项目无法满足业务需求，重构项目就会成为一个不得不做的事情。一个成熟有前景的项目，业务必定会不断的进行调整和迭代

因此，成熟的项目架构师往往都随时在为重构项目做准备。以至于有的优秀架构师提出了一个概念叫做 持续重构 。这样的项目往往具备更强的生命力。而许多人试图在一开始就希望自己的项目足够强大以至于再也不要重构，随着时间的推移反而会变成谁也不敢动的屎山代码。

2、项目规模变得越来越大

当项目规模变得越来越大的时候，往往项目会出现预期之外的情况。例如，在刚开始使用 vite 的时候，我觉得项目在开发的时候运行得非常快。以至于我非常惊喜地使用了这个方案。一直用一直用

但是随着项目模块越来越多，我发现情况开始发生了一些变化，项目启动的时候变得很缓慢，还会经常因为缓存内容不更新的缘故我不得不重启项目，让启动缓慢这个点就显得比较突出。因此我最近也在思考 vite 的替代方案

当然，目前使用 vite 我总体上还是比较能接受的。但是如果未来我不能接受的时候，可能我要考虑的问题，要么是找一个 vite 的替代方案，找不到就拆分项目。一旦拆分项目，项目的整个架构逻辑就会发生重大的变化

3、底层基础技术升级

例如，你用的脚手架升级了，react 版本需要升级、vue2 需要升级到 vue3，等等。这些底层技术变得更加先进，高效，都会驱动技术团队有主动升级项目的冲动。老是看着别人在工作中使用最新的技术方案，而你还在使用过时的老技术，你也会变得越来越焦虑。

所以，有的人拼着背大锅的风险，也一定要把基础技术升级上来就是这个原因

三、如何确保自己的项目可以轻松被重构

首先是心态上，优秀的架构师，都应该做好 持续重构 的心理准备。只有持续重构，才不会让问题堆积到一定程度来个大的，到最后即使你使出毕生功力也无法解决技术债务。

而在技术上，保持良好的代码封装，是确保我们的代码总是可以被轻松重构的前提。

简单来说，就是要尽量确保你的代码，在 解耦 上要做得足够好。低耦合甚至超低耦合是每个架构师都应该追求的目标。

在前端里项目中，落实到具体项目中的行为，包括：

1、严格遵循组件化的代码组织结构，这一点，我在 React 知命境的付费文章中有详细的提到过，而不是分层结构。 常规的分层结构会极大的增加重构前端项目的风险。 据我所知，到目前为止，还有大量的前端项目仍然采用了分层结构来组织自己的前端代码，这样的行为容易造成一个模块在无意识的情况下被多个组件使用，从而增加耦合，这些都是反面案例

2、尽量不使用全局状态管理器。是的，很多人想不到吧，费尽心力好不容易各种状态管理器中选了一个所谓的最佳实践，结果我还让你不用才是最好的。全局状态管理器非常容易让代码的耦合变得紧密，从而增加重构风险。因此在项目开发中，能不使用全局状态管理，就不要全局管理。 只有在极个别少数几个状态不得不用时，才应该选择全局状态管理

3、避免过度封装。 封装的最高境界是不封装 。记住这句话，所有都封装行为，都应该以代码是否更容易被维护和重构作为第一优先考虑标准。在许多时候，当你看到的类似的代码，认为应该封装一下的时候，其实有可能，不封装才是更好的选择。

许多时候 冗余重复代码是一种至高的编码境界。 而看到这样的代码就忍不住要去封装一下，反而落了下乘。

4、 学会在性能、功耗等方面做出一些必要的牺牲 。由于被面试印象，许多人在开发的时候，会把代码运行性能当成第一优先准则，这是大错特错的一个观念。在必要的时候，我们要适当的在性能方面做出一些让步。

通常情况下，代码的可维护性是优先级最高的。我们应该在保证可维护性的前提之下去追求更强的性能。而不是为了追求性能牺牲一切。

5、 把设计模式的五大原则融会贯通并运用到项目实践中 。而不是去学习固有的设计模式。是的，这也是大多数人都会走上的一个误区：在具体的设计模式上投入巨大的精力，但是却没有完整的理解设计模式的五大原则。

他们分别是 单一原则 、 开闭原则 、 里氏替换原则 、 接口隔离原则 、 依赖倒置原则

关于他们的详细解读，在我的付费小册《JavaScript 核心进阶》中有分享。

可持续重构的前端项目中，这些设计原则都会被大量运用到。

6、通过编写测试用例，训练自己的这些能力。 低耦合的代码都是容易被测试的 。如果你发现自己测试用例编写困难，那么说明你的代码耦合大概率是比较严重的，通过编写测试用例可以验证和训练自己这方面的能力，通常情况下，到了你的大后期，你就可以不需要编写测试用例了。

四、正确的重构方式

许多人很难成功重构、升级项目的一个重要原因，就是习惯在原有项目上直接修改、升级。折腾了几天，结果项目连正常跑起来都做不到

实际上，最简单并且成功率最高的做法是，在旁边从零开始重启一个项目。把你想要升级的项目架构逻辑先跑起来再说，架子先搭好。

由于我们前面已经确保了自己的代码是低耦合的，因此，当架子搭好之后， 我们只需要把业务代码复制到新项目 ，就代表项目已经重构成功了。低耦合的目的之一，就是为了让代码复制之后能够轻松的正常运行。

无论你是想做项目升级、项目拆分、架构变动等等，这样的方式都是非常轻松的。在时间上的花费也会非常小，出错的概率很低，风险可控。

五、渐进式重构

真实的现状是比较残酷的。往往你进入到一个新团队，面临的情况就是，屎山项目已经颇具规模。

这个时候，由于历史原因重构成本巨大，几乎很难在短时间之内把整个项目都重构好，这些项目甚至全都在使用我刚才说过的反面案例，逻辑混乱，耦合严重。想要低成本重构几乎不可能。

于是许多优秀架构师在这个时候会采用一种策略， 渐进式重构

渐进式重构是一种非常好的方向，但是大多数方案都非常容易拖泥带水，重构不彻底，带来更加严重的技术债务，新老方案同时维护，反而 加剧了团队项目交接成本和维护成本 ，带来更加严重的后果。我知道的有几个团队就是这种情况，招个人进来，学习半年都无法完全 hold 住公司的项目。

这里仅推荐一种方案：服务端监听新需求的路由，重定向到新项目中的页面。

首先在旁边完整的新起一个项目。把新的技术架构都在新项目中跑起来。

然后凡是新的需求，都在新的项目中完成。

最后在服务端做配置，让新需求对应的路由直接访问新的项目。

这样，新项目和老项目就完整的切割开，互不影响。接下来再抽空余时间逐步迁移老项目的模块即可。

六、风险分摊

无论如何，重构都会面临潜在的未知风险。因此在项目中，重构项目千万不能独自私下一个人解决。

一定要学会把重构任务变成团队需求，在正常的开发流程中进行排期完成。 并且要求测试团队介入进行正常需求的测试。

进入正常开发流程，并且测试团队介入可以最大程度上降低重构风险。你也可以通过这种方式将风险分摊给参与到这个流程中的每一个环节中去。

即使出了问题，责任也不是你一个人的。

如果是屎山代码，你是被领导要求重构，则应该提前声明风险，要求团队或者老板做好免责承诺。

七、总结

重构面临的问题可能会非常复杂。因此保持良好的代码习惯，尝试 具备持续重构 的能力，是每一个优秀前端架构师都应该追求的目标。

在 AI 盛行的年代，这一点会变得更加重要，始终保持一个可维护性强的优秀项目架构，能够让 AI 发挥出更强的作用。

否则， AI 也是屎山代码最强有力的生产者 。现在，有的团队喜欢声称自己的项目代码中有 30%，或者 50% 是 AI 来完成的。

这个数据呢，就说明他们团队大概率项目架构不太好，因为如果光说代码量的话，优秀的项目架构下，绝大多数项目代码都是增删改查这种比较简单的普通业务逻辑，按道理来说，AI 至少可以覆盖 90% 以上的场景。

但是如果只覆盖了 50%？那其中的各种痛苦和风险，就只有他们自己能切身体会了。