别再发给我巨大的 PR 了;一点牢骚
Stop sending me huge PRs; a rant

原始链接: https://getsmall.xyz/post/cmstjfl9l000if70ljmpzr4va

作者对人工智能生成的庞大合并请求(PR)日益增多的趋势表示不满。他认为 PR 应该保持精简易读,以确保人类审查者能够真正理解并核实代码。虽然 AI 工具加快了开发速度,但它们也为维护者制造了瓶颈,因为维护者现在不得不解析成千上万行机器生成的代码。 作者驳斥了“功能无法拆分为更小提交”的借口,并强调 PR 是为了方便审查者,而不仅仅是为了交付成品功能。此外,他还批评了代码过度注释的趋势,指出描述性的变量命名优于冗长且不必要的注释。 最后,作者反对让审查者使用 AI 来“理解”庞大 PR 的建议。如果代码需要借助 AI 才能读懂,那么人类的审查过程就已被绕过或失效。作者的核心呼吁是,开发者应将可维护性和人类可读性置于 AI 输出速度之上,并警告称,将海量 PR 抛给审查者会造成不可持续且令人沮丧的工作流程。

最近 Hacker News 上的一篇名为“别再给我发巨大的合并请求 (PR)”的讨论,探讨了如何管理过大合并请求的策略。评论者们普遍认为,过大的规模会阻碍有效的代码审查,并建议通过技术手段进行强制限制。 建议的方法包括: * **自动化 CI 拒绝机制:** 通过实施 CI 检查,自动拒绝超过特定代码行数的 PR,并礼貌地要求将工作拆分为更小、易于管理的部分。 * **Git Hooks:** 使用客户端 git hooks,在开发者推送代码前提示其确认或拆分大型提交。 然而,讨论也指出了一个潜在的弊端:尽管规模限制鼓励了模块化,但它也可能导致一连串相互关联、互为依赖的 PR。由于缺乏整体背景,这些 PR 在单独查看时可能难以理解,依然不便审查。各方共识强调,在通过规模限制来强制提高代码质量,与确保整个代码库的逻辑完整性之间,始终存在着某种张力。
相关文章

原文

I'm tired boss. I'm tired of reviewing one, two, three thousand line PRs because some agent was able to "one shot the whole issue." Small PRs were never asked for because they're easier to write, it's always been for the benefit of the reviewer. AI is such a boon to the industry, but it's becoming such a liability for reviewers and maintainers. Maybe I'm just an old man yelling at the clouds, but please, stop sending me huge PRs.

I have heard on multiple occasions recently the argument that "it won't work without the whole change" or "the code will do nothing if we don't put in the entire diff," well, yeah? Good? The point of small PRs is not necessarily to have small, individual, finished products. It's to have small, digestable, reviewable, understandable pieces of work. I have no data for this, so I will wildly speculate, that the time it takes to fully comprehend a piece of code increases exponentially with the number of lines the code covers. Taking up exponentially more of my time because you wanted to ship a full feature does not spark joy.

While we're at it, I don't need 50 line comments. Sure, document functions, give me jsdoc, rustdoc, javadoc, all of that good stuff. Absolutely do not give me 5 lines of comments on why a variable is named is_logged_in. If your variable is named well, 9 times out of 10 I'll understand what it does. If your variable is not named well and you need a comment, name your variable better.

Finally, for you AI maximalists that say "just use AI to grok (not grok) it bro," you're wasting your tokens reingesting code that was already made by an AI. "I use a different model for reviews though," okay, great, why did you put it up for a human review at all then? Perhaps, you could have your precious AI separate it for us mere mortals and then review it after we've had our turn?

Look -- AI is a great tool, it really helps things move faster and can make code better, but when React came out we didn't accept larger PRs because "React is faster to write and easier to read," so why are we doing it now?

Addendum: are you just making giant PRs so I give up halfway through and approve it? If so, well played. Well. Played.

联系我们 contact @ memedata.com