强调

笔者写这篇文章只是想就事论事，单纯分享一下自己重构的这件事。（叠几层甲：关于以代码量为考核绩效、能跑就行、成功把自己给优化了等讨论话题不在本文的考虑范畴哈）

事件起因

老实说，人和代码的确其中一个代码能跑就行，所以一开始💩山就💩山吧。但随着代码堆积的坑越来越多，一直到这座山，它真的塌了... 最后跟同事的一致讨论下决定开始重（堆）构（💩）项目😭。

项目性质

公司的产品是属于多端需求的自研产品，具体叫什么我就不方便透露了。用户群体的使用频率是小程序（微信和支付宝） > H5 > APP，并且总需求就是一套代码多平台共用（老板都是为了省而省），并且为了所谓的敏捷开发、快速迭代等很好的埋下了不少的雷（前辈埋💩后人吃）。不过也能理解😂，毕竟都是打工人。

技术选型

出于时间和学习成本考虑，最终还是选择了uniapp（没错，就是那个人人都吐槽的🤣）。从一开始我也是对uni嗤之以鼻的，而且还有它那难以言喻的HBuilder。但经过长时间的使用后，个人认为其实优点还是大于缺点的。因为真正想要多端编译一套代码的难度堪比登天（无bug），而且对常用Vue的开发者来讲上手也是非常的快（很重要，毕竟不想加班😭）。

    技术升级主要包括框架、设计模式和脚手架的升级
如：MVC模式 => MVVM模式
     jQuery =>  React/Vue/Angular 
     Grunt/Gulp => Webpack/Vite

    同时也推荐使用相搭配的组件库
如：Ant Design、Element、Vuetify、Vant、Taro、Material Design等

开始重构

`前提`

一定要对项目整体有一个完整的认知，知道原项目的坑在哪里（如果是刚接手的项目还是别搞了）。

`方式`

在不影响现有功能的情况下进行渐进式重构。逐步修改引入新代码。

区分业务

现状评估: 确定哪些部分是核心业务逻辑，哪些是辅助功能。核心业务逻辑通常是与应用的主要功能直接相关的代码。
模块/组件: 将不同的业务逻辑分离到独立的模块或组件中。避免在一个模块/组件中混合多种业务逻辑，这样可以减少耦合性。
抽象复用: 提取通用的业务逻辑或功能为独立的模块/组件，提高代码的可重用性。

预留扩展

插件机制: 允许通过添加新插件来扩展系统功能，而不需要修改核心代码。
开闭原则: 组件应该对扩展开放，对修改封闭。通过接口扩展新功能，而不是直接去修改组件的内部来实现。
动态配置: 把应用中的一些可变设置放在配置文件或环境变量里，而不是直接写死在代码中。以便日后快捷调整和修改设置。

统一规范

编码标准: 制定并遵循统一的编码风格和命名规则和项目文件结构一致，同时使用 ESLint 或 Prettier 检查代码。保证代码整洁一致。
文档注释: 在复杂的业务逻辑和模块编写适当的注释（很重要），确保易混淆的逻辑代码的意图和功能清晰可见。

性能优化

优化方式: 减少不必要的渲染和冗余代码，懒加载资源，按需引入组件和第三方模块，分包处理等。

其他细节

我们始终要铭记重构的初心：原项目难以维护！！！所以一切所做的事情往可维护性上靠。

再次叠甲：个人观点，你反驳就是你✅，无需多言🤣

不推荐原子类CSS:如: Tailwind CSS 虽开发体验较好，无需再考虑class的命名和便捷的响应式等，但由于过于细粒度所造成的可读性下降，造成可维护性困难。
减少代码嵌套:如: 大量的if/else语句、三元运算符的使用可优化为策略模式；使用Promise、async/await等方式代替回调函数减少嵌套，避免回调地狱；使用对象、数组或Map等数据结构替代复杂的嵌套条件判断或循环。

我是怎么重构公司历史遗留项目的（思路）？

强调