工作满一年：经历篇（上）——初出茅庐：在混乱中快速成长（末期项目）

如前所述，来陪我一起回忆回忆，这一年来的工作经历，重走一遍心路历程。

本文是《经历篇》上篇，大概对应工作的前 5 个月，4 月中到 9 月。

内容会比较随意，想到啥写啥，详略非常不得当。

一、入职前

还没进公司就换组？

当时面的是 AI 产品的后端研发岗。

大概 1 月左右，就加了 mentor（目前大部分互联网公司都有的机制，带新人熟悉业务、适应公司节奏，更像是伙伴关系）。

原本打算 6 月底毕业再入职，但在 3 月左右，传出公司有一波大裁员。我怕会被毁 offer，就打算直接在提交完毕业论文后（4 月中旬）马上入职了。

在入职前几天，突然有人加我微信说是公司的技术 leader。我很是欣喜，说我 4 月马上来。

然后就把这个消息分享给了 mentor，但是 mentor 给我来了个晴天霹雳，他说：

「我不认识他啊，你是不是被换组了」。

我呆住了，只能「小心求证」。

我和 leader 发消息说，我想知道我会负责 「xxx 部门」 的哪些业务，有没有什么可以提前学起来的。

果不其然，leader 说他不是这个部门的。

于是我又不死心，谨慎地发了条消息，表示：

• 我不知情：之前没有收到换部门的 HR 通知
• 为什么喜欢原来的组：自己对 AI 更感兴趣，论文也匹配项目组，
• 我接下来要做什么：想向 HR 求证沟通一下

不出所料，HR 说了一通，总结起来就是，「综合考虑，我觉得这个项目组更适合你的发展」。

哈哈哈！

刚入职那几天

入职的上午还是挺开心的，互联网公司福利都还不错，M3 pro，员工服务的细节也很到位。

中午一下子就开心不起来了：嗯，为什么是写 Java？

要知道，我研究生的时候，可是「弃 Java 投 Go」了的，现在是一个虔诚到癫狂的 Go 教徒！

马上化身为小胡适，第一天想跑路，第二天想跑路，第三天还想是跑路。

话说回来，线下见了 leader，很 nice，是我很喜欢的务实技术风，沟通非常顺畅。当天晚上就给我详细讲了部门的现状、规划，以及建议我进公司前两年加强哪方面的能力。

第一年推荐我增强硬实力，以及熟悉公司的组件。现在看来整体上算是做到了，起码算是熟练工了 hhh。（但是成为熟练工是没意义的，只是依托于公司。更应该去思考，如果离开了现在的公司，自己的工作效率是会怎么样的。这方面内容，会在后续的《疯狂篇》中尝试思考）

mentor 人也非常 nice，很真诚+有实力，帮助与启发了我很多。我等会就讲。

入职没多久就出差，在外地酒店过了我的生日，和 leader+mentor+另外一个同事一起过的。挺温馨的，当时大家一起聊了很多，都是肺腑之言。

关于跑路？

最终肯定是没跑哈！都苟一年了！

我曾经试想过很多可能性（就不展开了 hhh），但最终还是选择坚持下来。

其实主要还是组内的氛围很不错，leader、mentor 和同事人都很好，大家都互相帮助，都是能够交心的人。人和项目，起码有一个。

当然更多的是客观原因，比如更大的平台，更多的学习与成长机会，可能会在《疯狂篇》中展开。

现在，先回到主线！

二、天崩开局

我所在的组是一个处于一个末期的项目，用数字来描述就是，从 100 到 101 的项目，甚至从 100 到 0。

• 人力困境（根本困境）：末期项目，自然老板不太愿意继续投入人力。所以这会造成一个恶性循环：没人 → 没成果+bug 多 → 老板觉得项目不重要 → 更没人。全盛时期至少 20+人，现在<5 人。
• 开发环境困境：历史遗留项目，环境安装依赖麻烦
• 代码困境：项目多年前的代码是外包写的，质量并不高。感觉学不到太多语言本身的东西（还是有一些能学的）
• 历史包袱：业务逻辑复杂，且很多代码中写着是「临时方案」，却没等到最终方案。甚至真的有建立在 bug 上的 feature，上下游依赖太多，保证兼容性是最重要的。
• 文档老旧+交接断代：大部分文档都是过时的，或者链接到另外一个文档，然后再点进去没权限。
• 重要性（不能出错）：它是公司的一个中台，被集成到很多公司业务中，一旦计算失误，影响面很大，而且 CEO 和高管们强感知。
• 微服务复杂：一共大概 5 个左右的重要微服务，几十万行代码

