聊聊前端重构和技术选型
接触过一段时间在线系统的同学,对于重构、重写的概念都不陌生,本文主要是谈谈在前端重构(写)项目过程中的一些心得
明确下重构or重写
重构:重构一书中描述 -在不改变代码外在行为的基础上,对代码进行修改,以改进程序的内部结构
重写:这也是现在大部分人对重构的误解,我们通过对代码底层设计的改动,进行整体的系统重写,以达到改进的目的
很明显,这两种方式的适用场景上有区分的,
当我们的应用并没有框架或设计的致命缺陷时, 应该使用重构,微优化的方式进行代码调整
当我们的应用设计或底层框架已经不组件满足业务发展,那采用重写的方式抛弃历史包袱,无疑是一种合适的方式
重构我们该做些什么
对于前端来说, 无论是重构或重写,都面临着一些问题
- 前端业务被天然分成了两个部分, 逻辑&UI,并且大部分情况下代码的界限不够明确
- 缺乏完善的测试机制保障重构的正确性, 大部分情况下,都是靠人来check
当我们要对一个系统(模块)进行重构时, 我们需要怎么做呢
-
什么时候需要重构
- 三次法则
当我们第一次、第二次写某个功能时,我们可以正常去写, 当我们第三次写到类似功能时, 我们就需要考虑重构这三个部分,以达到代码优化的目的 - 预备性重构
当我们做到某个功能时, 已经知道这块代码在之前做过, 那我们就可以利用重构的手段,修改原先的代码,已适应现在的逻辑 - 优化现有代码
当我们修改的代码时,可能会发现当前的代码实现并不优雅或者存在明显的设计问题, 我们就应该及时重构优化它
- 三次法则
-
如何重构
TODO
重写我们该做些什么
重写的过程,其实就是在造一个新的系统, 实现了老系统的能力,并在其上进行了架构优化。一个新的系统,自然就涉及到一下几个部分, 技术选型、技术规范、架构设计
技术选型怎么做
技术选型,需要考虑以下几点
- 合适的才是最好的
用户群体是什么样的, 业务类型又是什么样的 - 成本约束
学习成本 (是否能快速学习,快速上手, 遇到问题能不能快速解决) - 时间约束
开发时间是否符合预期
上线时间是否满足业务方诉求 - 性能要求
重构后是否对性能有负面影响 - 技术优缺点
技术规范怎么设定
TODO
如何保障项目的生命周期足够长
很多时候,我们会听到有人这样说, xx年需要重写一次系统, 或者重构的时候只考虑了短期的利益, 初时写的时候,重构给我们带来了足够的效益, 但是后续并没有持续优化和重构,导致一两年之后,系统有变成千疮百孔, 无法很好的维护
那么除了技术规范,还需要做哪些事情,来为我们的系统保驾护航呢?
- 严格的代码审查机制
代码审查是我们编码过程中的一个重要且有效的手段, 合适合理的审查方式有助于我们提高代码质量,减少代码出错的可能 - 持续的优化和重构
重构或重写需要达成的目标
这张图上有两个曲线, 相信很多团队都遇到过差的设计
的问题。
当我们往一个系统添加新功能时, 内部质量良好的软件可以轻易找到在哪里修改、如何修改, 代码逻辑清晰的情况下, 引入bug的可能行也降低很多
我们做重构或重写的目标,也就是使我们的系统不断趋向于好的设计