团队里主战项目的整个框架结构大约是四年前搭建的，当前公司的业务策略已经发生了不少的变化，这个“老顽童”项目在面对快速迭代的新业务时，一些历史遗留问题和不规范的设计，给开发带来了额外的负担，劳神又费力，重构已经迫在眉睫 这是我参与更文挑战的第4天，活动详情查看： 更文挑战
项目中存在的问题
经过分析，大概存在这些问题：
- 使用的
Angular框架对组件化编程支持不够好，且比较笨重 - 框架的版本老化，
Angular已经出12版本了，我们还在用5。该版本的配套文档已经很少见 - 项目内大量不规范、冗余、错误的写法
- 由于历史原因，存在着大量的补丁代码
还有一个很大的问题，由于我们一般每隔两周发布一次，也许改动范围不大，但是影响面却非常大：每次都是全量发布。
由于全量的包体积非常巨大（好几百MB），那些跟本次发布功能无关的用户也需要重新下载整个资源包。
开发流程的问题
由于迭代节奏比较快，大家各自忙活手头的事，基本不怎么做CR（code review），毕竟一个人的见解是狭隘的，这可能会给项目引入一些糟糕的实现或设计。
同时，由于开发各自代码风格不同，导致每个人写的代码样子千差万别，这也给代码Review带来了困难。
所以团队需要统一代码风格，从而给CR铺平道路
再谈解决问题
首先对于项目的问题，其实解决方案很简单：那就是重构+拆分，我推荐团队采用了webpack的module federation方案,具体可参考微前端实践--webpack5模块联邦，结构图如下：
可以从上图看到，之前的项目目录很大，我们这里将其拆分成至少6个子项目（具体要看拆分的粒度），且每个子项目可单独部署也可以统一部署（是不是微前端呢？）。
并且我们将一些基础类库入react,react-dom,react-router-dom,axios...之类的一样拆分到一个项目中暴露出去，且所有其他的子项都依赖这个项目暴露的模块。
这样就做到了底层严格统一一致，并且由于这些底层依赖随时间变化的频次比较低，所以一旦稳定了，平时的迭代发布一般不需要发这些底层模块的，也就意味着用户每次只需要从资源缓存里读取这些模块包，而无需再次通过网络请求了。
再次，对于开发流程的问题，我们可以借助Git hook在提交代码时运行代码检查，统一风格，具体可参考这篇文章代码美化神器——Prettier使用详解
。
对于代码review，可以定期组织一下，每个人讲讲自己写某个模块的想法，其他成员发表一下自己的看法，尝试提出一些更优解，对于回答优秀者给出奖励，等养成了好习惯，自然就行了。同时，重构后的项目也会提升大家代码review的积极性。
最后
近期，团队正在进行重构的初期工作：如引入ts、解决远程依赖的类型问题、国际化啊、等等，等到重构告一段落，进入到一个成熟阶段后，我会再分享一些成果出来的哦。
感谢阅读！