其实万事都有对策，都能从不同程度去解决或改善。但这会让大部分精力花在无意义上的事情上。不能把大部分精力花在重要、正确的事情上，本身就是很可怕的。

三、 困境下大家的工作状态

在项目组期间，我们大部分时间都是在 Oncall。

甚至，很多时候业务方提的问题，我们自己都不知道有这个功能，先让业务方教会我们怎么用，然后我们再现场找到它对应哪个代码仓库，把代码克隆下来，现场看。

所以那段时间，看陌生代码的能力真的提高挺多的。还有问题排查的能力，通过各种日志+诊断工具，快速二分问题发生点。例如，确定是否是上下游原因、是否和基建相关、是哪个微服务、是链路中的哪一步有问题等等。然后现场构造数据在测试环境测试。

开发的时候也是，首要任务并不是实现功能，而是摸清历史老逻辑，保证兼容性。

还有各种各样乱七八糟的事情，例如安全工单、海外部署等等。

四、和 mentor 的日常

和 mentor 相处得还是挺融洽的，大概 5 月多他就从北京 rebase 到我们工区了，就坐我旁边。所以我也很幸运，有问题能够直接问。

他是一个不厌其烦，又热爱技术的人，所以能「接得住」我的各种讨论邀约。比如，我会问他，

• 这个功能，我有好几种实现方式，你觉得哪种最符合 Java 的哲学？
• 让我学学你是怎么排查问题的
• 你是怎么得到精准的数据的？例如多大规则的数据的数据库查询/写入时间？
• 有时我甚至会和他探讨变量怎么命名
• 更多的，还有各种技术品味上的探讨、学习、耳濡目染

他也会主动给我分享一些效率技巧，例如利用公司通讯软件的消息分组功能来实现不同等级的消息提醒。

除了各种技术细节，整个软件开发生命周期，他也很尽职尽责，我学到了很多：

• 评需求时，认真和产品讨论，平衡易用度与技术实现复杂度
• 交给我做的需求，会认真得讲明前因后果：最开始这个模块是如何诞生的，它现在有哪些坑要注意，当前需求大概要做什么，我可以大概怎么做
• 我大概理解后，让我再复述一遍，确保真的懂了
• 事后再认真得去 review 代码。对了，还有写自测文档，我大部分需求都会自己写一些自测文档（一直保留到现在），对上线保持敬畏，同时也能尽可能减少出错的可能性
• 还有对整个项目风险的把控，及时问我的进度，以及是否有困难等

整个职业生涯，也有些帮助和启发

• 会主动问我，这个事情大概怎么样了，有什么想法。然后和我说，这个事情是我主导的，所以关乎我的绩效，如果觉得重要，主动和领导申请时间去高优做它。
• 还耳濡目染一些和产品、和业务沟通的小技巧~

五、第一个需求？害怕！

第一个需求其实很简单，用 jasypt 加密一下敏感配置就行，目的还是熟悉一下公司的发布流水线。

但是，上线就崩了！（服务是滚动升级的，所以只是小部分容器无法启动，还好）

当时是 mentor 主导排查。快速排查后，总结了一些现象，无法找到根因，于是立即操作回滚。

当时的现象大概是：

• 我们有 N 个部署区，只有一个部署区服务无法启动
• 服务最后一条有效日期是 关于 jasypt 读取配置的
• CPU 打满，且几乎都是 Spring 占据
• jstack 发现服务卡在 jaspyt 的某一行
• 由于只有一个部署区域没启动起来，所以怀疑冷启动配置不一致。进容器发现是一致的。

这件事给我的印象很深刻，刚入职就深深地给我上了一课。

一是，对线上的敬畏。

二是，遇到线上问题时排查的思路，以及快速回滚止损。

最后我通过问题代码的定位+网络搜索，发现了是 jasypt 的旧版本的一个 bug，github 上有 issue。

于是我主动写了一个复盘文档，分享到群里，包含以下内容：

• 总结放在最前
  • 根因：避免在 Java8 中递归调用 ConcurrentHashMap.computeIfAbsent()，或者修改 map 的任何操作，可能会死锁
  • 修复方法：升级 jasypt
• 背景：还原事情 + mentor 的排查
• 资料搜索：github issue + stack overflow
• 自己写代码复现（最简版本）：代码+截图
• 贴 jasypt 核心代码，证明与最简版本是同一个问题
• 相关参考资料

