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