2022年底，我手里一共负责了30套系统

Posted 2022-12-19 经海路大白狗

2022年真是不平凡的一年，往常熙熙攘攘的办公室人越来越少，真是像曹操说的兄弟相继凋零，好似风中落叶啊。

结果人少了，手里的系统一个没少，慢慢年底了，我汇总了一下，手里的系统达到了30来个。

搞不定怎么办？我是这么做的

 

目录

1、 区分系统的重要程度

2、P3级别的文档梳理

3、P2级别的文档梳理

4、P1级的文档梳理

5、把前端代码部署到nginx服务器

6、还要学用sequlize操作mysql数据库

---

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 [e-mail].x:/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平台 --

名人名言：当你离目的地更近一站的时候，你会发现，可能到目的地的公交车就会多一趟。