六、偏个题，经历篇前身？

看到这里，你可能会非常好奇，我咋记得这么清楚？

其实我虽然没有写什么外部的分享，但是自己一直在记录零散的日常和反思。

其中，比较完整，或者说正式的记录，有两次：

一次是 9 月的时候，我写了个《阶段性学习总结》。按线性的方式，以时间顺序，列举一个个需求，记录：

• 需求链接、相关文档
• 我做了什么
• 收获是什么（技术能力、协调沟通能力、公司基建熟悉等等）

一次是转正述职报告。更注重外部视角，介绍我做了什么，难点是什么，怎么做的，为什么这么做，产出与数据，感悟。还附了各种各样的业务、技术架构图，方便理解。

简单来说，第一篇文档是个人视角的细节罗列，第二篇文档是在系统性总结+吹牛逼

那这篇文档《经历篇（上）》到底又该写什么？难道 copy 一遍？

所以我更侧重于，写成长本身，把事情+解决方案作为背景，引出思考与执行过程。

七、干的一些「脏活」

工作中肯定是大小需求夹杂着的，我们也没有挑需求的能力。

能做到的只能是把每个需求都做漂亮。

比较零碎的活有，各种安全工单、接口打标、批量替换上游服务的域名（并保证系统正常可用）等。

这类活的特点是五花八门+容易出错+重复性劳动。其中，重复劳动和容易出错是相辅相成的，因为容易懈怠，懈怠就容易出错。

所以我一般采取的办法都是，边操作边写文档，一方面是留痕，一方面是记录自己做到哪了（防止被打断后不知道从哪些继续），还有就是方便别人 review。

总而言之，认真对待脏活，做好，是工作的底线。同时只有把小事做好，才能获取大家的信任，做更大的事情。

八、砍掉/简化/主动提出的需求

首先说明，并不是以砍需求和减工作量为荣，而是通过和产品沟通，去保证双方最终利益（业务结果）的基本前提下，去优化需求的实现方式与投入。（并不是扯皮说不做需求，是站在同一视角去思考需求）。

上面的话是我在转正述职文档中写的，这里直接拿过来。

优秀的研发一定是能做到产研协同的，就像公司和个人的目标需要一致，产品和研发的目标也需要一致。

有太多太多坑，都是因为需求阶段做得不好

• 要么是实现的内容与业务偏差过大（导致需求频繁变更）
• 要么是当前的需求根本就不符合整个产品的设计（导致在原有架构上各种开口子）
• 要么是产品想实现 A 效果，但是提出了 B 功能，研发以 C 的方式去实现。最终三方都不满意。如果沟通足够，如果大家都能发现 ABC 的差异，就能找到新的路 D，反而可以降低开发成本、提升产品体验、降低系统风险。
• 还有的时候，产品没想清楚自己要的是什么，或者不知道半年后一年后要做什么，无法给研发一个整体的业务迭代预期，会导致研发难以设计优秀的业务架构。

来继续讲讲砍掉/简化/主动提出的需求吧，各挑一个好了。

8.1 简化的需求

• 背景：有一次我在写技术方案的时候，发现产品的 PRD 很简单，但是技术实现上非常复杂。背景是一个低代码系统，需要在表单的提交按钮上，做一些校验
• 复杂性：
  • 业务的复杂性：
    • 数据状态异构：用户配置的表单其实是中间态数据，我们还有个后端会把低代码平台的表单打平成一份新的终态数据。
    • 代码重复：如果想在每次表单提交后都做校验，那需要在低代码平台模拟打平逻辑，并且需要基于中间态数据与终态数据联合校验。
    • 校验逻辑复杂：业务复杂，case 非常多。
  • 低代码平台复杂性：低代码系统是有能力边界的
    • 同一个实体的数据量超过千万后，性能明显下降；
    • 表单上的提交按钮上绑定事件，需要 JS，而 JS 是弱类型的，bug 风险更高。
• 我是怎么做的：
  • 先写一份整体的技术方案，分 case 列一下，各种情况该如何校验
  • 拉 mentor+产品+测试，开会整体过一下
  • 开会到一半，大家一致觉得这样做太复杂了，开发、测试风险都高
• 最终：
  • 大家一起商讨出了一个简单、高效的方案
  • 低代码平台不校验，而是在发布时向后端发送「预发布」指令，由后端生成一个预览版本
  • 复用数仓团队之前写好的「对打平后的数据直接校验」的逻辑

