也许您阅读了审稿人关于审稿代码的文章的第一部分 （顺便说一句，我们已经设法在上一期Zinc Prod播客中进行了讨论）。
由于文章获得了很多喜欢，因此我写了关于代码审查的承诺续篇-来自代码更改的作者
像往常一样，我们将说MR（合并请求）而不是CL，因为很少有人会理解CL一词。
可以在这里找到根据Google为MR的作者提供的原始说明，我将进行简要介绍。
所以走吧
MR的描述
在Google，更改的描述存储在版本控制系统的历史记录中，将来很可能会有很多人阅读它。 因此，MR的描述非常重要。
第一行（标题中）应包含一个短语，描述MR中的操作。 此外，根据传统，使用命令式（命令式）样式，即 删除blablabla ，不删除blablabla
描述本身应该是内容丰富的，包含要解决的问题的简短描述，必要文档的链接（如有必要），任务跟踪器任务和其他上下文。 即使在小MR中，也应该如此。
当然，对“修复错误”类型的描述不充分。
MR应该尽可能小
- 小先生可以快速检查
- 验证将更有意义
- 不太可能遗漏错误。
- 如果整个MR都被拒绝，那么就不会那么令人反感。 当完成许多工作时非常糟糕，然后事实证明所有这些都是根本没有必要的
- 更容易推动变革，减少冲突
- 获得高质量的代码更容易。
- 一次更改越多，必要时回滚代码就越困难
在极少数情况下，不可能减小MR的大小并将其破碎成碎片。 如果MR太大，审阅者有权拒绝MR
当然，没有硬性规定，哪个MR将被认为是大而小的。 100行代码是否很大？ 谁知道
- MR必须做一件事。 通常这不是全部功能，而是其中一部分
- 分别重构为单独的MR
先生应小但能自给自足
- 审稿人需要了解MR的所有内容都应该在该MR中
- 注入代码后，系统应正常运行。
- 如果添加了API方法，则应在同一MR中演示使用该方法的方法。 换句话说，MR不应太小，以至于很难理解它的使用方式以及它将导致什么后果。
- 用测试覆盖代码，并且测试应该在同一个MR中
不要心动
有时审阅者不是很礼貌，他们可能会为您的代码写一些不好的东西。 从他们的角度来看，这不是很专业，但是在这样的评论中通常仍然有一些道理，必须加以考虑。 不要太苛刻。 这只会加剧局势。
如果您不喜欢评论中的谈话内容，最好找到此人并亲自与他交谈，以说明不适合您的情况。
如果这样做没有帮助，Google建议与经理联系。
根据我的经验，我想补充一点，写一个不礼貌的评论的人经常并不能说明自己看起来有点激进。 文字掩盖了一半的情感。 例如，以开玩笑的语调以文字形式说的话似乎有些残酷。 因此，我完全同意Google-如有误解，请只当面交流！
解释代码
如果要求您解释代码中的要点，请考虑是否可以更正代码，以便无需解释即可理解。 因为如果一个人不了解，那么其他人可能就不了解。
对审稿人评论的回复
通常，当工作完成并发送到审阅代码时，从心理上很难接受这样的事实，即某些东西也必须修复。 因此，请不要以敌对的态度看待审阅者的评论，以为他也许是对的，结果代码会变得更好。
但是，如果审稿人仍然是错误的，请随时撰写相关评论，并提供论据和事实的答案。
结论
总的来说，据我从Google的文档中了解到，MR的作者必须尽一切努力使审阅者更加轻松。 以便审阅者理解为什么编写代码，如何编写代码，必须具有理解所必需的所有上下文等。
不可避免地，要以礼貌的专业形式达成共识，以解决分歧。
在下一期《锌销售》中，我们一定会讨论本文（以及更多内容），因此请务必订阅我们的播客 ，否则请跳过有趣的部分！