离职跳槽再启航——三十二岁C++老程序员两年来的心路历程(一）

2023年2月14日，天气阴，偶尔有太阳出没，刮风，比较冷，冬天还在持续，最近一两周的时间里没有一个像样的晴天。

去银行办了新公司的工资卡，提交了所有入职材料，整理了新租的房间，熟悉周围环境，为明天开始的全新工作生涯做准备。

昨天下午，经过漫长、“欢快”的告别，终于拿到离职证明，彻底跟老公司说了再见，回顾在老东家近两年的时光，怀念不舍，却又只能义无反顾。做个全面系统的总结吧，为往事画一个句号。

三十岁换赛道

21年3月份的时候，开始寻找新的工作机会，最开始就被前同事推荐了公司的人机交互方面的岗位，跟该岗位的直属上级交流后，他同意接收，但由于对相关领域实在缺乏了解，简历写的驴唇不对马嘴，在简历这关就直接被hr毙掉了。

后面入职了其他公司，试用期半个月左右的时候，把编辑过的简历又通过boss投了公司别的岗位（算法工程化，这个并不了解的岗位，为后面埋下了伏笔）。没想到这次简历通过，经过三轮面试拿到了offer，待遇比当时入职的公司高了一些（后来了解到，我要的薪酬还是偏少了，实在没想到当时的新能源、自动驾驶行业如此高薪）。经过多方考虑，在辗转两个多月的时间后，于2021年6月9日最终入职了公司的算法工程化团队。

一些细节见：两年时间，年薪从16到45，一个30岁程序猿的碎碎念

两年来的工作

团队主要有三个方向：
1.云原生，基于gitlab artifact 云服务buildburn等基础设施，部署多种微服务(主要是在gitlab中运行相应的pipeline)，设置云机器的伸缩策略，定制各种docker容器，管理开发过程中的所有相关文件，持续监控所有机器、服务的运行状态，充分利用和发挥云平台的弹性+分布式优势，为公司研发降本增效
2.Toolchains，工具链相关，最主要的是一个对snapshot的管理工具链，包括上传、查询、拉取、部署、运行、停止、定时清理等，有命令行和网页端两个入口；另外还有一些辅助性的，比如将snapshot/tags/ jira等绑定在一起集成显示，比如统计pipeline中job失败的次数、原因等等，感觉和数据库打交道较多~；
3.V&V，验证与确认，相对来说与业务打交道多一些，负责编译工具链(bazel、buildtools、多仓代码合并编译、提交)，代码分仓解耦，代码格式检查，代码静态动态分析，coverage，license合规等

我隶属于V&V小组，是国内整个大团队里除了两个入职很早的员工外，第一个入职的，刚好遇到当时最紧急的静态分析相关，于是便入了静态分析的坑。大概讲一下这块内容。

静态分析

静态分析：是指在不运行代码的方式下，通过词法分析、语法分析、控制流、数据流分析等技术对程序代码进行扫描，验证代码是否满足规范性、安全性、可靠性、可维护性等指标的一种代码分析技术

公司买了一个付费的商业软件对各个团队提交的代码进行检查，因为质量管理需求，所以需要集成到pipeline里，主要是通过gitlab提供的CICD/pipeline功能，写一些yaml语法，调用该软件的命令行工具，检查分析代码，将软件的分析结果上传，并且在job中对分析结果的错误等级和错误数量进行统计，如果检查出严重错误，或者错误超过一定数量等情况，就判断job失败，不允许代码合入；

集成到pipeline的过程中遇到了很多问题（本身该软件更适合单机版本，拥有完整的gui客户端，但因为证书数量原因，无法做到每台电脑都安装）：
1.分析时间超级长，最开始的时候，有些代码仓分析下来超过20多个小时，对于CICD来说，超过半小时就已经算是不合格
2.分析结果不一致，误报，漏报，因配置文件不完善引发的一系列问题等，导致各个开发抱怨
3.分析软件本身导致的job失败，比如分析异常，上传分析结果失败，获取证书失败，dashboard打开失败/太慢等
4.其他

针对这些问题，我和另外一个在美国的中国同事(他比我来的早)，进行了一系列的研究优化，比如切分part分析，屏蔽第三方文件，增量分析，优化dashboard查看列表，减少dataflow的分析嵌套数，代码符合规范时不上传分析结果，完善配置文件等，最终取得了一定的效果：
1.分析时间降低，大部分增量分析的时间在10min钟内，最多不超过半小时
2.分析结果较为稳定，极少数误报，需要retry
3.分析结果统计与判定较为合理完善，dashboard打开基本在10秒之内
4.其他

最开始我以为静态分析只是工作中的很小一部分，然而没想到这些内容却是我在公司的主要工作内容和任务了，实现了上述的效果之外与之后，就是反反复复做一些简单琐碎的事情，push别的团队修改工具检查出来的问题，做一些细节优化，改一些参数配置，测试一些简单的功能feature等等，这样的维护工作一直持续到我最后离职，并且占据日常较多的KPI。

在静态分析最紧急的一些问题解决后，接手了动态分析的工作。

动态分析

动态分析：动态代码分析是一种在应用程序执行期间分析应用程序的方法。这种方法有助于暴露只能在运行时发现的漏洞和错误，例如内存泄漏、未初始化的访问、并发问题、未定义的行为情况等等。

公司主要采用google的sanitizer、gpeftools等动态分析工具，选定运行的代码，在编译代码时添加相应的debug选项，在运行时设置相应环境变量(比如 export ASAN_OPTIONS=xxxx)，来实现动态分析；使用数据回放、仿真等手段来提升代码覆盖率；
我这边的主要工作是：
1.将动态分析的上述流程——添加编译选项/运行选项——集成到pipeline中，定期运行（和静态分析的方法差不多，大概就是一些bash命令，加yaml自带的语法规则）
2.自动化解析动态分析生成的日志文件，将其中属于公司自身代码的问题查找出来，自动化查找责任人，创建相应的gitlab issue指派给他，并限定修复时间
3.解决基于上述两个任务中遇到的问题，并优化相应的流程。

动态分析对业务代码依赖较多，经常遇到编译不过、运行crash（添加debug信息导致），第三方代码导致错误，环境修改等等问题，几乎每隔一段时间就需要返工一次，并没有做出特别的成绩。

动态分析作为代码质量管理的一个重要方法，对团队、公司来说是不可或缺的部分，但老实说，我们团队做的不算成功，只是运行了一遍动态分析流程，实际上运行的效果、覆盖率、模块是否crash等，我们并不清楚，这也是支持团队不了解业务系统的尴尬点，始终停留在表面。这一点没有做好，其实与我的直接leader有很大关系，后面细说。

回首近两年时间，一行工作的c++代码都没写，而这些琐碎、且成就感很低的东西成了我的主要kpi，时间大多消耗在自我漫游上，每天都要考虑如何熬过例会，每周都要头疼如何写周报。