前端重构方案

  • 本文作者:karoboflower
    转载自https://juejin.cn/post/7106056899828645919

前言

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

重构原因

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

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

重构时间

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

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

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

重构类型

渐进式重构

适用项目

业务需求处于不断迭代中,必须不断更新需求占领市场。

老技术和新技术能够兼容。

项目过于庞大。

底层重构

适用项目

现有技术已无法满足业务需求,比如原来的项目用微信小程序开发,现在需要同时支持支付宝和微信小程序。

项目复杂度不高,且现有时间和人力充足。

重构前期准备

前言

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

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

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

技术选型

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(外部地址:https://github.com/IDuxFE/idux-setup)
  3. 请求封装(使用@vueuse/core 中的 fetch,不再使用 axios)
  4. 基本 types 类型封装
  5. 路由统一过滤,并建立每个路由的基本页面
  6. 登录进入首页成功(token 配置)
  7. 支持 theme 主题变更,根据后台返回的数据设置全局主题变量,引用不同的 less,并修改不同主题下的全部 namespace,设置不同 class
  8. class 尽量使用 windiCSS,减少 css 体积
  9. 国际化处理
  10. 本地 mock 数据

全局组件

根据具体项目分析所得

页面开发

具体开发人员梳理

其他

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

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

© 版权声明
THE END
喜欢就支持一下吧
点赞10 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片

    暂无评论内容