查看原文
其他

一个真实的故事:1 行代码,改了 6 天!

程序猿DD 2023-11-28

编译 | 郑丽媛、出品 | CSDN(ID:CSDNnews)

“这是一个真实的故事。”
是的,你没看错,“花 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,他会给你开权限的。

2 小时后

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 上也有不少程序员出面证实了这种情况的真实性:
▶ “这种事绝对是真的,大多数公司的代码审查过程都充满了吹毛求疵和琐碎的评论。”
▶ “讲个轶事:我在有正式代码审查的团队工作了几年后,跳槽到了没有代码审查的公司,也就是每个人都可以自由提交/合并到任何分支。在刚这个加入公司时,我感觉有些复杂,但很显然,这也让我感到非常新鲜并动力十足,所以在几天之后我就变得很有生产力。”
▶ “代码审查的出发点是好的,但有些把关人总以琐碎的理由拒绝一切。他们老说这样是为了保持“代码质量”,但最糟糕的事莫过于在错误修复完成之后,还保留着错误百出的代码,或者推迟功能的发布,以至于没有人能够试用。”
那么作为程序员的你,是否也对这类事情有所共鸣?欢迎在评论区留言分享你的经验。
相关链接:
https://edw519.posthaven.com/it-takes-6-days-to-change-1-line-of-code
https://news.ycombinator.com/item?id=36746014

------
我们创建了一个高质量的技术交流群,与优秀的人在一起,自己也会优秀起来,赶紧点击加群,享受一起成长的快乐。另外,如果你最近想跳槽的话,年前我花了2周时间收集了一波大厂面经,节后准备跳槽的可以点击这里领取

推荐阅读

··································

你好,我是程序猿DD,10年开发老司机、阿里云MVP、腾讯云TVP、出过书创过业、国企4年互联网6年。从普通开发到架构师、再到合伙人。一路过来,给我最深的感受就是一定要不断学习并关注前沿。只要你能坚持下来,多思考、少抱怨、勤动手,就很容易实现弯道超车!所以,不要问我现在干什么是否来得及。如果你看好一个事情,一定是坚持了才能看到希望,而不是看到希望才去坚持。相信我,只要坚持下来,你一定比现在更好!如果你还没什么方向,可以先关注我,这里会经常分享一些前沿资讯,帮你积累弯道超车的资本。

继续滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存