8.2 砍掉的需求

产品希望能够将两个系统的权限申请联动起来。在用户获得 A 产品的 a 权限后，系统自动找到 B 产品相关的 b 权限，执行授权。

我觉得需求不合理，做起来也很脏，理由大概如下：

• 业务+技术上：两边产品的权限模型不是一对一的，是多对多的。这个自动授权是与逻辑还是或逻辑，即，是拥有了 A 产品的某个模块的所有权限，就能授权 B 产品相关的模块的权限，还是任意？
• 技术上：双方权限模型的映射关系，还不能硬编码，因为随时会变化。要一直互相兼容。
• 业务上：自动授权是隐式的，体验上不好

当然我也给了解决方案，就是两边都将自身的权限模型提供一个新的外部模型，这个模型要相对稳定，类似于防腐层的作用。双方基于这两个新的防腐层权限模型，基于消息队列做双向自动授权。

另一个产品的研发听了后，也非常赞同，觉得不应该做。

8.3 主动提出的需求

不详细展开了，记得有主动提出的技术需求，也有业务方反馈给我，我将其转化的产品需求。

九、一次技术上的挑战

接上文，在引入了「预发布」的概念后，需要对状态机做调整。

但是老项目很屎山，真不敢动，但必须要动。

9.1 背景

整体来看，整个系统就是在【低代码平台】配置表单，然后发布到【后端】生成最终数据。

9.2 难点

难点概述：【低代码平台】 + 【后端】二者实际上形成了 【联合状态机】。

• 环境复杂： 低代码平台只在中国区有，后端有 3 个地域 3 份数据，一对多。甚至可能因为网络等复杂原因，发生部分成功部分失败的情况。
• 状态复杂：
  • 低代码有 6 个数据流转状态：编辑中、预发布中、预发布完成、发布失败、预发布完成、正式发布
  • 后端有 4 个状态：初始化、数据生成成功（预发布）、发布失败、最终启用
  • 二者之间的状态转换非常复杂，原先的状态机勉强能运行
  • 现在再加一个状态很容易出现未出现的 中间态、异常态 ，导致整个系统不可用。
• 数据易错乱： 每次发布时都是后端全量更新数据（删旧+加新）（因为一个版本的数据量在百万级），同时更新最终生效版本号。 极易误删数据 或 生效版本号设置错误。
• 发布触发逻辑多样：发布时既有低代码主动发布触发的更新，也有定时任务每天自动从低代码主动拉数据作为兜底。
• 代码复杂：用的是 if…else…的逻辑，但 if else 本质上是隐含了通过离散数学逻辑的方式做过一些逻辑合并，如果不仔细梳理，无法确定新增状态后【if…else…】是否需要拆分出新的子分支。

还有很多细节，例如要设计低代码平台的每个按钮的禁用逻辑，按钮提交的前置校验，还有错误容忍与纠正能力，甚至考虑网络错误等。

一定要保证系统是极其健壮不会出错的。

9.3 解决方案

每个系统的状态、操作实在太多了，该怎么梳理呢？

答案是，倒推！

系统怎么才是稳定的，终态要求 如下：

• 正确性要求（有可用数据） ：后端数据库中，有且仅有一版数据在启用中
• 性能要求（无冗余数据） ：后端数据库中，最多有两个版本数据，一个是生效中，一个是预发布中（或失败）。（也就是要能自动清理无用数据）

如何保证终态？通过 三个核心准则 保证：

1. 限制【低代码平台】的非法操作，即，根据终态，反推各类按钮的前置状态校验逻辑，和提交按钮后的并发校验逻辑
2. 限制【后端】的版本数据误操作
3. 两个系统实现操作的幂等，并且中间态与异常态能够通过接口回归到正常态

再往后就是将核心准则 拆解为细节 ，比如：

• 后端视角（终态 2）：在启用版本时，删除上一版本的数据；在禁用版本时，删除当前版本的数据；
• 后端视角（终态 1）：无论如何，当前版本不可被禁用；只有在新版本正式生效时，才会将历史版本自动禁用并删除。
• 低代码视角（准则 1）：整个表单系统中，只允许存在一个版本的编辑中数据。如果想新建版本，可以禁用表单的老版本，同时禁用的时候又会自动清除后端已发布的脏数据。
• 中间态或异常态的修复（准则 3）：假设每个版本发布后，只在后端的 3 个环境中的 N 个环境「预发布」成功，发生了跨环境数据不一致问题。这时候直接禁用，同时清空 3 环境的脏数据，升级版本重新发布即可。
• 还有很多细节就不一一赘述了。

