重构过程中，一直坚持重构不一定重写，项目重构我认为其实它是在做架构设计

架构设计往往需要做需求调研，会经历的步骤：
（1）收集利益相关者的需求。倾听业务人员、项目负责人等相关者的需求，进行用户访谈，收集相关的需求。
（2）与相应的技术人员（如开发人员、测试人员）讨论，了解架构上的潜在限制。
（3）寻找潜在的可行性技术方案。
（4）整理出功能列表中的功能性需求和跨功能性需求。
（5）找出会严重影响开发的风险点。
（6）和技术委员会、利益相关者反复确认方案（可选）。
（7）对架构设计进行概念证明。
（8）细化架构的部分实施细节。
（9）结合技术和业务，进行需求排期。

1、技术栈选型

一般需要结合团队技术，开发成本
如vue、react 两者选型
个人会更偏向写react
从当前项目基调，我选型技术栈：vue3.0 全家桶，TS, Element-UI ，scss

2、推行UI标准化

在推行过程中，其实前端可以做很多的事，如

  • 制定前端组件标准化：表单、表格、详情页

项目重构 - 图1

  • 组件库建设

目的：在协助开发过程，保证每个模块开发出来UI风格统一。

更多详情：https://www.yuque.com/web-developer/kpmh1b/gyau2v

3、性能优化

性能一般可以分成二种：项目上线后针对的做性能优化 和 在实际开发中做优化
其根本的目的：让良好的用户体验成为性能优化的目标

4、熟悉代码，梳理业务

  • 重构可以帮助我复审别人的代码，开始重构前我可以先阅读代码，得到一定程度的理解，并提出一些建议。
  • 组件提取、函数提取、样式提取
  • 梳理业务为什么重要？

从技术层面上看，重写应用并不复杂，复杂的地方在于理清原有的业务逻辑——看着旧的业务代码，编写新的业务代码，找寻公司内部相关的人寻问业务。

5、制定前端后台vue-temlate-admin 模板

  • 一般会借鉴开源 vue-element-admin，改造结合自己元素，开发成后台公共模板

主要功能包括基础组件,通用业务组件，网络请求库，Proxy跨域代理，Auth权限，Router路由，eslint代码规范，Mock data本地模拟后台数据，图表库， webpack打包工具

  • 打造前端团队的 Vue CLI 工具

公司中你会发现有以下一系列的问题!

  • 业务类型多
  • 多次造轮子，项目升级等问题
  • 公司代码规范,无法统一

很多时候我们开发时需要新建项目，把已有的项目代码复制一遍，保留基础能力。（但是这个过程非常琐碎而又耗时）。那我们可以自己定制化模板，自己实现一个属于自己的脚手架。来解决这些问题。

6、打造自己拳头产品，加快项目迭代

  • 开发可视化表单设计器

    • 赋能企业实现低代码开发模式；帮助开发者从传统枯燥的表单代码中解放出来，更多关注业务，快速提高效率，节省研发成本。
    • 中后台领域痛点
      1. 首先交互不统一，比如说有一些很相似的页面，但是由不同的产品或者设计师出的图。那实际上他们想要达到的效果是很相似的。但是交互不同，不同的前端开发出来的效果也不一样。不同职级的开发可维护性就会差一点，代码可能会复杂一些，会出现不同的编码风格。中台还有一个痛点的就是中台的系统非常多，业务重，人员有缺口。我之前负责的那个域，前后端比例当时是有 1：7 的样子，借人也好，招人也好，都是很难去补上这个缺口。
      2. 前端不了解业务，造成开发上线测试暴露的问题多

        7、项目重构前，会做前端代码规范

  • 从源码管理方式、代码合并方式、代码提交信息规范、代码规范自动化，到测试编写等一系列的过程

  • 代码质量及改善。在实施过程中不仅要注重代码整洁，还要注重TDD（测试驱动开发）等相关的实践，并且遵守SOLID原则，以保证代码的质量。此外，还需要制定代码的测试策略，测试的目的并非减少bug，而是用测试来保证现有的功能是正确的。（Jest）单元测试、UI测试等
  • 小的团队可以依赖于默契，大的团队则需要规范。它需要我们关注几个方面：代码风格的统一，如统一化编辑器、IDE等的配置、使用几个空格；代码的命名；如何保持一致性等。

  • 此外，在日常的开发中，还需要注重代码的可维护性——简单的代码更容易被读懂和维护。在维护一个项目的过程中，就深有体会——越是写得抽象的代码，越难以维护。诸如函数式编程是一个好东西，但是好的东西也容易被滥用，导致人们不喜欢这个东西。（ts）

    8、技术积累

  • 技术分享

