1.前言
跳槽季，来到一家新的公司。怀着憧憬向往这新的技术层次和环境。往往梦想很丰满现实 很骨感,HTML+Jq+vuejs的混合模式让我维护起来苦不堪言,话不多说，有问题就要解决,开始摸索
2.目前的思路
-
保证生产稳定
-
了解项目产生和低成本的代码复用
-
查看各个版本迭代情况
了解后
- 寻找共同技术栈,保证协作开发的稳定
- 解决以前多版本多页面冲突,提高协作开发效率
- 了解项目需求,拓扑基本产品线
一期需要消化的问题
| 问题 | 优先级 | 处理 | 收益 |
|---|---|---|---|
| 多页面模块化 | 高 | 解耦各个功能模块 | 解决各个功能模块冲突 |
| 缺少CI/CD | 低 | 下放二期 | 缺少运维Jenkins实现落地收益不高 |
| 脚手架/工程化 | 中高 | 统一框架技术栈 | 产品版本达到应用可以拆和 |
| 接口规范 | 中 | 字段枚举和语义化 | 提高产能和复用性 |
| 代码规范 | 低 | 需要时间 | 时间证明一切 |
| 解决痛点 | 高 | 攻克以上问题带来的痛点 | 后续进行二期工作安排 |
2. 基础架构设计
新架构
classDiagram
后台管理 <|-- Duck
后台管理<|-- Fish
后台管理 <|-- Zebra
后台管理 : 对应所有web管理
后台管理 : +按需权限下放()
class Duck{
+前台页面
+独立授权()
}
class Fish{
+前台页面
+独立授权()
}
class Zebra{
+前台页面
+独立授权()
}
旧架构
classDiagram
后台管理 <|-- Duck
后台管理 : 对应所有web管理
后台管理 : +按需权限下放()
class Duck{
+前台页面
+独立授权()
+Fish()
+Duck()
+Zebra()
+...()
}
2.1一期的目标
一期的目标将所有前台主工程从业务线剥离，形成以下
- 微应用,多模块化管理
- 公共静态文件整合,例如Echarts,Jqurey.....第三方引用
- gitLab线上版本权限,以及产品版本号明确
- 工程化统一脚手架规范等
微应用
采用多工程模式,分别管理各自的模块,优化了各自浏览器的加载速度，一些不必要加载问题。 nginx进行统一授权随后分发到各自应用,解决了2次授权问题。接触了各个模块之间的耦合，不同的技术栈迭代和框架的选择有了很大自由度。通过这样的拆分，降低了代码开发、维护难度，也减少不同story 开发之间协作成本。
公共资源
老生常谈的问题,比如Echarts,element-ui,vant-ui的本体引用很大,且可能项目使用的地方其实不是很多,如果没有做按需加载的话，也会重复加载这些文件，浪费网络带宽和静态服务器存储空间，没有意义。 抽离出这些的js or css进行公共静态cdn引用，有利于优化加载和版本控制,对后期代码维护会有很大帮助。
gitLab版本管理
大家都会遇到人走了，线上代码是哪个的问题,统一的产品的线拉取约束很有必要。且产品线迭代权限一定是最高的级别，团队负责的迭代应该对应项目进行定制化版本号的迭代，总之活要见人死要见尸！！！
工程化统一脚手架规范等
统一UI，主工程统一技术栈，统一请求管理，达到子工程可以拆分合并,无兼容,改动过多,版本过多和技术栈的冲突,降低开发成本。以产品线的脚手架为主,做加法,如需合并同步npm包的包含即可。
3.未来计划
初期计划正在执行，后续我会更新我的在一期落地的情况，分享我的经验。这里感谢掘金的各位大佬（^-1）就不一一样感谢了，特别感谢我的偶像花裤衩大大@花裤衩，未完待续.......
