为什么要重构？
- 开发效率低
- 不好排查问题
- 维护困难
- 不好招人
重构方式
- 框架选型
- 成本评估
- 收益评估
- 测试排期
- 灰度发布
- 错误监控
- 性能监控
找到Web站点的重构案例介绍（三次重构）
第一次重构：引入spa
背景
为了解决页面跳转过程中重新加载doc文档的耗时问题，加快页面跳转后的页面加载，希望引入spa框架。
框架选型
因为当时npm还没现在这么火，开发人员对于外界流行的框架认知不够，所以闭门造车了一款sg框架，基于requirejs和jquery开发的，实现了spa的模式、组件化、懒加载的功能。所以决定将找到项目直接用sg重构。
成本评估
- sg框架的开发培训
收益评估
- 页面打开速度从2秒降至了1秒
测试排期
因为是新项目，功能不多，所以测试时间充裕
灰度发布
无
错误监控
通过前端监控window.onerror来上报错误到php端，在日志机tail观察日志
性能监控
通过开发人员在自己电脑上测试性能，覆盖面几乎为0，所以算不上真正的性能监控
本次重构的问题
- 开发人员的信息闭塞，没有进行框架选择
- sg框架初步完成，没有完善的文档，需要进行培训，耗费人力
- 性能监控太粗糙，覆盖面几乎没有，也没有具体的指标
第二次重构：去php，引入vue2.0
背景
以往web都依赖于至少一门后台语言，比如php，实际上php所做的工作仅仅是接口转发，业务都是由后台来完成。为了节省php两台服务器的成本，同时减少前端人员对php语言的依赖，需要去除php。
现有的sg框架不足以提供去php的方案，所以只能另寻其他框架。
框架选型
有三大框架angular、vue、react可供选择，我当时主推angular，但领导觉得外部企业都在用vue，所以最终选择vue作为新的框架。组件库选择bootstrap-vue作为pc站，vant作为m站。
- angular 2.0：大厂维护，社区人较多，但学习成本较高，需要使用typescript开发
- vue 2.0：个人团队维护，比较轻量，容易入门
- react：未作调研
成本评估
- vue的官方文档的学习
- vue-cli脚手架搭建，以及router，vuex的引入，sg框架的中间件的集成
- 组件库的官方文档的学习
- 由于sg与vue的模板语法和生命周期比较一致，所以代码的迁移成本较低，仅仅是做一些代码位置的调整
收益评估
- 去除php，省了2台服务器成本
- 开发效率提升，因为vue的文档完善
测试排期
由于客户端版本迭代优先测试，web的框架重构会放在测试空闲时间进行，对整体的排期稍有延后。
灰度发布
无
错误监控
引入elk，定制错误监控面板
性能监控
引入google提供的性能监控的库web-vitals，定制性能监控面板
本次重构的问题
- 框架选择上存在调研不全面，缺少react的调研，不过对于最终结果而言，其实选择vue是最合适的，因为从sg到vue的学习成本最低
- 测试排期紧张
- 缺少灰度发布，面对达到一定体量的用户基数，需要加上灰度发布
第三次重构：升级vue3.0，引入typescript
背景
js的的弱语言的特性，导致了后期维护的困难，在修改之前同事的代码时，对于变量是何种类型存在疑惑，不敢轻易改动。
框架选型
由于vue2.0对typescript的支持不够好，所以升级vue3.0。组件库并非都支持vue3.0，所以优先对m站进行重构，因vant已经支持了3.0版本
成本评估
- typescript语法学习
- vue2.0到3.0语法的变更学习
- vant的语法变更，迁移过程中挨个对比
- vue-cli脚手架的变更，以及相关组件的变更
收益评估
- 代码维护方便
- 升级框架带来的新特性可以随时使用
测试排期
测试资源空闲
灰度发布
无
错误监控
不变
性能监控
不变
本次重构的问题
- npm私有仓库的vue组件库因为是vue2.0开发的，到了3.0版本不可用，花了一些时间更新了3.0的打包方式，等后期在慢慢改为3.0
- 引入的第三方库不支持typescript，比如d3，针对这部分代码采用js的方式
- vue-router的相关语法变更，导致滚动条位置出问题
- IDE的代码提示不友好，此为vue3和typescript结合的问题，暂时无解，等官方更新
- 没有灰度发布，因为代码改动较小，基本逻辑没有变化，所以挑了早上的时间上线，安排人员实时观察报错监控
框架选择注意要点
- 新框架是否支持现有项目的所有功能
- 设备兼容性问题
- 对所有开发成员的技术实力都有一定的评估，每个人对于新框架的接受程度不一样，尽可能的统一意见
- 框架性能问题，根据自身业务来判断，web要注意的点是页面是否展示居多，还是交互居多，数据动态变化是否频繁。
- 框架是否有人维护，维护的团队是否是大厂
- 框架社区是否健全，轮子够不够丰富
- 开发效率上是不是够快
- 组件库是否官方自带
- 代码风格的一致性
- 单元测试是否具备
- e2e测试是否具备
- 部署方式是不是可实施
- 有什么弊端或者劣势，是否可以接受
成本评估注意要点
- 所有的新技术都要安排一个人提前调研和学习，评估具体时间，在开发排期之前
- 开发时间排期（具体到天），包括学习成本和开发成本
- 开发人员对于当前项目的熟悉程度，是整个项目都熟悉，还是只熟悉部分模块，至少需要一个对项目全部熟悉的人来进行主导
- 迁移过程中沟通一定要及时，对任何可能延期的要及时上报
收益评估注意要点
- 预期的收益量化，实在无法量化的，比如提高项目的可维护性
- 重构完成的实际收益和预期收益对比，可以进行复盘会
- 收益评估需要技术和产品一起来衡量，尽量不影响版本迭代，如果需要同时进行的话
测试排期注意要点
- 测试同学最好是提前准备好全量测试用例，如果没有，开发人员整理好所有的页面入口，测试人员重写测试用例，可能需要产品配合提供对应的历史交互文档
- 测试的时间评估
- 兼容性测试，根据elk统计图看看目前用户设备的分布图
灰度发布注意要点
- 如果是php项目转spa的，灰度发布有点困难，可以不做
- spa项目升级或者更换框架，灰度发布可以通过nginx配置流量百分比，根据ip来分流就好了
- 如果没有成熟的灰度发布方案，可以选早上9点发布，开发人员可以随时观察报错监控，活跃用户数也会慢慢涨起来
错误监控注意要点
- 优先保证支付功能能够正常
- 其次根据量级来修复
- 当量级都不大的情况下，优先修复影响主流程的错误
性能监控注意要点
- FCP，LCP，FID等指标保持在75%以上
- 如果是后端，可以定义其他性能指标
总结
- 项目重构都是基于一定的目的和背景的，如果没有强烈的目的或者需求，没有必要重构
- 重构过程中需要有一个人先行调研新框架或者新方案的可行性
- 开发人员在重构过程中需要密切沟通，及时反馈，排期虽然是可调控，但尽可能地跟排期一致
- 重构上线之后，如果遇到重大问题无法及时修复，需要立刻回滚
- 单元测试和e2e测试不是为了测试而测试，是为了保证新的改动不会影响旧的功能，可以不做，或者针对重点业务做
- 重构后的项目在一段时间内最好有code review，避免重构后的代码依旧不可维护，及时统一代码规范
- 重构最好是完整的项目开发完上线，如果需要分阶段重构，需要设计好方案，做好风险评估
