5.14 - 第一次接 P0

现在是 5.14 晚上 22:08，写一下今天的日记。

上午

今天上午的话，吃完早饭就开始开发昨天那个需求了，捋了捋相关代码，写着还是比较简单的，不过设计一个选择，类似于一个链路 1，一个链路 2，当链路 1 的其中一个身份打到时需要额外投递到 链路 2 一份，此时实现上有多种选择。

保存独特状态
调用链路2
回放独特状态

当然也可以直接粗暴的复制链路 2 的代码，也就是核心逻辑略微修修，移除一些保存状态的逻辑即可。

因为 golang 的 defer 机制，因此在埋点时这个状态回放是必须的，但我觉得为了后续可能的定制化，还是复制一份会更好，前者有点像是糊shi。

然后 review 时发现一个降级需求会导致重发，补了一下判断。

上午对开发感觉比较新颖的也就是引入了 tcc 做灰度，其他的基本都是常规开发，捋业务，写代码。

下午

吃完饭提了开发单，然后开发质量门禁一遍过，接着就是测试了，这个测试就说没有对应功能，然后给个 logid 就没其他有效消息了，全靠自己找，今天主要是熟悉了一下 debug 流程，然后顺着链路一个一个找，因为我看日志根本就没有我这个服务的，一天全在排查这个东西，没了 ai 协助还是很吃力的，所以花了接近一个下午 + 晚上才捋明白，大概率是服务调用的下游服务与它不在一个机房导致的，明天让他全量所有机房再试试。

忙里偷闲的把昨天的下线那个需求全量下线了一下，又是权限权限权限，没招了真的，慢慢申请吧，在 4 点左右终于全量上线了。

今天这个需求下午 5 点半给我拉到了对应的 meego，真没想到居然是 P0 需求，感觉代码开发难度没那么大，主要是和各方对接比较费精力吧，等这个需求上线了，我就是入职 12 天解决 p0(doge) 了。

今天比较开阔视野，见识到了不一样的对接流程，以及 log 审查平台、总线配置平台 等等工具，下次 debug 应该会轻松很多。

今天差不多就这样，明天见~