别再给我发大量的 PR；咆哮

我累了老板。我厌倦了审查一、二、三千行的 PR，因为某些代理能够“一次性解决整个问题”。从来没有要求过小型 PR，因为它们更容易编写，这始终是为了审稿人的利益。人工智能给这个行业带来了巨大的福音，但它也成为了审阅者和维护者的负担。也许我只是一个对着云大喊大叫的老人，但是请不要再给我发巨大的 PR。我最近多次听到这样的论点：“如果没有整个更改，它就无法工作”或“如果我们不放入整个差异，代码将不会执行任何操作”，好吧，是吗？好的？小型 PR 的目的并不一定是拥有小型、个性化的成品。就是要有小的、易消化的、可审阅的、易理解的作品。我没有这方面的数据，所以我会疯狂地推测，完全理解一段代码所需的时间随着代码覆盖的行数呈指数增长。因为你想要发布完整的功能而占用我的时间成倍增加，但这并不能激发我的快乐。当我们这样做时，我不需要 50 行注释。当然，文档功能，给我 jsdoc、rustdoc、javadoc，所有这些好东西。绝对不要给我 5 行注释来解释为什么变量被命名为 is_logged_in 。如果你的变量命名得好，十有八九我都会明白它的作用。如果您的变量命名不好并且您需要注释，请更好地命名您的变量。最后，对于那些说“只需使用人工智能来理解（而不是理解）它兄弟”的人工智能极端主义者来说，你正在浪费你的代币来重新摄取人工智能已经制作的代码。 “不过，我使用不同的模型进行评论，”好吧，太好了，那你为什么要把它放在人工评论中呢？也许，你可以让你宝贵的人工智能为我们这些凡人分离它，然后在轮到我们之后再审查它？你看，AI 是一个很棒的工具，它确实可以帮助事情进展得更快，并且可以使代码变得更好，但是当 React 出现时，我们并没有接受更大的 PR，因为“React 编写起来更快，更容易阅读”，那么我们为什么现在这样做呢？附录：你只是做了巨大的 PR，所以我中途放弃并批准它吗？如果是的话，打得好。出色地。玩过。