我遇到了一份文件，其中包含有关公司内部代码审查流程的规则和建议。 我决定将此类有用的信息与外界共享。 在
作者的祝福下
，我出版了这本书。
这些规则大多数都是建议性的，应首先以常识为指导，而不应盲目遵守。
一般规定
- 在hh.ru中，审核以Github上的请求请求格式进行。
- 即使在任务框架内更改了代码中的一行或一个字符，也需要审阅和提取请求。
- 每个任务必须至少有一个负责的审阅者，该任务在任务中指示为审阅者，并对代码负责，就像作者一样。 不禁止和鼓励参加他人的审查。
- 通过审阅执行任务的责任在于任务的作者。
- 审核后的任何更改（例如测试期间的修订）也应预览。
审查目标
- 在开发人员之间传播经验和知识。
- 支持该原则-更改不应使现有代码恶化，而应对其进行改进。
- 纠正逻辑错误和与安全性相关的错误，正确处理异常。
- 提高代码质量，可维护性和项目体系结构。
- 提高代码的可读性。
- 在适当的水平上提高测试范围和测试。
- 改善文档。
- 变更是否符合任务要求。
- 防止技术债务或技术税。
- API的周到设计，其中API是具有外部接口的任何模块。 例如，服务中的资源具有经过深思熟虑的URL，便捷的JSON格式，在不同情况下的正确响应代码等等。
- Gita中正确的提交历史，带有反映消息本质的消息，没有临时提交。
准备审核
- 在发布拉取请求之前，请阅读2-3次代码：很有可能您自己会在那里发现错误，这将为审阅者节省时间。 检查是否没有可以自动检测到的错误-代码样式的错误，已删除的测试。 确保该代码没有临时注释和调试代码，并检查您的代码是否与可接受的样式指南匹配。
- 如果您在处理任务的过程中创建拉取请求，请在标题中写上“ [WIP]”并标记“正在进行中”。 工作完成后，请删除标签并在单独的注释中提供有关信息，以便有关各方知道可以查看该代码。
- 准备向审阅者显示任务的迷你演示。
- 给出一小部分代码以供审查。 200-300行更改-有效审核的上限。
- 在单独的提交中进行独立更改。
- 用简短而翔实的消息描述提交。
- 如果将重构作为单独的提交进行，则更容易看到逻辑上的更改（任务的本质）。
- 在重大更改之前，将代码格式化为单独的提交，甚至格式化为单独的请求。
- 不要进行较小的更改。 例如，在文件中添加换行符，而您未对其进行任何更改。
- 在拉取请求的标题中，简要且内容丰富地描述更改的本质。
- 在拉取请求中描述问题和解决方案。 描述替代解决方案以及为什么选择当前解决方案。 如果更改与界面有关，请在“之前”和“之后”附加屏幕截图。
- 在拉取请求中，提供指向任务的链接，在任务中提供至拉取请求的链接。
- 有时在编写代码之前与审阅者讨论所选的解决方案很有用。 这将有助于找到问题的最佳解决方案，并简化审核过程。
审稿人选择
- 将审查任务交给相关领域的专家。
- 如果几个命令使用某个代码，则从另一个团队中选择一个审阅者以传播知识将很有用。
- 缓刑官可能不是负责的审阅者，但可以参与审阅过程。
- 不要将所有任务都交给同一个人-要求其他人发表评论。
- 如果问题涉及某个人可以理解的非平凡的代码段，请向他显示所做的更改，而不管负责人是谁。 还请记住，每个存储库都有维护者，他们对此代码有更多了解并负责开发。
- 其余的审阅者是在双方共同同意下任意选择的。 根据受影响代码的“怪”使用github上的建议来帮助您选择。
- 选择审阅者后，在拉取请求中将其指定为受让人 。 分配给您的所有拉取请求的列表 。
审核流程，一般
指代代码的作者和审阅者。
- 所有代码都是通用的，没有“我的代码”或“您的代码”之类的概念。 这意味着每个开发人员应对任何一行代码负责，而不仅仅是编写这一行的代码。
- 营造相互理解的气氛，礼貌友好，珍惜彼此尊重，不要强加您的意见。 听对手的意见，不要站在原则上。 不要将评论变成对同事的负面体验。
- 如有疑问，请提问。 争论并指定问题和答案。 对于代码的编写者来说，“为什么这样？”的含义可能并不明显，但是审阅者并不理解答案为“不同意”的说法。
- 不要拉长审阅过程，节省时间，快速回应评论，口头讨论，不要引起冗长的讨论并且不要滋生“手段”。 如果您不能迅速达成共识，请向您的同事，维护人员或职能部门的经理寻求帮助。
- 如果任务不在两行之间，请与审阅者一起进行10-15分钟的联合代码审阅，即使在创建拉取请求之前执行此操作也很有用。 讨论任务和解决方案的本质，看看它在工作环境中如何发展。 这将有助于审阅者更好地深入研究任务的上下文。 大多数评论将保持不变，这将节省每个人的时间。
- 经过口头讨论后，请务必在请求请求中描述所做出的决定及其原因。 描述的责任在于代码的作者。
- 如果代码中包含相同类型的错误，那么审阅者应在第一或第二条注释中关注代码作者的注意力，而不是对每个条目进行评论，并且作者应在发布更正之前分析代码中的同一类型的错误。
- 感谢作者的成功决定和审稿人的建议。
- 对拉取请求本身中的更改（而不是单个提交）发表评论。 因此，所有信件都将放在一个地方，包括在重新设置基准之后。
- 在开始讨论的同一讨论线程中回应评论。 如果注释引用了整个请求请求或同一线程中的多个注释，请引用注释后的注释。 为了从电子邮件切换到过时的讨论线程，请使用“ in path / to / file”链接，而不是“在GitHub上查看”链接。
- 如果在审核过程中从编码标准或其他正式协议的角度做出了任何主要决定，则代码作者有义务在相关文档中写下这些决定。
- 审查不仅涉及代码，而且涉及整个任务。 不要将任务或布局中的要求视为最终真理-每个人都会犯错，而且没人可以考虑所有细微差别。 焕然一新和明智的建议只会使产品受益。
代码作者的审核过程
- 直到通过“产品”上的审查，测试和发布，该任务才完成。
- 回应审阅者的所有评论，无论您是否接受，都不要让评论无解。
- 考虑一下审阅过程中出现或可能出现的问题。 也许代码部分缺少注释，或者最好是更明确地编写代码。
- 不要使用gend commit --amend更正现有的提交；而是将更改作为单独的提交进行更改，每个修订一次。 更正现有提交会极大地增加审阅过程，因为您必须再次查看所有代码。
- 向拉取请求添加新的提交后，在单独的注释中编写更改摘要，以便有兴趣的各方知道。 这适用于审阅期间的更正以及测试期间的更正。
- 审核之后，在发送测试任务之前，请重写提交历史记录（git rebase --interactive），对各个提交进行更正并删除临时提交。 签出--autosquash选项以简化该过程。
审阅者的审阅过程
- 如果您在请求复审时很忙，请告诉我您何时开始复审。
- 不要要求，但建议进行更改。
- 评论代码，而不是编写代码的人。
- 您对书面代码负责，并据此进行审查，但这并不意味着代码作者必须严格遵守您的所有要求。 请记住，许多事情可以用不同的方式完成。
- 遵循审查的目标并提出实质性修改建议。 不要坚持非关键性的改变。 在评论中指出更正的重要性。
- 如果发现严重问题，请暂停审阅并等待作者修复它。 更可能的是，在更正之后，仍然有必要再次进行修改。
- 不仅要注意已更改的内容，还要注意未更改的内容。 查找并向作者显示应更改但未更改的代码（被遗忘的导入或未使用的类，在其他地方使用重构的代码，等等）。
- 在代码作者进行更改之后，请检查更正并再次查看整个请求请求。 也许，如果有更正，您将有新的评论或问题。
- 不要浪费时间检查尚未更改的代码，因为该代码是任务的一部分。 将部分代码分配到函数中被视为更改。 “按原样”进行代码传输不视为更改。 作者可以自行决定是否修改受影响文件中的代码。
- 审阅者并没有独立地编辑分支中的代码，因为他希望如此或那样容易。 更改由代码作者进行。
- 如果进行了修订，请不要拖延或切换到其他任务，以免影响当前
二手资料及相关链接
PS在评论中分享您在审查过程中的规则，建议和有用的用户案例