重构原因
-
技术落后，维护及迭代功能都很困难
-
之前写代码的同学不是专业前端，写出来的代码质量差，冗余代码多，大部分文件代码行数超过两千行（重点）
-
业务变化，后续需要迭代的功能与现有功能差异性比较大（和ip挂钩的物理机监控到与物理ip无关的云服务、容器类数据监控）
实施步骤
技术调研和选型：主要考虑点，组内非前端同学的上手难度、后续扩展难度
-
因为改动较大，相当于整个项目的重构，前期做了很多技术调研，比如当前使用的react15版本，对比当前vue和react框架最新稳定版本，考虑到组内其他同学的上手容易程度，选择直接更新到react16.8版本，但是先不使用hooks开发，还是主要使用class组建，在代码层面需要做的改动就主要是生命周期上的（react16之后为了引入hooks概念，抛弃了几个容易滥用导致组建不可控的生命周期componentWillMount、componentWillUpdate和componentWillReceiveProps），不用hooks，主要是为了对于非前端同学来说更容易做规范化管理，后续想使用hooks也完全可以，另外还是使用redux做数据管理，整体使用单页应用hash路由，和原本保持不变
-
构建工具还是使用的市面上比较流行的webpack（V4，5还没正式发布）工具，一个是因为相比Grunt、Gulp这些基于任务运行的工具，我对于模块化打包的webpack更熟一些，第二就是create-react-app已经集成了webpack，它满足现阶段我们的业务需求和后面的一些规划使用，比如我们需要和antd统一规范的组件等，所以直接使用cra，再针对我们的项目做一些定制化配置就好了，另外组件库还是使用antd，但是需要使用antd4以上版本，支持虚拟列表，来优化我们搜索指标结果的无限列表展示和图表页面多屏页面图表的性能
-
css预处理器，主要是为了做一些全局样式统一的变量控制，做全局主题切换，当时是考虑了sass和less两种比较流行的预处理器，然后对比了下，发现sass相比less更成熟，但是less受欢迎程度也不低，并且sass需要装ruby环境，less只要js环境就可以允许，我们需要使用到的东西（变量、层级、作用域），他们两者都支持，我们也业务发展也不需要太多的扩张，所以选择了less
制定代码格式校验和提交规范：
主要是使用自动化工具 + code-review的方式，来保障代码质量
工具上，配置esLint + git hooks + prettier，使用husky工具，在git pre-commit这个钩子执行的时候来做代码检查和格式化校验，这个需要在实施的过程提前配置上
实施
- 环境配置：使用cra创建基础应用，安装并配置redux、react-redux、react-router-dom、less、esLint + git hooks + prettier等工具，将全家桶内部webpack配置暴露出来（npm run eject），进行一系列优化（分环境），点不多，主要是指定编译范围、压缩、提取公共包、配置postcss-loader、CDN服务地址配置、本地开发代理配置等，基本的demo跑起来之后，进行业务代码迁移
- 基础建设：基于原本的项目页面情况划分模块，设计并创建整体文件结构，重新封装和优化公用的方法（网络请求、url参数解析等）
- 业务代码迁移：挨个创建使用中页面的路由，并拷贝原页面的代码，进行粗略的代码重构，兼容新的语法、新的公用方法，进行代码解构，将可复用公共组建和方法提取出来
- 交付测试：迁移完之后进行整体的优化调整，然后跑起来自测，然后进行了组内互测，在基本稳定之后，发布到测试环境，交付给测试同学帮忙测试，测试大概花了两周的时间，第一周的时候我这边在持续进行代码组织层面重构，业务保持不动，第二周整体不再调整，集中解决bug
- 发布预测：然后发布到预发部环境又测了一段时间，最后再上线， 整体花了大概一个半月的时间，但是从后续整体的开发维护效率来说是值得的，期间新的功能通过提mr的方式提到旧项目，我再去同步每天的新提交
旧的上线操作：上机器，替换静态文件，手工部署
Step 1: 压缩打包 tar // tar czvf devui.tar.gz ./dist
Step 2: 解压部署 deploy // tar zxvf devui.tar.gz
新的部署方式：配置cicd，自动走脚本命令部署到对应服务器
