前端重构方案

1,920 阅读5分钟

前言

探针风格老套,现有架构越来越无法满足新的需求迭代,每次只能简化处理,产品线和开发人员都苦不堪言。最近有重构的打算,借此梳理了代码重构的一些注意点。

代码重构是一个产品发展到一定阶段不得不面对的事情,大到整个产品重构,又或者是一个页面、一个组件的重构。我们都要思考重构背后的起因是什么,并分析重构所带来的效益和成本。

重构原因

重构会面临很多问题,想要推进重构,需要分析项目重构的原因并梳理重构完成后是否解决了这些问题。

  1. 样式风格老旧,跟不上主流时代。
  2. 产品需求和产品交互,现有技术不能够完成。
  3. 来自客户的槽点。
  4. 项目中存在破窗效应,代码风格不统一,历史遗留问题过多,业务逻辑不断添加,缝缝补补,导致项目很混乱。
  5. 项目中存在漏洞、内存泄漏、性能等问题。
  6. 开发效率受挫,比如打包时间过长;前后端未分离;前端无法本地代理等。
  7. 项目中使用的依赖库无人维护,百度工程师进行不下去。
  8. 团队人员想要追求技术的极致,需要新的技术提高团队人员的热情。

重构时间

接受到一份重构任务的时候,大部分时候都很蛋疼。

第一要分析原有的业务逻辑;第二原有代码存在很多历史遗留问题;第三互联网人员流动很快,很有可能就找不到当初负责这一块的开发人员和需求人员,所以重构时间点也是十分重要的。

  1. 不建议在当前页面积累了太多业务逻辑代码的时候去重构,这个时候选择去重构,开发人员需要在理解需求和业务上面消耗太多时间和人力。
  2. 不建议在当前页面还处于不断迭代中去重构。
  3. 当前公司处在技术改革时期。
  4. 建议当前页面存在新需求,同时重构完成能赶上当前迭代火车时去重构。

重构类型

渐进式重构

适用项目

  1. 业务需求处于不断迭代中,必须不断更新需求占领市场。
  2. 老技术和新技术能够兼容。
  3. 项目过于庞大。

底层重构(复合重构)

适用项目

  1. 现有技术已无法满足业务需求,比如原来的项目用微信小程序开发,现在需要同时支持支付宝和微信小程序。
  2. 项目复杂度不高,且现有时间和人力充足。

重构前期准备

前言

本次规划主要是针对于探针重构,项目最终确定为底层重构。

在项目重构中,可以很好的梳理现有项目存在的设计问题和历史遗留问题,在规划架构和规划具体页面时,可拉拢相关人员,提出一些交互优化。

需要考虑当前代码设计和交互设计是否具有未来需求的可扩展性,比如支持主题变更,国际化?

技术选型

  1. 现有团队对于新框架的上手成本。

  2. 新框架是否具有稳定性(可从GitHub、社区活跃度上面去考量)。

  3. 新框架是否满足现有业务需求,是否满足未来业务需求,在此基础上,再去考虑技术对于团队人员成长性的提高。

原项目梳理

  1. 将原有页面结构和项目结构梳理一遍,并用xmind梳理现有页面结构、项目结构,了解原有基础架构设计的理念,并利用现有重构技术梳理一套适用于项目的基础架构方案,拉通相关人员,商量方案的可行性。

  2. 针对于当前项目制定一个重构计划。

风险考量

  1. 原有需求如何保障
  2. 新的交互风格是否能获得客户认可
  3. 各方人员拉拢协商

重构计划

最终采用vue3+ts+idux上线项目,遵循seerdesign设计规范

制定规范

  1. 文件、组件、方法、变量名等形成规范,梳理成相关文档
  2. eslint采用eslint-config-idux规划
  3. git提交规范
  4. 梳理后台接口文档

基础搭建

  1. 参考现有vue3+ts+idux上线项目,并询问相关开发人员意见。
  2. 使用内部业务架构模板vue3-vite-setup(外部地址:github.com/IDuxFE/idux…
  3. 请求封装(使用@vueuse/core中的fetch,不再使用axios)
  4. 基本types类型封装
  5. 路由统一过滤,并建立每个路由的基本页面
  6. 登录进入首页成功(token配置)
  7. 支持theme主题变更,根据后台返回的数据设置全局主题变量,引用不同的less,设置不同class
  8. class尽量使用windiCSS,减少css体积
  9. 国际化处理
  10. 本地mock数据

全局组件

根据具体项目分析所得

页面开发

具体开发人员梳理

其他

  1. 因为我们服务于产品线,重构计划的推动是个难点也是第一步,为了推动重构计划,提供切实可行并可控的重构计划方案是很有必要的,同时需要梳理重构计划带来的业务价值和技术价值。
  2. 建立渐进式重构意识,一旦意识到代码项目冗余且复杂,就要考虑重构代码。
  3. 在进行代码设计的时候,不要过度注重代码的可扩展性和抽象设计,这样会导致代码变得十分难懂和过度复杂,我们要在简化和冗余之间取得平衡点。
  4. 为了避免二次重构和考虑未来需求的适应性,设计要高内聚低耦合。

最终重构是否能够顺利成功,需要天时地利人和,谢谢大家~~~~