能力提升有多种方式，其中使用得最多的招式便是技术分享。继续按照是和否的分法，可以将其分为两类：

  • 项目相关的技术分享。它所围绕的是项目所使用到的技术。
  • 非项目相关的技术分享。做一些项目相关的技术栈，或者完全以项目为主的技术分享。

对于非项目相关的技术分享来说，主要目的在于，知道有这样一件事，以及它能做些什么。对于绝大部分的人来说，仅仅是听半小时、一小时的分享，是不可能掌握相关的技能的。整个分享结束，掌握得最好的人，便是那个做技术分享的人。因此，就结果而言，做分享的人是最能学到东西的。我们也往往会将相关的分享，交给团队的新人来做。当我们做一个技术分享的时候，必然需要准备一系列的资料，还要反复加工相关的东西，这样才能向其他人介绍相关的技术。如果团队中有技术经验丰富的人，就能指出讲述过程中的一些错误。做分享也能加深双方的印象。此外，技术分享还能帮助新人练习一系列非技术相关的技能，诸如表达、资料搜集，等等。

9、增量改写

增量改写，即将系统拆分为多个独立模块或应用。当我们决定对应用进行重写的时候，只需要重写其中的一部分，其他功能仍然是正常运行的。而那些需要新功能的部分，又可以运行在新的应用之上。直到有一天，我们重写完所有的模块，系统相当于重写完成了。这种模式，又称为绞杀者模式，它可以在满足系统演进的情况下实现如下目标：

  • 大幅度减少对于业务的影响，降低了风险。
  • 可以随时停止重写，而不影响用户使用。
  • 用户、客户可以随时看到网站的变化，带来更多的价值。
  • 为开发人员带来更多的自由和乐趣。
  • 每个模块重写时，只关心相关部分的业务，而非所有的业务。

所了解的数据管理系统 还是我之前所开发的EIP系统 都采用当前的方式进行改造。（路由分发）

当然，这种方式拥有这么多优点而没有被采用，主要是因为实现起来有难度。该拆分方式仍依赖于微架构。对于后端来说，往往是使用BFF作为防腐层。对于前端来说，如果想采用这种模式，需要使用微前端架构来拆分现有的前端应用。

需要重写项目，往往这个项目已经是遗留系统，留下很多问题，所以才不得已就只能考虑重写这些应用。
过去认为，重写一个应用是一件简单的事，而演进一个应用则是一件复杂的工作。所以，我经历了一个大型前端应用的重写，发现重写应用一点都不简单——当一个应用有一定的历史时，没有人能讲清楚完成的业务逻辑，也没有人知道代码中的2是什么意思，大概就只能是2吧。要是我们在重写的过程中，没有把2变成诸如varHALF=2这样的变量，也没有写上对应的注释，恐怕又会多一次重写。直到有一天，这个2被删除了，或者知道了2的含义。
此外，应用在其生命周期里，经过了不同的开发人员、不同的业务变更，必然有大量的遗留代码——没有人知道具体业务的代码。有大量的业务已经不存在了，然而代码仍然保留着，还包含了相关的注释，也就没有人想去或敢去修改这些代码。
因此，在拥有足够人力和物力的情况下，对于旧系统或者遗留系统而言，最好的使用方式就是重写应用。但是，基本上不存在这样的情况，除非我们远远领先于其他竞争对手。如此一来，我们还是能够接受重写的成本的。
那么重写能解决问题吗？
在年轻的时候，我们对于有一定年限的应用总有一个相似的看法，为什么我们不重写呢？而资深的程序员，又会同情地告诉我们“重写不会带来业务价值”。那么，怎样才能带来业务价值？下面是问题的答案。

  • 更少的功能完成时间。旧的系统需要3天才能完成的功能，新的系统现在只需要1天就能完成。
  • 更好的用户体验。
  • 提升应用的性能。旧的应用需要3秒才能响应结果，新的系统只需要0.5秒。