“这是一个真实的故事。”
是的，你没看错，“花 6 天时间，改 1 行代码”这件事是真实发生的——甚至改动的这行代码，也只变动了 1 个字节，即从“3”改为“4”。
Philip（总裁）：我发现我们的工厂利用率低了 10%，既然如此，要么我们开始生产更多的积压订单，要么就要进行裁员。我是更希望能让每个人都保持忙碌，建立库存，在旺季之前提前做好准备。你认为我们应该如何做到这一点呢？
Lee（运营经理）：公司政策限制我们的积压订单不能超过 3 个月，如果你要把期限改成 4 个月，我们就有很多工作要做了。
Philip：好的，那现在我们该如何落实呢？
Lee：我不太确定，不过我认为我们得在旧软件中更改一个设置。
David（IT 总监）：没问题，这应该只要改变核心程序中的一行代码。填写一张工单，提交给 IT 服务部门就行了。
Judy（IT 管理员）：我为这个请求分配了工单号码 129281，但目前还需要填写关于业务影响的部分，并获得总监的批准。
David：这是 Philip 要求的，如果我们不立即处理，就不得不进行裁员了。
Judy：好的，那我自己填写这一部分，并将这个工单优先处理。
2 天后David：129281 的情况如何？
Judy：它是开发队列中的第一个增强功能，排在 14 个错误报告之后。
David：别管什么队列了，把它标记成紧急，然后立即发送给 Ed。
1 个小时后
Ed（程序员）：在模块 ORP572 的第1252行，我将硬编码变量 MonthsOfBacklog 从“3”改为“4”。我成功进行了单元测试，并运行了两次批量处理测试，预计运营工作队列会增加 10%。这个修改已经就绪了，我刚刚提交了代码审查，并转入 Homer 进行用户验收测试。
Shirley（代码审查）：目前的公司政策禁止使用任何硬编码变量，你必须在参数文件中对此进行记录。此外，还有两个旧的调试命令，一个未分配变量的警告消息和一个硬编码的员工 ID，所有这些都必须在该模块进入生产之前进行修复。
Ed：啧，麻烦。
Shirley：了解，但规定就是这样。既然你被指派处理 ORP572，你就必须修改违反公司新政策的现有错误，我不能就这样让你的修改通过审查。
2 小时后Ed：好的，完成了。我刚刚重新提交了代码审查。
Julie（IT 测试）：Homer 目前不能用于用户验收测试，因为 Fred 正在进行月末会计结账的受控测试，你可以用 Marge 代替。
Ed：我没有 Marge 的访问权限。
Julie：那就联系 IT 安全部门的 Joe，他会给你开权限的。
Joe（IT 安全）：如果没有 David 的签字，我没法给你开 Marge 的访问权限，不过他现在出差了，要不你等到周一？
Ed：不行，Philip 要求立即处理，找他去批准开权限吧。
Shirley：你的新参数记录“MoonsOfDemand”得改个名字，因为海外程序员可能看不懂这是什么意思。另外，它还应该有变更的审计记录。
Ed：哈？哪条规定这么说了？
Shirley：目前规定里确实没有明确说明，海外团队晚了 3 个月才更新 wiki，但我向你保证，所有的新参数记录都必须满足新的命名要求，并保留审计记录。
1 天后Ed：我把参数记录“MonthsOfDemand”改名为“SelectedMonthsOfBacklogDemand”，还添加了模块 PAR634 来维护该记录及其审计记录，并已将其提交给代码审查。
Tony（IT 测试）：我在 Marge 上看到了 129281，但我没有测试计划。
Ed：就用老方法和新方法运行，注意工单工时报告中的总数增加即可。
Tony：这就是你的测试计划？不行，这会影响工厂中的一切。我必须有用户选择的测试用例、预期结果、记录的测试运行，并获得用户的确认。
2 天后Philip：David，告诉 Tony 立即将 Ed 的程序移入生产环境。
David：好的，老板。
综上：
总耗时：6 天。
更改的关键代码行数：1 行。
更改的关键代码字节数：1 个字节。
吃下的头痛止痛药：24 颗。
在 Hacker News 上愤怒的时间：14 个小时。
程序员上线作证：“这种事绝对是真的”也就是说，仅修改 1 行代码，甚至就只改动 1 个字节，这家工厂就花了 6 天时间——不要觉得荒谬，因为这个事件的开头就说了：这是一个“真实的故事”。
同时，Hacker News 上也有不少程序员出面证实了这种情况的真实性：
▶ “这种事绝对是真的，大多数公司的代码审查过程都充满了吹毛求疵和琐碎的评论。”
▶ “讲个轶事：我在有正式代码审查的团队工作了几年后，跳槽到了没有代码审查的公司，也就是每个人都可以自由提交/合并到任何分支。在刚这个加入公司时，我感觉有些复杂，但很显然，这也让我感到非常新鲜并动力十足，所以在几天之后我就变得很有生产力。”
▶ “代码审查的出发点是好的，但有些把关人总以琐碎的理由拒绝一切。他们老说这样是为了保持“代码质量”，但最糟糕的事莫过于在错误修复完成之后，还保留着错误百出的代码，或者推迟功能的发布，以至于没有人能够试用。”
那么作为程序员的你，是否也对这类事情有所共鸣？欢迎在评论区留言分享你的经验。