在这个需求中，我画了很多流程图，既有梳理历史状态机的，也有解释新状态机的。既是保证自己不出错，也是为后续接手的人留下宝贵的财富。

这次需求后，也获得了两个很宝贵的经验沉淀：

1. 每个系统应该尽可能保证自身的稳定性。即，先保证自身边界清晰与稳定，再考虑组合稳定性。
2. 优化系统，不要过于被当前的不良状态掣肘，应该思考最优雅的终态是什么，再朝着终态演进

十、Oncall 治理（AI Oncall 拦截）

10.1 引子

就像前面说的，部门里由于中台属性+历史悠久+定制多+交接乱，导致 Oncall 人力耗时极大，希望能用各种手段降低 RD 的 Oncall 人力消耗。

其实我刚来差不多两星期，这个活就交到我手上了，也许是当时我是唯一一个校招生，所以最闲，正好把这个「不知道要花多久，也不知道效益如何」的活给我。

所以这个活，其实是「可大可小」的。

10.2 初次开展

我还是比较幸运的，当时刚好公司另外一个部门 A，正在做一个新工具，利用 RAG 做 Oncall 提效。

当时整个大部门在由上往下推，我刚好就成为了他们的第一个试点部门。

部门 A 基于当时的历史 Oncall 聊天记录，聚类了一些高频 FAQ。

所以我的任务就是，拉着小组其他几个人，把 FAQ 补全。因为每个人负责的模块不一致，以及很多细节只有项目组老人知道，甚至没人知道。

这个在当时对我来说还是个小小的挑战，是第一次拉着其他人，请求别人一起帮忙。

好在大家其实人都很好，所以开展起来没遇到什么阻力。

10.3 正式启动

记不清当时背景是什么了，我写了个文档，叫作【XX 部门 Oncall 拦截梳理及 Action 制定】。

背景应该是多方面混杂的，有主动也有被动。比如这个项目工作量肯定不低所以要制定一下整体的策略让大家 review，同时这样也能让大家都参与进来帮忙，以及当时可能领导的领导比较关心做事的 ROI，所以需要我列出很多数据来证明 Oncall 治理的必要性和收益。

文档大概是这样的：

• 第一段：总结拦截 Oncall 的手段。
  • 用户咨询类：基于那个部门提供的 RAG 能力，用 AI 做前置拦截
  • 需要研发介入的：开放、制作排障工具，让使用了我们中台的业务方先尽可能自己排查。
  • 工作量转移大法：让技术支持、产品、测试 前置拦截一些 Oncall
• 第二段：基于第一段大概展开一下为什么。然后这里还叠了个甲，因为每个 Oncall 的耗时可能不同，通过 AI 等方式能拦截的都是通用的能快速解决的；有些需要深入排查甚至找代码 bug 的 Oncall 很难有作用
• 第三段：统计一下当前的 Oncall 现状，计算一下总数、技术支持的拦截率等。
• 第四段：详细展开几个手段应该怎么做，具体的 Action 是什么，尽可能细化到人
• 第五段：提出后期 AI Oncall 的 SOP。
  • 用户 Oncall 时，先基于历史工单和文档 RAG 首次拦截
  • 然后是技术支持拦截，基于人工的文档检索和使用后台诊断工具排查
  • 最后是研发介入。介入时先判断一下是不是 AI 本该能解决的问题；解决后，如果当前问题能通过沉淀文档解决，就顺手更新知识库
  • AI 定期自动继续挖掘高频问题
• 第六段：定一下每个季度的 milestone（要完成哪些事项）

10.4 徐徐展开

后面的几个月里，整体上都是我保持和 AI 团队的紧密沟通。通过会议，一起讨论，怎么才能提高拦截率，毕竟我们俩的目标是完全一致的。

他们每隔一段时间，也会以人工+AI 的方式，去梳理出新的高频问题，分析出哪些 AI 可能可以解决，让我们补充新的知识库。所以我也定期先尝试自己去补全，不会的再一点点请教同事。

过程中，我也提出了一些建议，或者说需求哈哈哈。

比如增加一些洞察能力，根据历史工单，判断哪些问题是高频出现的，这背后是否隐藏着一些产品和流程问题。

