hugh 的个人博客

聊聊前端重构和技术选型

接触过一段时间在线系统的同学,对于重构、重写的概念都不陌生,本文主要是谈谈在前端重构(写)项目过程中的一些心得

明确下重构or重写

重构:重构一书中描述 -在不改变代码外在行为的基础上,对代码进行修改,以改进程序的内部结构

重写:这也是现在大部分人对重构的误解,我们通过对代码底层设计的改动,进行整体的系统重写,以达到改进的目的

很明显,这两种方式的适用场景上有区分的,
当我们的应用并没有框架或设计的致命缺陷时, 应该使用重构,微优化的方式进行代码调整
当我们的应用设计或底层框架已经不组件满足业务发展,那采用重写的方式抛弃历史包袱,无疑是一种合适的方式

重构我们该做些什么

对于前端来说, 无论是重构或重写,都面临着一些问题

  • 前端业务被天然分成了两个部分, 逻辑&UI,并且大部分情况下代码的界限不够明确
  • 缺乏完善的测试机制保障重构的正确性, 大部分情况下,都是靠人来check

当我们要对一个系统(模块)进行重构时, 我们需要怎么做呢

  1. 什么时候需要重构

    • 三次法则
      当我们第一次、第二次写某个功能时,我们可以正常去写, 当我们第三次写到类似功能时, 我们就需要考虑重构这三个部分,以达到代码优化的目的
    • 预备性重构
      当我们做到某个功能时, 已经知道这块代码在之前做过, 那我们就可以利用重构的手段,修改原先的代码,已适应现在的逻辑
    • 优化现有代码
      当我们修改的代码时,可能会发现当前的代码实现并不优雅或者存在明显的设计问题, 我们就应该及时重构优化它
  2. 如何重构
    TODO

重写我们该做些什么

重写的过程,其实就是在造一个新的系统, 实现了老系统的能力,并在其上进行了架构优化。一个新的系统,自然就涉及到一下几个部分, 技术选型、技术规范、架构设计

技术选型怎么做

技术选型,需要考虑以下几点

  1. 合适的才是最好的
    用户群体是什么样的, 业务类型又是什么样的
  2. 成本约束
    学习成本 (是否能快速学习,快速上手, 遇到问题能不能快速解决)
  3. 时间约束
    开发时间是否符合预期
    上线时间是否满足业务方诉求
  4. 性能要求
    重构后是否对性能有负面影响
  5. 技术优缺点

技术规范怎么设定

TODO

如何保障项目的生命周期足够长

很多时候,我们会听到有人这样说, xx年需要重写一次系统, 或者重构的时候只考虑了短期的利益, 初时写的时候,重构给我们带来了足够的效益, 但是后续并没有持续优化和重构,导致一两年之后,系统有变成千疮百孔, 无法很好的维护

那么除了技术规范,还需要做哪些事情,来为我们的系统保驾护航呢?

  1. 严格的代码审查机制
    代码审查是我们编码过程中的一个重要且有效的手段, 合适合理的审查方式有助于我们提高代码质量,减少代码出错的可能
  2. 持续的优化和重构

重构或重写需要达成的目标

这张图上有两个曲线, 相信很多团队都遇到过差的设计的问题。
当我们往一个系统添加新功能时, 内部质量良好的软件可以轻易找到在哪里修改、如何修改, 代码逻辑清晰的情况下, 引入bug的可能行也降低很多

我们做重构或重写的目标,也就是使我们的系统不断趋向于好的设计


标题:聊聊前端重构和技术选型
作者:hugh524
地址:https://blog.uproject.cn/articles/2021/08/01/1627812063409.html