周五下午三点，会议室的白板上还留着上一场评审的痕迹。老张把笔记本接上投屏，打开了一份代码改动记录，一共十七个文件。他没有急着讲结论，而是先把背景说清楚：这次改动来自一条线上告警，订单履约链路在大促预热期间出现了偶发的超时，平均耗时从 180 毫秒涨到了 900 毫秒，量不大，但每天都在发生。
这是他在这家公司的第五年，写代码的第八年。团队的同事习惯叫他老张，其实他今年三十三岁，不算老。这个称呼大概是三年前叫起来的——那时候他第一次主导订单中心的微服务拆分，连着两个月在工位上待到凌晨，头发白了几根，从此"老张"就固定下来了。
八年，从写接口到扛系统
老张是 2017 年入行的，第一份工作在一家做 SaaS 的中型公司，负责 CRM 模块的后端。他至今记得第一个上线需求：给客户列表加一个按标签筛选的功能。当时他写了三天，SQL 里嵌了四层子查询，被带他的师傅退回重写了两次。第二次退回时，师傅只留了一句话："你先想清楚数据量到十万条的时候，这条语句会怎么执行。"
这句话后来成了他带新人的常用开场。在他看来，后端工程师的成长有一条清晰的分界线：在分界线之前，你关心的是功能能不能跑通；在分界线之后，你关心的是它在什么条件下会跑不通。
从 CRM 到电商中台，从单体应用到微服务，从 Java 到后来大量使用 Go，老张的技术栈换过几轮。他不太愿意把这段经历描述成"技术升级"，更准确的说法是"被业务推着走"。2021 年公司订单量翻了六倍，原来的单体应用在一个月内出了三次数据库连接池耗尽的事故，拆分不是选择题，是必答题。他作为核心成员参与了整个拆分过程，从领域边界怎么划，到分布式事务用什么方案，再到灰度发布的开关设计，每一环都踩过坑。
"拆分最难的不是技术选型，"他在一次内部分享里说，"是你怎么说服所有人接受一个暂时不完美的方案。"那次分享的 PPT 只有九页，其中五页讲的是历史包袱和折中取舍。
他的技术观：先让系统站得住，再谈跑得快
和很多热衷于讨论新框架的工程师不同，老张对技术选型的态度偏保守。他有一个习惯：任何中间件进入生产环境之前，必须先回答三个问题——出故障时怎么降级、数据怎么对齐、排查问题时能看到什么。回答不上来，再热门的技术也先放一放。
去年团队评估过一轮新的服务网格方案，社区热度很高，Demo 跑得也漂亮。老张花了两周时间做压测和故障注入，最后给出的结论是不建议在当前阶段引入。理由写了两页：一是团队现有的可观测性体系还没完全覆盖，引入后排查链路会更长；二是当前业务的规模，收益不足以抵消运维复杂度。这个结论当时让几个年轻同事有点失望，但半年后另一条业务线因为类似方案导致线上问题定位困难，大家才回过头理解他的判断。
他常说的一句话是："技术债不是不能欠，但你得知道利息是多少。"在他的推动下，订单团队从 2022 年开始执行一套接口变更规范：任何对外接口的字段调整，必须同时提交兼容性说明和回滚方案；数据库的每一次 DDL，必须附上预估执行时间和锁表风险评估。这套规范刚推行时被抱怨"太重"，但两年下来，团队因为接口变更导致的线上问题从每季度四五起降到了零。
代码之外：文档、评审和复盘
在老张的工作清单里，写代码大概只占一半时间。剩下的一半，分散在设计文档、代码评审和故障复盘上。
他的设计文档有个特点：不写"我们要做什么"，先写"我们不做什么"。比如订单履约改造的方案，开篇第一段就列出了本次不涉及的范围——不改动支付回调逻辑、不调整库存扣减时序、不引入新的缓存层。他认为边界写清楚了，讨论才不会发散，评审也才有意义。
代码评审他参与得很细。团队里流传一个说法：老张评审过的 MR，注释数量通常比提交的代码行数还多。但他很少直接说"这里不对"，更多是提问式的——"这个异常如果连续抛出三次，上游会怎么处理？""这个字段如果为空，下游的兼容逻辑在哪个版本？"有新人一开始不适应，觉得被追问得难受，后来发现这些追问几乎都能对应到某个真实发生过的故障。
故障复盘是他最看重的环节。他定的规矩是：复盘会不谈责任人，只谈时间线。从第一个异常日志出现，到监控告警触发，到值班同学介入，到最终恢复，每一分钟做了什么，全部还原出来。2023 年有一次缓存击穿导致的连锁故障，复盘会开了两个半小时，最终产出了七条改进项，其中五条在两周内落地。剩下的两条涉及跨部门协作，他主动接了下来，跟基础设施团队一起推了三个月。
"故障是系统给我们的反馈，"他在复盘纪要里写过一句话，"你把它当成事故，它就只是一次损失；你把它当成输入，它才变成资产。"
带人：把踩过的坑变成团队的台阶
老张正式带过四个新人，非正式指导过的就数不清了。他带人的方式不太一样——不先讲规范，先给一个真实的小需求，让人自己动手，卡住了再来问。
去年入职的小周记得很清楚，自己接手的第一个任务是给订单查询接口加一个筛选项。写完提交后，老张没有直接评审代码，而是先问了一句："你觉得这个需求，产品经理真正想解决的是什么问题？"小周愣了半天。后来他们一起翻了客服的工单记录，发现真正的痛点是客户在批量查询时无法快速定位异常订单，而那个筛选项只是产品给出的一个实现思路。最终方案做了调整，改动量比原计划小了三分之一，效果反而更好。
这种"先问问题再改代码"的风格，慢慢影响了整个团队。现在订单组的评审会上，经常能听到类似的提问：这个需求背后的场景是什么？有没有更简单的实现路径？三个月后回看，这个设计还成立吗？
他也很少把功劳揽在自己身上。订单中心拆分项目拿了当年的技术团队奖，他在获奖感言里花了五分钟感谢测试、运维和产品，只用了两句话讲自己做了什么。团队里的人说，老张最不擅长的就是自我表达，但只要是他负责的系统，他比谁都清楚每一个细节。
工作之外的老张
不加班的时候，老张六点半准时离开工位。他住得离公司不远，骑车二十分钟。家里有个上小学的女儿，周末的固定安排是陪她去图书馆。他的工位上摆着一张照片，是女儿画的"爸爸在工作"，画里的电脑屏幕上全是歪歪扭扭的方块，他说那是代码。
他喜欢下围棋，业余三段，公司的棋社里没有对手。有同事问他下棋和写代码有什么关系，他想了想说，都讲究一个"势"——不是每一步都追求最优，而是让整盘棋处在自己可控的节奏里。
他还是团队里最早开始写技术笔记的人，从 2019 年到现在，积累了将近两百篇，大部分是故障分析和方案取舍的记录。这些笔记没有发到公开平台，只在内部共享。有同事建议他整理出书，他摆手说："等我把手上的系统再打磨两年，现在写出来，怕误导人。"
写在最后
采访快结束时，我们问老张，写了八年代码，有没有想过转管理。他想了想说，想过，但暂时没走那条路。"我可能更适合把一个系统从混乱带到有序，这个过程挺有意思的。"
他停顿了一下，又补了一句："而且现在的系统，还远没到有序的程度。"
这就是老张。在团队里，他不是一个特别显眼的人，发言不多，朋友圈也很少更新。但当线上出现问题的时候，当方案讨论陷入僵局的时候，当新人不知道从哪下手的时候，大家第一个想到的往往是他。
八年时间，代码写了几十万行，系统改过几轮架构，技术热点换了一茬又一茬。他始终在做同一件事：让每一行代码，都能经得起时间的检验。
这大概就是一名后端工程师，最朴素也最难得的职业底色。
