用于单个产品的多个团队的代码评审模式

Question

我们正在将单个产品的开发从一个团队扩展到多个团队。有哪些模式可以确保编码风格、模式和技术得到一致的使用？

有没有一个人除了评论什么都不做.是否应该有更多的人参与审查？是否应该更早进行审查？

我们目前的scrum团队规模是6个人，有2-3个开发人员和1-2个测试人员。拉请求需要一个开发人员和一个测试人员的批准.这通常发生在系统/集成测试之后。

我在网上搜索过，但找不到任何指导。

Answer 1

有哪些模式可以确保编码风格、模式和技术得到一致的使用？

自动化。对于大多数流行的语言，有优秀的自动格式化器和指针，以确保一致性和惯用风格。每一次CI运行时，指针都应该运行每个可链接文件。

这类中任何不能自动检查的重要内容都应记录在案。我发现一个由可验证语句组成的简单合并请求清单对于收集我们现在所做的事情非常有用。它应该包含关于应该如何完成事情的容易验证的陈述(而不是如何完成它们；它是项目文档，而不是编程指南)，最好有一个基本原理和示例。这样，当您最终不可避免地发现一种更好的做事方式时，您可以简单地更新这个文档。一个额外的好处是，如果文档是存储库的一部分，更改将由另一个团队成员评审，因此它被证实是一个好主意和可读性。从稀薄的空气中抽出的例子可能是这样的：

• 权限类继承自定义BasePermission类。理由: Frobnicator库BasePermission类是不安全的，因为它不安全，但是他们拒绝修复它，因为它会破坏太多的链接到发布。示例：from dwim.permissions import BasePermission …

有没有一个人除了评论什么都不做.是否应该有更多的人参与审查？

您绝对应该确保参与项目的所有开发人员都进行代码评审，包括初级开发人员：

• 领域知识至少与代码评审的“原始”编程知识一样重要，尤其是当您强制执行精练以避免所有那些双向的评审评论时。只阅读代码而不实现更改的人会得到域的一个非常不平衡的视图，因此他们的评论不会像他们可能的那样有用。
• 一个人，其唯一的工作是评论，很可能会尽快辞职，因为这将是职业自杀。没有作为代码审阅者的作业。
• 初级学生可能擅长发现过于复杂的解决方案，因为如果允许的话，他们可能会问“为什么”。
• 让初中生也训练他们进行评审，并让他们感觉自己是团队的一员，而不仅仅是实现一些事情和接受反馈。

是否应该更早进行审查？

比什么早？一旦作者认为变更已经准备好合并，就应该立即进行评审。如果更早的话，您就会大量增加风险和浪费(从敏捷的角度来说，这是无法到达的代码)，在评审完成时，作者就会失去上下文。