工程师工作计划

周一早上八点四十，工程我打开Jira，师工发现上周五下班前还挂着“待验证”的作计十七个任务，现在只剩三个。工程剩下那十四个，师工全被测试打回了“重新打开”。作计原因出奇地一致：接口返回的工程字段名大小写不统一，前端那边直接炸了。师工

这不是作计第一次了。上个月做用户中心重构，工程后端同事把 `userName` 和 `username` 混着用，师工联调阶段多花了整整两天。作计你可能会说，工程加个校验规则不就行了？师工问题是，没人愿意在需求评审的作计时候提这个。大家都盯着功能点，字段命名这种“小事”，往往要等到代码跑起来才暴露。

我的工作计划里，有一条固定不变：每天上午九点到九点半，不写业务代码，只做三件事——翻一遍昨天的提交记录，看有没有命名不规范的地方；检查CI流水线里最近三次构建的警告日志；把当天要动的接口文档先过一遍。听起来琐碎，但过去半年，光靠这个习惯，团队少开了至少十次“紧急修复会”。

写计划这件事，很多人喜欢列一堆“学习新技术”“优化架构”。我试过，年底复盘的时候发现，那些条目基本没动。后来我换了个方式：计划只写这周要关掉的三个具体问题。比如这周是——统一所有用户相关接口的字段命名风格；把订单查询的慢SQL从1.2秒压到300毫秒以内；给支付回调加上幂等校验。每个问题都有明确的验收标准，不是“优化”，而是“从A变成B”。

上周三下午，我花了两个小时改一个分页查询。原来的代码用了 `OFFSET` 翻页，数据量到五十万行的时候，最后一页要等四秒。我换成基于游标的方案，用 `last_id` 做条件。改完测了一下，稳定在80毫秒。但有个坑：前端传参得跟着改。我直接在接口文档里把旧参数标了删除线，旁边写了新示例。第二天前端同事看到，在群里回了个“收到”，没多问一句。这种默契，比写十页设计文档都管用。

还有一件事让我挺在意的。上个月招了个应届生，他每天下班前会发一封邮件，列清楚今天做了什么、明天打算做什么、卡在哪里。格式很简单，三行。我问他为什么这么做，他说在学校做项目时养成的习惯，怕自己忘。我带过的新人里，他是第一个主动这么干的。后来我把这个做法加进了团队的工作计划模板里——不是强制，但推荐。结果两周后，连隔壁组的老张也开始发了。

计划赶不上变化，这话没错。但我的经验是，变化吃掉的是那些模糊的、没有边界的任务。如果你把“提升系统稳定性”拆成“给所有对外接口加上超时和重试”，那变化再大，这一条该做还是得做。区别只在于，你是周三做还是周五做。

今天下午两点有个会，讨论下个季度的技术债偿还。我准备提一个具体数字：上个季度因为字段命名和参数校验问题，累计浪费了三十七个小时的联调时间。折算成人力成本，差不多是一个中级工程师一周的工作量。我不想讲大道理，就把这个数拍在桌上。大家看着办。

下班前，我会把明天要改的三个接口的字段名先列出来，贴在工位上。明早来了直接动手，不给自己犹豫的机会。计划这东西，写得太漂亮没用，能让你第二天坐下来就知道第一行代码敲什么，才算数。