软件代码审查流程是一种系统性的、由同行驱动的质量保证程序,当开发者提交拉取请求或合并请求时会对代码进行审查。
虽然糟糕的代码审查流程因其不可避免的延误以及人们可能因无关紧要的细节而制造瓶颈而受到诟病,但良好的代码审查能及早捕获 Bug、促进导师关系,并被视为分担责任的民主方式。
这就是全部,但事实并非如此。
高级软件工程师 Mark Dominus 告诉 The New Stack,尽管许多公司确实会执行代码审查,但他们并没有“明确说明审查的结果应该是什么”,这是一个问题。
“假设你是一名初级工程师,第一次被告知要做代码审查。你的交付物是什么?在我工作过的许多地方,交付物都没有被明确规定,”Dominus 说。
在关于这个主题的 Mastodon 帖子中,Dominus 写道:“任何依赖代码审查来发现 Bug 的人都生活在愚人的天堂里”,主要是因为“通常不可能”通过检查代码来发现 Bug。他强调说,“代码审查的主要目的”是找出未来难以维护的代码。
通往代码审查不良结果的必经之路
他认为,在软件工程师被要求悠闲地浏览 变更集 并指出他们不喜欢的地方的场景中,会导致不良结果,即鼓励人们试图强制执行自己对事情应如何完成的偏好,从而引发争论。
“仅通过检查变更集来发现 Bug 极其困难,需要一定的运气。” – Mark Dominus。
“有时候老板会给初级工程师多一点指导,比如:‘看看能不能发现任何 Bug’,这会把初级工程师置于一个不愉快的境地,”Dominus 澄清道。“也许他们确实发现了一个 Bug,太好了!但如果他们没有呢?仅通过检查变更集来发现 Bug 极其困难,需要一定的运气。”
他建议采用不同的方法,由软件团队的项目负责人推动代码审查流程:“花两个小时查看这个,写下任何你不理解的地方,如果你没有全部看完,就在停止的地方做个记录。”
交付真正软件工程价值的途径
“现在,如果审查者没有时间查看所有内容,你就学到了有价值的东西:变更太大或太复杂,无法在两个小时内理解。也许变更集应该分成两个或更多较小的提交,分别进行审查。无论审查者多么初级、缺乏经验或宿醉未醒,他们都能交付被要求的内容,而他们交付的内容将具有真正的工程价值,”Dominus 解释道。
这种真正的工程价值在这种情况下是一种积极的否定。团队现在已经识别出其他团队成员无法理解的代码,或者变更集对于当前的代码审查流程来说过于笨重……或者两者兼而有之。
代码审查是戏剧,即将在你附近上演
Mikhail Golikov(一家高负载电子商务平台公司的 QA 工程师)大致同意这些观点,他告诉 The New Stack:如果一个团队依靠代码审查来捕获 Bug,那么“代码审查就是戏剧”。
“当一个团队将审查视为其 Bug 过滤器时,它带着温暖的感觉发布而没有任何证据,然后在生产环境中发现问题。” – Mikhail Golikov。
“人类浏览 diff 无法看到竞争条件或在负载下变为负数的折扣。审查是针对你日后会讨厌维护的代码;测试是针对现在已损坏的代码,”Golikov 强调道。“审查者阅读一个干净的 diff,看到合理的命名和整洁的函数,然后点击批准。所有这些都无法告诉你应用的关键部分出现故障并向用户提供损坏的服务。”
Golikov 也是开源 Python 测试工具的维护者,他解释说,导致这些错误的 Bug 并不存在于开发者可以阅读的代码中,而是存在于代码在运行时所处的状态中。
不要带着温暖的感觉发布而没有任何证据
“当一个团队将审查视为其 Bug 过滤器时,它带着温暖的感觉发布而没有任何证据,然后在生产环境中发现问题,”Golikov 证实道。“审查针对的问题是‘六个月后我会讨厌维护这个吗’,而‘它是否真的有效’则需要在针对真实输入运行测试时回答,而不是让一个人在下午 5 点浏览拉取请求。”
开发者和供应商几乎一致认为,代码审查流程需要改变,尤其是在 AI 时代,代理式编码工具日益普及。
Judah Taub(Hetz Ventures 的管理合伙人)同意这一观点,他告诉 The New Stack,多年来工程团队一直将代码审查视为抵御 Bug 的最后防线,但这从来不是它的强项。
“工程师的角色正在进一步远离实际代码,转向验证架构、意图和业务逻辑。未来,即使这一点也可能被自动化。” – Judah Taub。
“代码审查捕获风格、架构、可读性和可维护性,”Taub 说。“测试捕获 Bug。生产捕获其他一切。最好的工程组织不依赖另一个开发者在数百行代码中发现一个微妙的边缘情况——他们构建系统,在拉取请求到达另一个人之前就自动验证正确性。代码审查是为了确保下一位工程师可以无缝地处理代码。”
代码审查的未来
随着 AI 生成的代码 加入战局,Taub 认为不可避免的新平衡将是人类直接审查更少的代码,而是越来越多地审查 AI 对代码的审查。
“工程师的角色正在进一步远离实际代码,转向验证架构、意图和业务逻辑。未来,即使这一点也可能被自动化,”他预测道。
我们可以从中提取关键趋势,即软件工程团队确实需要走出九十年代——如果他们目前还停留在那里的话。
云原生、平台工程以及从氛围编码到代理式编码的革命(你可以加上大数据、DevOps 以及向企业开源的标准化,如果你愿意的话)已经改变了软件开发者的工作方式,因此他们审查刚刚发生的事情的方式也应该有相应的改变。
技术发展迅速,不要错过任何一集。订阅我们的 YouTube 频道,观看我们所有的播客、访谈、演示等。
Group Created with Sketch.
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.