第162章 Code Review（1/2）

周四上午十点，T厂AI平台部每周例行的CodeReview环节。

会议室的大屏上投射着林晨前两天修改完的代码，旁边还并排展示着另外两位同事的待审分支。围坐的六个人面前各摆着笔记本，桌上散落着咖啡罐和零食包装袋，气氛倒更像一场非正式的技术沙龙，而非严肃的审判庭。

先过林晨这版。王皓推了推眼镜，点开了合并请求。作为团队的直属主管，王皓每周四的CodeReview会议既是技术把关，也是团队学习的场合。

林晨坐在长桌末端，脊背挺直，手指不自觉地摩挲着笔帽。这是他第一次正式参加团队的CodeReview会议。之前只是被动地收到模块原开发者王工的审查意见，自己修改后重新提交。而现在，他要面对面地听同事们逐行审视他的代码，当场回应质疑。

这种感觉，和一个人埋头写代码、跑测试完全不同。更像是一场公开答辩，只不过台下坐着的不是考官，而是并肩作战的队友。

整体结构清晰了，老赵先开了口，手指在大屏上划过林晨重构后的批量特征获取逻辑，把串行调用改成批量查询这个思路是对的，缓存层的引入也合理。不过——

他放大了其中一段代码：这里，缓存失效策略用的是固定时间窗口，TTL设的多少？

默认的300秒。林晨回答。

300秒对于用户画像这种高频更新数据来说偏长了。老赵直截了当，画像特征更新频率大概是两到三分钟一次，你的缓存可能在特征已经变化了的情况下还在返回旧值。建议改成基于版本号的主动失效，或者至少把TTL压到120秒以内，配合一个灰度验证。

林晨点头，在笔记本上飞速记下。这个他确实没考虑到，当时只想着减少远程调用次数，对缓存一致性这一层想得粗了。

许悦接着指出了另一个问题：降级逻辑这里，你用最近行为热度池做兜底，逻辑本身没问题，但权重系数的硬编码方式容易维护出问题。你定义了常量，注释也写了来源，这个比第一次好多了——她笑了笑，不过我建议进一步把所有可配置参数抽到配置中心，这样上线后可以动态调整，不需要重新部署。

好建议。林晨认真点头。从写死到常量，再到外部配置中心，这是工程化思维逐层递进的过程。他在量化系统里也干过类似的事，只是到了T厂的规模，每一个配置项的改动都影响数亿用户，对灵活性和安全性的要求自然更高。

王皓翻到单元测试部分，扫了几眼，抬头看着林晨：测试覆盖率86%，比上次好。不过我注意到你的降级测试用例里，模拟外部服务超时的场景用的是固定延迟。实际线上环境，超时不是简单的到点断开，可能是先慢后断，也可能间歇性恢复。你的测试能不能覆盖这种不稳定的中间态？

林晨愣了一下。他确实没有考虑到这种情况。你说得对，我只模拟了干净利落的超时，没有考虑半死不活的模糊状态。我回去补一组混沌测试用例，模拟延迟波动和间歇性恢复。

用esh或者自己写个简单的故障注入脚本都行。王皓语气随意，但信息密度很高，我们内部有封装好的混沌工程工具包，Wiki上搜ChaosToolkit，里面有模板。

收到。林晨记下来。

整个Review持续了将近四十分钟。六个人一共提出了十一处修改建议和六条优化方向，涉及缓存策略、配置管理、测试覆盖、日志规范、监控埋点、灰度方案等方方面面。密度不可谓不大。

但林晨注意到了一个细节：没有人用你这里写错了这样不对之类的措辞。取而代之的是这里可以考虑……建议改成……你有没有想过……。甚至有人会在指出问题的同时，主动分享自己之前踩过的类似坑。

本章未完，点击下一页继续阅读。