又比如，我们部门人员流动太大，很多文档都失传了。但是历史工单中有很多老研发们发的链接，都是十分宝贵的。这些链接都散落着，希望能基于工单历史自动提取链接并整理。

10.5 及时调整

在这之前，我也意识到了不对劲。因为需求太满了，所以我完全没有额外的完整的精力在 Oncall 治理上面，只能每周抽零碎的时间去做，但这做不成什么大点的事情。在 mentor 的建议下，取得了 leader 的同意后，我给自己建了个排期，大概空出了一星期的时间，认真去做这件事情。

到后期的时候，我们发现，由于我们部门的项目历史太悠久了，所以继续补充 AI 文档的收益有限。存在着大量的需要人工排查的个例问题。

我开始逐渐转变思路，不再高度依赖 AI 的前置文档拦截。

比如，在评估了安全性后，将部门的一些诊断工具，做成审批流，开放给业务方。然后写了一个业务方自查文档，推进大家自查。（虽然每个业务方都不希望自己动手，但是我们的人力实在不够，他们急了会自己查的，没办法）

我也亲手写了一些文档，例如我们有个产品做了商业化版。

• 公司有个角色是「客户成功经理」，类似于一对一帮企业解决问题。但我了解到，并不是一个员工负责一块业务的解答，而是一个员工负责一个公司的所有产品的使用。
• 这就很蛋疼了，每次产品有问题，遇到的都是新的客户经理，他们很可能也是第一次用我们的产品。而且绝大多数情况，都是客户+经理自己没用明白（毕竟代码很久没改了）。
• 而且这个产品，还涉及到两个部门产品的联动。
• 所以我就写了个文档，清晰得告诉客户经理，如果用户有什么问题，该如何去排查，什么 case 是哪个团队的问题，什么 case 让用户提供什么信息以及如何验证，如果这块没问题继续验证哪块
• 最后事实证明，这个文档效果非常 nice

又比如，做了一些历史文档的整理。我现在还经常能够收到消息，提示某人给某某用户开通了某个测试环境 All in One 的 FAQ 文档。

10.6 结尾

做了几个月，我就被动转岗了。是的，这就是中篇的事情了。

所以我也趁着交接的机会，又写了个 All in One 文档，既是交接，也是经验总结。

大概包含以下内容：

• 效果 & 数据 & 人力投入：贴一下产品使用效果 + 拉各种数据 （其中，AI 文档拦截率在 20%左右）
• 治理经验：
  • 和前期的文档类似，多了一些细节和维度。
  • 例如，总结哪些方面能够收敛和 ROI 高，已经做了什么和哪些还没做，以后可以如何优化等。
  • 畅想如何基于 Agent 来自动化排障。基于日志 ID + 知识库 + 工具 排障。（但是工具的开发成本太高了，对于末期项目来说，很奢侈。同时项目的业务非常非常复杂，微服务也多，其实很难做）
  • 提议：搞个跨业务方排障文档，我们和好几个团队有耦合，很多时候排查要一起进行。
• 流程交接：各类后台地址、操作文档等

10.7 一些小总结

总体上，还是做出了一些成果的，有个成语很贴切，「差强人意」。

但是遗憾也很多，一方面是人力因素，导致很难花大把时间做很大规模的东西。另一方面也是我个人胆量不够，有些东西可以更加主动地去落地与推动。

也有一些产品上的思考，我发现，想从根本上解决 Oncall 问题，还是先要做好产品本身。无论是产品的易用性，还是各种可观测能力，以及业务可解释性，又或是后台排障工具。

最后，简单收个尾~

其实这半年做的需求远不止上面这些啦，比如有增强业务可解释性（打日志）然后让数仓团队做看板的，有各种技术治理工作。

还有一次印象很深刻，改一个很核心的东西，但是历史遗留很深。我足足给那个函数写了差不多 30 行注释。写了业务背景，贴了需求和技术方案链接，解释了配置来源有两套要兼容，接口参数有两套也要互相兼容等等。最后也是自测了很久很久，才敢上线。

现在想想，还是挺怀念的（但是不想回去）。在高压和困境中，也能获得独属于这个环境的成长。

很惊艳的一点是，这个项目虽然欠缺维护，但是各种告警策略配的很多，集成测试 case 也非常丰富，所以反而在我待的那段时间没出什么事故。现在来看，这块当时应该深入学习一下。

以至于，我现在看其他项目，都是眉清目秀的。

我常调侃，这个项目组就是个进修班，定向向公司其他部门输送优秀人才。