- 本文作者：karoboflower， 转载自juejin.cn/post/710605…
前言
代码重构是一个产品发展到一定阶段不得不面对的事情，大到整个产品重构，又或者是一个页面、一个组件的重构。我们都要思考重构背后的起因是什么，并分析重构所带来的效益和成本。
重构原因
重构会面临很多问题，想要推进重构，需要分析项目重构的原因并梳理重构完成后是否解决了这些问题。
- 样式风格老旧，跟不上主流时代。
- 产品需求和产品交互，现有技术不能够完成。
- 来自客户的槽点。
- 项目中存在破窗效应，代码风格不统一，历史遗留问题过多，业务逻辑不断添加，缝缝补补，导致项目很混乱。
- 项目中存在漏洞、内存泄漏、性能等问题。
- 开发效率受挫，比如打包时间过长；前后端未分离；前端无法本地代理等。
- 项目中使用的依赖库无人维护，百度工程师进行不下去。
- 团队人员想要追求技术的极致，需要新的技术提高团队人员的热情。
重构时间
接受到一份重构任务的时候，大部分时候都很蛋疼。
第一要分析原有的业务逻辑；第二原有代码存在很多历史遗留问题；第三互联网人员流动很快，很有可能就找不到当初负责这一块的开发人员和需求人员，所以重构时间点也是十分重要的。
- 不建议在当前页面积累了太多业务逻辑代码的时候去重构，这个时候选择去重构，开发人员需要在理解需求和业务上面消耗太多时间和人力。
- 不建议在当前页面还处于不断迭代中去重构。
- 当前公司处在技术改革时期。
- 建议当前页面存在新需求，同时重构完成能赶上当前迭代火车时去重构。
重构类型
渐进式重构
适用项目
业务需求处于不断迭代中，必须不断更新需求占领市场。
老技术和新技术能够兼容。
项目过于庞大。
底层重构
适用项目
现有技术已无法满足业务需求，比如原来的项目用微信小程序开发，现在需要同时支持支付宝和微信小程序。
项目复杂度不高，且现有时间和人力充足。
重构前期准备
前言
本次规划主要是针对于探针重构，项目最终确定为底层重构。
在项目重构中，可以很好的梳理现有项目存在的设计问题和历史遗留问题，在规划架构和规划具体页面时，可拉拢相关人员，提出一些交互优化。
需要考虑当前代码设计和交互设计是否具有未来需求的可扩展性，比如支持主题变更，国际化？
技术选型
1.现有团队对于新框架的上手成本。
2.新框架是否具有稳定性（可从 GitHub、社区活跃度上面去考量）。
3.新框架是否满足现有业务需求，是否满足未来业务需求，在此基础上，再去考虑技术对于团队人员成长性的提高。
原项目梳理
1.将原有页面结构和项目结构梳理一遍，并用 xmind 梳理现有页面结构、项目结构，了解原有基础架构设计的理念，并利用现有重构技术梳理一套适用于项目的基础架构方案，拉通相关人员，商量方案的可行性。
2.针对于当前项目制定一个重构计划。
风险考量
- 原有需求如何保障
- 新的交互风格是否能获得客户认可
- 各方人员拉拢协商
重构计划
最终采用 vue3+ts+idux 上线项目，遵循 seerdesign 设计规范
制定规范
- 文件、组件、方法、变量名等形成规范，梳理成相关文档
- eslint 采用 eslint-config-idux 规划
- git 提交规范
- 梳理后台接口文档
基础搭建
- 参考现有 vue3+ts+idux 上线项目，并询问相关开发人员意见。
- 使用内部业务架构模板 vue3-vite-setup（外部地址：github.com/IDuxFE/idux…
- 请求封装（使用@vueuse/core 中的 fetch，不再使用 axios）
- 基本 types 类型封装
- 路由统一过滤，并建立每个路由的基本页面
- 登录进入首页成功（token 配置）
- 支持 theme 主题变更，根据后台返回的数据设置全局主题变量，引用不同的 less,并修改不同主题下的全部 namespace，设置不同 class
- class 尽量使用 windiCSS，减少 css 体积
- 国际化处理
- 本地 mock 数据
全局组件
根据具体项目分析所得
页面开发
具体开发人员梳理
其他
- 因为我们服务于产品线，重构计划的推动是个难点也是第一步，为了推动重构计划，提供切实可行并可控的重构计划方案是很有必要的，同时需要梳理重构计划带来的业务价值和技术价值。
- 建立渐进式重构意识，一旦意识到代码项目冗余且复杂，就要考虑重构代码。
- 在进行代码设计的时候，不要过度注重代码的可扩展性和抽象设计，这样会导致代码变得十分难懂和过度复杂，我们要在简化和冗余之间取得平衡点。
- 为了避免二次重构和考虑未来需求的适应性，设计要高内聚低耦合。
最终重构是否能够顺利成功，需要天时地利人和，谢谢大家~~~~
