如何逐步引入代码审查？

我带领一个由六个高级工程师组成的团队。我非常相信，出于所有标准原因，进行代码审查将对我们大有裨益。不一定每次更改，但至少要有稳定的背景审查。因此人们至少会看到别人的变化并开始谈论它们。

有什么好的方法来介绍评论吗？我感到团队很不情愿，因为这是另一回事，而且谈话可能会很痛苦。我觉得复习每一个变化都是起步，至少作为第一步。我希望人们在增加数量之前先进入节奏和练习以较低的频率进行评论。

有人成功地逐步引入了代码审查吗？怎么样？我已经要求对“热门”文件或库进行审查。或随机采摘。或者我选择“选择”必须审查的更改。还是冒险尝试并进行所有更改是唯一的方法？

这不是工具或过程的问题。这与文化有关。您描述了一个由批评和保护自己的工作的人组成的团队。这是非常非常普遍的。但这不是专业的。

我的建议是开始以身作则。提供您的提交以供审核。公开要求别人强调您的方法中的问题。接受反馈。不要防御，而要探究反馈背后的原因并就团队行动达成一致。鼓励开放的对话气氛。在您的团队中找到一两个愿意这样做的冠军。

辛苦了

第一步是走到某个人面前说：“嘿，您会审查我的代码吗？”。成为您希望在组织中看到的变化。如果找不到一个愿意做的人，那么您将无法说服整个团队。如果你们两个都取得了成功，请向团队报告。

找到某人检查您的代码后，请问他们是否介意是否查看他们的某些代码。短语它作为一个学习的机会，你，而不是作为一个机会他们，以提高他们的代码。

作为团队负责人，我从代码审查过程中获得的最大价值是对正在发生的事情的意识。我希望有机会看到每一个变更集，即使我对开发人员没有任何变更或建议。我称这些为“意识评价”。我可以在30分钟内将它们转过来，因此没有瓶颈。

我建议您从这些开始。定义代码复审提交过程（如果使用TFS，这很容易完成），并让每个人都在签入之前向您（仅您）提交他们的变更集。告诉他们这仅是出于意识，没有人会批评他们的代码。

经过一两次迭代的意识检查后，开始邀请团队中的其他成员再次检查彼此的代码...，仅用于意识检查。信不信由你，仅此一项就有助于团队凝聚力和代码统一性。

一旦整个团队参与进来，您可能会发现您的开发人员无法抗拒就彼此的代码提出建议。这将自然而有机地发生（工程师们不能自力更生！），让团队开会讨论这一问题，并提出指导原则，以相互提供建设性反馈。然后将其设置为。恭喜，您现在处于完整代码审查模式！

有什么好的方法来介绍评论吗？

可能有几种好方法，具体取决于您的团队和希望从审核中获得的收益，但是任何一种方法都具有一些共同的特征：

• 解释您的期望：这是您团队的新流程，或者至少是对现有流程的更改，因此，公平的是让团队知道您为什么要进行更改，如何期望团队受益以及您如何知道它是否有效。

• 定义过程：引导人们完成您希望他们遵循的过程以检查代码，讨论更改等，以便团队中的每个人都知道如何进行。

• 定义标准：列出人们应该和不应该指出的需要改进的种类。例如，应该指出错误和显着的性能改进。应当注意编码标准，可读性和可维护性问题，但不能过多地提及；关于个人品味或风格的问题应该任其单独考虑。

• 讨论行为：指出目标是改善代码并增进共识，这将帮助团队全面编写更好的代码，而不是使任何人尴尬，结算分数等。批评应该是客观和建设性的，永远不要个人。制定一些基本规则可能有助于减轻有关审查代码的疑虑。

• 首先让您成为热门话题：无论您打算进行个人评论还是小组评论，将头几个小组作为一个小组进行讨论都是一个好主意。第一次审阅应该是您自己的代码，以便其他团队成员可以看到该过程还不错，并且您愿意亲自进行。

首先举行启动会议，以解释以上所有内容并解决团队成员的疑虑。跟进记录该过程的电子邮件。

我感到团队很不情愿，因为这是另一回事，而且谈话可能会很痛苦。

这是两个不同的问题。如果您认为审核会有所帮助，那么您需要在时间表中花一些时间来进行审核。确保团队成员了解复查是与其他任务一样的工作，而不是他们在继续以相同速度继续完成其他任务时要做的其他事情。

小组审查会议应由主持人主持，主持人应保持讨论的进行，限制会议时间并保持建设性。这对于避免痛苦的谈话应该有很大帮助。到您准备开始个人审核时，团队有望采用一些行为，以帮助他们保持自己的建设性。

您还应该不时审查审查过程。经常召集团队一起讨论该过程：它的工作状况如何，如何进行改进，应该放弃哪些实践等。赋予团队所有权，并拥有尝试新事物的自由。

一种方法是在每次冲刺之后进行代码审查会议，并检查每个人的更改，将代码投影到某种大屏幕上，以便团队中的每个人都可以参与。任何改进都可以作为技术债务添加到积压中。

这种方法有效，但是并不完美。

最终目标是使用拉取请求将代码合并回master或开发分支，在该分支中，必须回顾每一行代码。