我对项目重构的理解
重构意味着风险和机会
我对重构的感觉是“复杂”，之所以说它复杂，是因为重构实际上是一种吃力不讨好的事情。在迫不得已需要重构的时候选择重构，实际上也算是一种勇气。重构会从长远上给项目开发、需求推进、业务扩展带来长足的好处，但是也是一种风险最大的选择。因为大家喜欢稳定，保持现状不出错就不会摊上事。所以那么多堆成屎山的代码也就不足为奇了。
为什么需要重构
重构往往是迫不得已的事情，需要重构时大概率是遇到了下面的麻烦：
- 落后的技术栈。落后的技术栈影响了应用性能，提升了开发成本，较低的开发效率。
- 需求无法在现有的结构上推进。需求不断变化，都原有的架构无法实现时，只能提出更具有扩展性的架构来。
- 代码的复杂度难以维护。总之就是一个字：乱。bug太多，调试太难，问题太难找。推翻重写可能会效率更高。
如何避免重构
- 保持稳定且较新的技术栈。如果实在无法升级，可以考虑使用微前端的架构。
- 项目之出要充分了解需求的变化轨迹，为项目打造足够灵活、可扩展的架构进行开发。不要为了一时之便牺牲了扩展性。
- 代码要充分解耦可复用。推动基础设置的建设。推动团队内部的code review。提升代价质量。
重构的难点
- 繁重的工作量。重构就意味着推翻重来，工作量自然是很大的。
- 可能存在的业务风险。比如某一段需求理解不够充分，可能引起一些问题。
- 时间不可控。重构的过程中无法预测会遇到什么样的问题，会怎样影响进度。
需要注意的细节
- 充分了解需求。实在不清楚的代码要保持原样，等弄清楚原因之后再改。
- 提前设计架构。新的架构应该能够充分满足未来几年内的需求。
- 分模块重构和解耦。从梗概到细节进行重构。
- 充分的测试用例。充分、全面的QA测试流程。
四次重构经验
通讯录业务
概况：通讯录模块是一个较为独立的模块。技术栈较为落后，开发效率比较低。
重构的原因：
- 技术栈落后，影响开发效率和应用性能。
- 结构不合理，无法扩展新需求。
- 在多环境下，维护比较吃力，经常发生线上问题。
重构的过程：
- 使用最新的技术栈。删除较为陈旧的开发代码。
- 优化DX体验，优化打包体积。
- 优化项目结构。将应用模块之间进行解耦。如状态管理、国际化、网络请求、图片资源。
- 优化CI/CD流程。
直播业务
概况：直播模块相对较大，但依然存在着诸多问题。
重构的原因：
- 状态管理混乱。一个项目中同时使用多个状态管理工具。
- 代码陈旧，较多遗留的代码。
- 入口混乱。
重构的过程：
- 升级状态管理模块。
- 优化代码，删除无用代码。
- 优化样式表。
- 重新配置入口和模板。
证书业务
概况：静态的证书无法满足更复杂的业务需求。
重构的原因：
- 原模块功能无法扩展，新的需求无法继续开发。
重构的过程：
重写证书编辑的系统，并且提升为插件。
- 画布。渲染图片、导出图片。
- 节点：文字节点、图片节点、变量节点。
- 拖拽系统
- 标准线系统和磁吸系统。
- 节点层级。
- 文字编辑系统。编辑命令。
巡课业务
概况：巡视教室终端画面。
重构原因：
- 现有结构无法继续扩展需求。
- 代码太乱，一个文件5000行，JSX中混合大量业务逻辑。
重构的过程：
重写巡课业务，抽离为巡课SDK模块。
- 视图与业务分离。业务以SDK存在，不依赖于特定的框架。
- 任务驱动渲染。将渲染封装为任务，由外界更新所驱动。
- 分模块解耦。会议模块、巡课模块、轮询模块、分页器模块、清流模块、渲染模块、声音管理模块、Monitor模块、测试模块。
- 增量调度，队列提升性能。
- 提供通用的视图组件，方便扩展。