当前位置:当前位置:首页 >综合 >“仅1行代码,我们改了6天!” 正文

“仅1行代码,我们改了6天!”

[综合] 时间:2024-04-26 15:57:24 来源:蓝影头条 作者:探索 点击:196次
编译 | 郑丽媛

出品 | CSDN(ID:CSDNnews)

“这是仅行一个真实的故事。”

是代码的,你没看错,仅行“花 6 天时间,代码改 1 行代码”这件事是仅行真实发生的——甚至改动的这行代码,也只变动了 1 个字节,代码即从“3”改为“4”。仅行

图片

01 总裁:要么裁员,要么提效

Philip(总裁):我发现我们的仅行工厂利用率低了 10%,既然如此,代码要么我们开始生产更多的仅行积压订单,要么就要进行裁员。代码我是仅行更希望能让每个人都保持忙碌,建立库存,代码在旺季之前提前做好准备。仅行你认为我们应该如何做到这一点呢?

Lee(运营经理):公司政策限制我们的积压订单不能超过 3 个月,如果你要把期限改成 4 个月,我们就有很多工作要做了。

Philip:好的,那现在我们该如何落实呢?

Lee:我不太确定,不过我认为我们得在旧软件中更改一个设置。

David(IT 总监):没问题,这应该只要改变核心程序中的一行代码。填写一张工单,提交给 IT 服务部门就行了。

Judy(IT 管理员):我为这个请求分配了工单号码 129281,但目前还需要填写关于业务影响的部分,并获得总监的批准。

David:这是 Philip 要求的,如果我们不立即处理,就不得不进行裁员了。

Judy:好的,那我自己填写这一部分,并将这个工单优先处理。

02 2 天后

David:129281 的情况如何?

Judy:它是开发队列中的第一个增强功能,排在 14 个错误报告之后。

David:别管什么队列了,把它标记成紧急,然后立即发送给 Ed。

03 1 个小时后

Ed(程序员):在模块 ORP572 的第1252行,我将硬编码变量 MonthsOfBacklog 从“3”改为“4”。我成功进行了单元测试,并运行了两次批量处理测试,预计运营工作队列会增加 10%。这个修改已经就绪了,我刚刚提交了代码审查,并转入 Homer 进行用户验收测试。

Shirley(代码审查):目前的公司政策禁止使用任何硬编码变量,你必须在参数文件中对此进行记录。此外,还有两个旧的调试命令,一个未分配变量的警告消息和一个硬编码的员工 ID,所有这些都必须在该模块进入生产之前进行修复。

Ed:啧,麻烦。

Shirley:了解,但规定就是这样。既然你被指派处理 ORP572,你就必须修改违反公司新政策的现有错误,我不能就这样让你的修改通过审查。

04 2 小时后

Ed:好的,完成了。我刚刚重新提交了代码审查。

Julie(IT 测试):Homer 目前不能用于用户验收测试,因为 Fred 正在进行月末会计结账的受控测试,你可以用 Marge 代替。

Ed:我没有 Marge 的访问权限。

Julie:那就联系 IT 安全部门的 Joe,他会给你开权限的。

05 2 小时后

Joe(IT 安全):如果没有 David 的签字,我没法给你开 Marge 的访问权限,不过他现在出差了,要不你等到周一?

Ed:不行,Philip 要求立即处理,找他去批准开权限吧。

Shirley:你的新参数记录“MoonsOfDemand”得改个名字,因为海外程序员可能看不懂这是什么意思。另外,它还应该有变更的审计记录。

Ed:哈?哪条规定这么说了?

Shirley:目前规定里确实没有明确说明,海外团队晚了 3 个月才更新 wiki,但我向你保证,所有的新参数记录都必须满足新的命名要求,并保留审计记录。

06 1 天后

Ed:我把参数记录“MonthsOfDemand”改名为“SelectedMonthsOfBacklogDemand”,还添加了模块 PAR634 来维护该记录及其审计记录,并已将其提交给代码审查。

Tony(IT 测试):我在 Marge 上看到了 129281,但我没有测试计划。

Ed:就用老方法和新方法运行,注意工单工时报告中的总数增加即可。

Tony:这就是你的测试计划?不行,这会影响工厂中的一切。我必须有用户选择的测试用例、预期结果、记录的测试运行,并获得用户的确认。

07 2 天后

Philip:David,告诉 Tony 立即将 Ed 的程序移入生产环境。

David:好的,老板。

综上:

总耗时:6 天。

更改的关键代码行数:1 行。

更改的关键代码字节数:1 个字节。

吃下的头痛止痛药:24 颗。

在 Hacker News 上愤怒的时间:14 个小时。

08 程序员上线作证:“这种事绝对是真的”

也就是说,仅修改 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

(责任编辑:知识)

    相关内容
    精彩推荐
    热门点击
    友情链接