关于重构的一些自我思考🤔

近期新接手的业务线需要对 H5 项目进行升级，所谓的升级在我的认知中是“还技术债”的一种表现，接盘的同学需要对先前开发这个仓库的同学遗留的一些问题进行填坑，同时还要加入一些新的功能和能力。

对于这种升级改造，我在年终总结的时候有说到三点：

  1. 技术债要不要还？
  2. 收益有哪些？
  3. 做加法做减法？

一切以提升能效为导向，一切以提升能效为导向，一切以提升能效为导向。

什么时候要还？

首先当前公司要发力该业务（重获新生），未来很长一段时间内必然会有很多新需求需要开发。这也是我认为最重要和最基础的一点，没有这个背景，升级改造一个旧项目纯属浪费人力。

其次旧代码架构不合理？(事后反思总结)

一开始我觉得代码冗余（新的样式 Token 加入）、能力缺失是一个因素，但经过考虑并不是这样，难道不能删除老旧的冗余代码么？难道不能在老的项目中补齐缺失的能力么？答案是能，所以制约你要不要改的次要因素应该是架构的问题，而这种问题必然会在今后的迭代中以肉眼可见的方式变得不可维护，考虑清楚这个问题才能开始后面的工序。

当前的问题

  • 老版本 Vue2.x
  • 处于维护状态 VueCLI
  • 接口 code 不符合当前团队的规范需要改造
  • 错误兜底页面不符合当前团队规范需要改造
  • 缺少版本控制
  • 冗余代码需要剔除

解决的做法

  • Vue升级到3.x
  • 和后端沟通枚举 Code，并输出文档
  • 与设计同学沟通，完成错误兜底页的开发
  • 增加版本控制
  • 删除冗余代码
  • SDK 升级统一

迁移工作

除了技术层面的改造，还需要开发人力的投入，1人负责整体把控+底层迁移改造，N人（常规业务开发）负责对应功能页面的迁移改造。

实际迁移过程中的优先级

  1. 确保降级方案，能否回滚
  2. 评估迁移过程中涉及的周边依赖（端是否需要改造、接口是否需要改造）
  3. 罗列升级改造点（以页面为改造维度，方便小伙伴直接校对改造内容）
  4. 确定目标技术栈（Vue3 + Vite）
  5. 先行：底层框架变更，api 层，异常监控，性能监控，文件夹结构等设计
  6. 按页面优先级迁移业务逻辑（按访问量大小）
  7. 确定页面开发归属人
  8. 测试人力安排
  9. 排期确认
  10. 持续跟进直至迁移完成
  11. 评估收益 -> 发现问题 -> 解决问题

收益有哪些？

继续回答一开始提出的第二个问题，关于收益，往往我们脑子一热，把框架进行了升级，但实际 Vue2 与 Vue3 在开发上的差距真的不是特别大（这里指的是开发一个常规的活动页面，我们在框架层面耗费的时间）。

举一个极端的反例：假设一个新手只会 Vue2，那么迁移到 Vue3，新手同学需要查文档，边学习边开发，效率低了（开发估时或许会延长，存在着这种可能性，即便新手同学平时已经预习了一遍 Vue3 的文档，但实际开发过程中难免磕磕碰碰）。

但假如是一个熟练工，Vue2 、Vue3 都会，那么以个人经历来说，似乎没啥开发效率的提升？🥱在我浅薄的认知里，没有碰到哪个同学说我用了 Vue3，原本 3PD 的开发时长变成了 2PD。

因此升级可能存在负收益的情况。

那正向的收益有没有？有，但短期内可能很难看到，因为架构升级了，必然在当下这一两年让我们这群开发同学维护的相对比较“爽”（没有银弹，一个再好的架构也只能在特定的时间内是优秀的）。开发“爽”就意味我们能用爱❤️发电，我们发自内心的拥护它，维护它，正向循环。好代码越来越多，代码执行效率高效，设计模式用上，修改 Bug 不用再翻来覆去找人问，看旧代码。嗯，这很理想，也是我们想要的。但依然存在不确定因素，开发者的水平参差不齐，缺乏必要的 Code Review，好架构依然会滋生“烂代码”。

另一方面，在前端，当我们去除了一部分冗余代码后，页面的加载速度必然有一定的提升（当然这种提升不一定有质的变化，可能效果也不是非常明显），但性能仍然是衡量一次升级改造的一个重要指标。

如果是 Boss，相信他在意的是能不能为公司省钱，一分钱办多份事，省钱的方式有很多种，比如将原先 JPG、PNG的大图，换成了 webp，流量下来了省的是真金白银；又比如，原先一个开发要用 3 天开发一个活动，现在只要 1 天就能开发完一个活动，同等的人力可以支持更多的产品 IDEA，这也是一种省钱，也是最最直观的收益。

然而据我观察，绝大多数开发同学，特别是刚开始工作的热血青年最容易忽视收益这个词，喜欢搞新技术，自己 High 的不得了，但是对业务对公司没有多大价值，仅仅是自己单方面觉得这个技术好。

做加法做减法？

推荐优先考虑减法，抛开当下降本增效的大环境，难道用最少的工具就能实现同等的效果是最方便和高效的么？在我的认知里似乎没有哪一个开源项目需要一群人用 A、B、C多个系统来实现开发流的？大多数情况下都是围绕着 Github 提供的服务来完成一系列工作。而不是提个 Bug 就要去 A 系统这样。提个需求就去 B 系统。

个人觉得通过，PR，ISSUE 这些就满足开发工作流了，特别是在测试同学不需要介入的情况下，我们的 Bug、需求 都可以使用 ISSUE，ISSUE 本身就可以标注是 Bug 还是 Feature，而我们提交的 Commit 则可以关联对应的 ISSUE，形成开发生命周期的一个闭环。

以上是我个人对于项目重构的一些思考。