2022年底，我手里一共负责了30套系统
2022年真是不平凡的一年，往常熙熙攘攘的办公室人越来越少，真是像曹操说的兄弟相继凋零，好似风中落叶啊。
结果人少了，手里的系统一个没少，慢慢年底了，我汇总了一下，手里的系统达到了30来个。
搞不定怎么办？我是这么做的
目录
1、 区分系统的重要程度
当然这30来套系统也不是一次性过来的，是经过一年断断续续到我手里的，刚开始每人手里都有自己负责的系统，慢慢3月份一点，6月份一点，8月份一点，10月份一点，2022年真是不平凡的一年啊。
根据重要紧急程度，我区分了P1 P2 和 P3三个等级。
P3就是线上还在跑着的系统，但是访问量比较小，而且几乎一年了也没有什么需求的；
P2就是线上跑着，也有访问量，需求偶尔会提1个，但不会去做太多投入，除非有重大改动的，不过看今年这情况，短时间内也不会有大的改动了，但是不是促销活动还是会动一动，属于三四个月可能会动一次的；
P1就是比较重要的系统，访问量比较大，几乎每次迭代都会提需求的。
2、P3级别的文档梳理
P3级别相对来说不太重要，因为只要线上机器不会坏就没事。但是一旦自己负责了就得有个样子，针对这P3级别的8个系统，我做了一个统一的文档。
记录了以下几点：
△ 代码的地址（保证自己有master权限）
△ 保证代码可以本地启动起来，修改代码可以生效
△ 知道这8个系统都部署在哪台机器上
△ 线上访问的地址是什么
这样就够了，这种系统一般不会动，除非机器坏了，一旦哪天机器坏了，我再重新保证能部署到合适的位置就好啦。
3、P2级别的文档梳理
P2级别的日常不用动，但到了某个特殊的节日，还是会做一些活动处理的，所以我做了以下梳理：
△ 每个系统记录一个文档
△ 记录代码库的地址（保证自己有master权限）
△ 记录每套系统的npm源，node版本，保证与之前开发者统一
△ 代码可以启动起来，修改代码会生效
△ 大体梳理代码结构并形成文档，例如有前端路由的，要找准路由对应的组件，如果用了vuex redux的，证明这是一套比较麻烦的系统，还要多梳理一下数据走向（很多人为了锻炼用vuex，一个小破页面也用上，好烦）
△ 通过以上梳理，看一下打包的时候是否区分版本号，是否区分部署环境等，找准测试环境和线上环境的机器，都记录下来
△ 线上部署的时候，HTML和静态资源（js css image）是否在一起，是可以几台机器一下都重启，还是分批重启，冷备一部分
△ 记录线上地址，查看线上和测试的接口区分
△ 一般服务端同学不用记了，因为也只有那么俩人了
△ 代码细节也不用着重梳理，有时间再梳理也行
这样，保证自己需要做需求的时候，可以快一些找到修改的位置，改完了可以做代码部署，自测以及通知测试怎么测
4、P1级的文档梳理
P1级别的，可能每天都需要关注，文档中除了以上的P3P2级别的梳理文档，还有如下几点重要事项：
△ 梳理代码细节，子组件的嵌套关系，组件间的数据传递情况，展示情况
△ 着重梳理数据来源，接口是哪些，入参是哪些，出参是哪些
△ 梳理关键数据的兜底情况，是否会因为某些数据下发的不同而产生不同的情况，或者直接造成八阿哥
△ 交接给你的人，一定追着问，之前还有哪些坑，哪些没解决的问题，这一点至关重要；
△ 梳理这套系统中哪些功能更常用，需要立刻梳理代码细节，有哪些不常用甚至废弃的，还没有删除的
△ 了解这些系统的监控系统都有哪些，是否需要添加自己为处理人的，或者更加重要的系统，自己每过半个小时就需要自己去手动访问一次的
等等等等吧，问题很多，弄不过来，再区分也弄不过来。有人说技多不压身，但是活儿多了压身啊。
5、把前端代码部署到nginx服务器
有些系统代码因为历史原因，不能通过部署平台的，需要自己往线上nginx平台部署。之前要么都是前端把dist压缩包发给服务端，让服务端部署，要么就是有了部署平台自己玩，这下好了，我得自己往nginx线上服务器上部署。步骤如下（学的比较浅，但是暂时够用）
1、npm run build 打包
2、打出的zip压缩包之后，传到服务器上的某个位置
执行 scp -r dist-2022121201.zip [email protected]:/home/dbg
这里的dist-2022121201.zip就是你本地dist打出的压缩包
dbg是你在线上机器的用户名
xxx.xx.xxx.x 是线上机器的ip
/home/dbg 是你在线上机器的某个文件夹，属于你自己的文件夹
3、登录到线上机器
执行 ssh xxx.xx.xxx.x
4、登录上去以后，就到了你自己的空间，然后执行 ls ，如果刚才传送成功了，是可以看见你刚刚打出的 dist-2022121201.zip
5、从你的空间，把压缩包移动到部署位置
执行 mv dist-202212121201.zip /usr/share/nginx/dbg_area
/usr/share/nginx/dbg_area 这是你nginx机器上的部署代码的区域，这里面将会放你的前端代码
6、将执行命令指向到nginx服务器位置
执行 cd /usr/share/nginx/dbg_area
7、再次执行 ls 命令，查看是否已经把压缩包移动过来了
8、解压压缩包，就会把上一次的内容覆盖掉
执行 tar -zxvf dist-202212121201.zip
9、重启nginx
nginx -s reload
其实先把压缩包移动过来再解压显得有点冗余，完全可以直接执行 tar -zxvf dist-202212121201.zip -C/usr/share/nginx/dbg_area，不过前端需要的nginx的知识点不过，就是部署一下，哦，对，有的项目用的nginx路由指向前端机器，这个也需要关注一下
6、还要学用sequlize操作mysql数据库
这里先大体写个步骤吧，每天事太多了，还没来得及梳理呢，改天梳理上。
印象最深的是后端java大哥告诉我，不能把mysql数据库密码写到代码里，要以文件形势加密写入到机器的某个位置。
而系统里需要先读取文件，再解密，再去做为连接池，去操作mysql数据库。
哦，对了，本地还装了个破mysql ，还弄了个免安装的小海豚，可以自己建表玩。
快要2023年了，感觉今年的冬天，好冷啊
-- 经海路大白狗 记录于 2022年12月 某个寒冷的星期六、五棵松 - CSDN平台 --
名人名言：当你离目的地更近一站的时候，你会发现，可能到目的地的公交车就会多一趟。