后端工程师 · 任务逐条

接口,以及它们之间的管子

规格清晰、训练数据里大量存在、跑一下就能验证 —— 让任何任务成为生成强项的正是这三个性质。它同时也是「从外面看后端工作」时看到的大部分内容。

生成一个接口,和「决定它该不该存在、它必须保证什么、被调用两次会怎样」是两回事。在这份工作里,打字很少是贵的那一部分。

在事情同时发生时保持正确

这类 bug 不会在测试里出现,常常几个月都不出现。要推理它们,需要在脑子里装着「同时还有什么在跑」和「一次部分失败会留下什么」,而正确答案取决于这门生意做过什么承诺,不取决于你眼前这段代码。

这是一条关于工作性质的判断,不是量出来的。几乎没有人会公开把事故归因于「生成的并发代码」,而这种沉默不能证明它没发生 —— 任何公司里,一份把原因写得这么具体的事故复盘都很罕见。

数据模型,以及在它被使用时改它

早期的表结构决定会在几年后变得很贵,而这种代价的位置任何工具从当前代码里都看不出来 —— 因为它长在「已经写进数据里的东西」里。一次迁移在实践中也是不可逆的,这把它放进了「必须有人担责」而不是「有人辅助」的那一类。

它没有说工具现在多频繁地起草迁移脚本 —— 那是家常便饭。这条判断说的是谁来决定、谁来答复,不是谁来打字。

谁有权看到什么

生成是朝着「被描述出来的那个请求」优化的,而一个鉴权漏洞恰恰是没有人描述过的那种情况。这也是「自信、看起来合理、但是错的」答案最危险的领域 —— 在有人利用它之前,它和正确答案长得一模一样。

这里建立在问题本身的结构上,而不是建立在一次测量上;能把它定下来的,是一份把同一个代码库里「生成的代码」与「手写的代码」分开统计缺陷的研究。受监管环境本来就要求这一步有人签字 —— 起作用的可能是那条要求,而不是难度本身。

它花多少钱、有多快

工具在「揪出那条病态查询、建议加哪个索引」上确实很强。它们弱在取舍上 —— 花钱换更快是一个生意决定,而「哪个请求要紧」取决于你知道这个产品是干什么的。

这里没有任何东西测量了「实践中有多少已经由工具驱动」,而一个有可观测性预算的团队和一个没有的团队之间,答案差得极远。

被呼叫叫醒的那个人

诊断越来越多地被辅助,而那确实有用。但决定不是:为了恢复服务而选择接受一笔已知的损失,是一个有后果、必须有人承担的判断,而且它在设计上就是在信息不全时做出的。

它没有说值班负担是在变重还是变轻 —— 而那才是大多数工程师真正关心的问题,也正是没有人会公布的那个数。