本文是2024年上半年的经验总结
个人成长
学习新东西和分享内容虽好, 但要避免乌龙
实验的场景有问题, 最后得出的结论确实想要的, 分享出去之后才发现场景的问题, 导致结论也是错的.
工具最好配备文档, 继续常见问题
写了工具之后, 其他人使用过程中免不了有疑问, 如果逐一回答则会耗费精力, 所以最好把常见的写到文档中, 其他人有问题, 先让对面去看文档.
分享出去的工具, 在精不在多
多了之后, 不精的工具会耗费精力去答疑和修改, 所以分享就要分享好用的, 而不是随手写的就分享出去.
多多钻研和发现值得思考的内容
- 编译出的elf文件为什么这么大? elf文件中有哪些内容? 这些内容中哪些可以减小? 如何减小? 减小了有何影响, 这里搞完之后收获还是有的.
- elf文件变大之后, gdb分析变慢, 对gdb使用火焰图发现是在解析符号表, 所以才会卡慢.
- 服务器占用xx内存, 这些内存占用必定有他的原因和使用位置, 如何对这些进行分析整理?
总迭代时间超过半年的编译发布流水线的更新记录和反思
编译发布流水线经过多次修改, 有的修改甚至到了重写地步, 总结发现下为什么没有一开始就能发现这些问题.
- 初版直接把本地的编译命令放到了流水线的shell脚本中, 开了超多条流水线, 每条都写了很多代码
- 写了个超长的函数更新各个submodule, 流水线的更新并不好用
- 要求自动更新服务器, 修改编译上传脚本将版本号保存到本地, 修改发布脚本支持读取
- 要求能够发布IDC的版本, 将原本初版的流水线完全拷贝了一份用来编译release版本, 区分了space导致release和debug无法混发到腾讯云
- 要求支持指定submodule的分支发布, 发现改所有的流水线代码比较麻烦, 统一了更新部分
- 发布重试的要求, 统一了构建部分
- 要求增加海外部分, 如果再开一条流水线将会导致数量继续增加. 直接把构建部分全写到了脚本来控制.
- 上传有失败, 增加了上传重试
- 分支有/增加了转义
- 流水线加上了code_branch分组功能, 防止冲突.
- 用分支名命名感觉还是有点问题, 目前看还能抗住
- 异常错误处理, 编译会有编译加速失败, 这个还没加重试
- 目前一个发布环境也会有多套了, 不能再只用idc, test当做版本号标识了.
- 一步到位, 把相关信息作为msg发到平台, 更新的时候不再读取本地版本号. 不使用花里胡哨的版本号标识, 直接使用构建信息.
多多学习和消化公司已有的学习资源
- Q-Learning和KM内容太多了, 可以用来扩充知识面, 还能选取感兴趣的点进行深入学习.
- 还可以看看已经公开的晋升文档, 看看其他人搞了什么内容, 从中选取自己感兴趣的点.
工作
详细了解需求的背景和要求后再动手
- 防止一句话需求的理解存在偏差
- 防止实现错误, 最后还要进行修改, 如果带到了测试环境甚至线上, 修改的难度和不稳定会越来越大.
需求做到位即可, 防止做了没必要且无用的内容
需求中一个功能本来可以用简单的方法实现, 却用了复杂的实现方式, 最后反而效果不好, 得不偿失.
需求实现成本高的地方和产品沟通
看看能不能换成本较低, 效果略微降低的方案.
服务器命名问题
新加了一大批服务器, 起初我想通过命名给这些服务器赋予功能, 但是会导致服务器的名字难以记忆, 最后分离了开来, 命名使用了简单的方式, 至于服务器的功能则额外加了一张功能表.
加深自己参与的服务器各个模块的理解
这样才能在商定各个服务器分工的时候, 给出合理的解释, 方便进行快速的分工.