在代码审查中，积极反馈的重要性如何？

重要的是在代码审查期间指出代码的好部分以及它为什么好？积极的反馈对于正在审核的开发人员以及参与审核的其他人员可能同样有用。

我们正在使用在线工具进行评论，因此开发人员可以在给定的时间段（例如1周）内打开其已提交代码的评论，其他人可以评论其代码。其他人可以评论该代码或其他评论者的评论。

正反馈和负反馈之间是否应该保持平衡？

使用对等代码评论提高质量和士气
http://www.slideshare.net/SmartBear_Software/improve-quality-and-morale-using-peer-code-reviews

每个人都应该做的事情：代码审查
http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/

这两篇文章都指出，代码审查的目的之一是分享有关良好开发技术的知识，而不仅仅是发现错误。

所以我想说这很重要。谁想参加会议而只受到批评？

当我进行代码审阅时，我倾向于只运行一段独白，因此，当我理解自己正在阅读的内容时，会出现很多“好的，我明白了。”好吧，它可以与此相关并调用那好吧..这取决于这两个问题。”

我认为用这种方式并不是“太棒了！”，这可能完全是琐碎的乏味代码，但是听到其他人实际上进行了解析并显示出对您所写内容的理解，这本身就是一种积极反馈，反馈为“该代码有意义”，当我遇到不理解的部分时，我要求解释，当我理解时，则称“啊，我明白了”。

我认为，简单的理解力之所以受到另一位工程师的称赞，是因为我们都希望他人理解我们的代码，它提供了一种隐式验证的形式。

就是说，如果您看到代码的某些部分具有良好或积极的特征（即使是无聊的琐碎代码，如果它本身是最小形式的话，也可能是好的），我肯定会陈述这些特征，我也不会将它们归因于“哇！大！” 就像“我认为这是一个最小的实现”或“好，这个复杂的算法有很多注释”一样，关注代码的属性而不是固有的优缺点。

任何时候在代码审查中将“好”或“坏”归因于代码，以避免使工程师感到被别人看不起或抱在基座上时，不要说某事是好是坏，而是说出原因或结果。他们的代码。

“好吧，这部分很有意义，啊，这里有一个魔术数字，下一位工程师接触它时可能无法很好地理解该值的含义”

“我看到您在这里有一个DI容器，所以您将与该存储库松散耦合”

“啊，这里有一个静态字典，如果有多个线程接触该字典，我们可能会遇到某些竞争情况”

请注意，我并不是在说什么是好是坏，但是正在审查其代码的工程师将理解工程师是否应该更改它。显然，您必须以yy或nay结束代码审阅，但是在整个过程中累积这些语句会减轻对nay的影响，因为当您告诉他们“我想签入之前修复的那些魔术数字”。

如果我在代码审查中看到了我真正喜欢的东西，并且超出了“足够好”的代码，那么我会给出积极的反馈。

总的来说，我认为如果有人写了一段使您说“哇，这真是太好了！”的代码。然后，是的，积极的反馈很重要-它使作者知道他们的所作所为受到他人的喜欢，因此他们应该再次尝试这样做。但是，不仅要遵循准则和标准实践。给予赞美是因为某人很好地缩进或添加了样板注释可能会降低标准。

这不是编程问题，而是一般管理和人机交互问题。代码审查中的正面反馈与任何形式的审查中的正面反馈一样重要。

是否要求（以及要求的程度）取决于您正在交谈的人的性格和情绪构成。加上赞美，有些人对纠正的反应会更有效。其他人认为纠正后的表扬是不真诚的。

一般的公式有时被称为“反馈三明治”：好东西第一，坏东西第二，好东西最后。这样做的目的是使总体语气保持正面，同时确保收到负面反馈。这有助于防止在进行复审时产生压力，并有助于防止事后自我吸收。两者对于生产率和质量都非常重要。这不只是敏感的情感冲动；这是人类的行为101。

同样，您必须了解与您一起工作的人，并了解他们的反应。与人打交道是管理层的重点，优秀的经理知道如何使人们做出回应。

我认为积极的反馈非常重要，这主要来自个人，现实的政治动态。我们每个人都坐着写代码长达数小时，数天，数周，数月，而我们大多数人都为自己的工作感到自豪。代码审查是展示这一点的机会。

如果您去进行代码审查，而您希望获得的最佳结果是“不发表评论”（即没有正面反馈的平衡），则会议很容易以“发现人们认为您的糟糕程度如何”为标题。因此，开发人员将开始对代码审查感到厌烦甚至恐惧，这显然对团队不利。开发人员将“忘记”审查他们的代码，或者发展出学习到的无助感，而只是问他们不断的批评者该怎么做才能避免在这些会议上被炸毁。

很好地说，从理论上讲，修复坏处并要求每个人把情绪丢在门外是最合乎逻辑的，但是恰恰是负责代表开发人员的态度像人际交往一样充耳不闻。除了理论，我们是人类，人类喜欢时不时地拍打，甚至是名义上的拍子。那东西很重要。

如果您要进行并排审核或团队审核，则更为重要。在书面评论中，没有新闻是好消息。目的是使代码投入生产。当是您的代码时，您应该对自己感到满意。

代码审查应用作信息来源，以帮助指导和管理团队。在不使代码审查数据库混乱的情况下，有很多机会给出积极的反馈。可以拿出一些例子与他人分享。

除了开发人员的代码外，还有很多其他事情要审查开发人员。劫持代码审查时间可能会适得其反。设置特定于在代码审查之外帮助开发人员的时间，但这并不意味着您应该排除代码审查反馈。

我想到提供对代码的积极反馈可能会适得其反的唯一方法是，如果您不小心避免“反手称赞”。大多数人都熟悉这一点……它的意思是诸如“干得好，但是……”

如果每个人都以这样的态度参加会议：这不是程序员的个人评论，而是努力提高整个系统质量的编码实践，那么所有反馈都是“好的”反馈。强调改进编码实践方式的反馈与强调解决问题的有用新方法的反馈一样重要。

至少，如果没有那么长，应该强调的是，努力在审查过程中做到“良好的反馈，不良的反馈，良好的反馈，不良的反馈”循环。同样的反手赞美感觉。不要试图强加良好的反馈，不要试图加强努力，以免增加知识的空缺。

多年来，我从中学到最多的短语：

• “这是一种有趣的方法。如果我们必须适应[某些其他用例]，会发生什么？”
• “不错的尝试！您知道我们已经有这样做的方法吗？也许我们应该做一些基准测试，看看哪种方法更有效。”

我最喜欢代码审查的工作流程是：

1. 开发人员通过邮件列表/在线工具提交补丁。
2. 每个需要照顾的人都会仔细研究补丁，并提出改进建议。
3. 开发人员回到第一名
4. 如果不需要改进，人们会说“好工作，请投入。” <-积极反馈。接受的所有代码都是好的。人们告诉您更改事物的次数越少，您所做的就越好。
5. 开发人员提交，进入下一个项目。

通常会发生的情况是，新开发人员在熟悉代码库时会得到更多的“校正”反馈。

这种方法的好处是：

1. 每个人都知道每个人在做什么。没有垄断或神秘的知识。
2. 每个人都从他人的反馈中学习。这个很重要。如果在配对时面对面对话中仅2个人之间发生了反馈，那么会议室另一侧的某人将无法获得与邮件列表中发生的相同的收益。
3. 其他开发人员通常可以在版本控制中发现一些错误。

我完全不同意。优秀的开发技术与所谓的忍者编码者有什么区别，他们可以编写出色但无法解释的凡人代码？现在，软件开发（IMO）是最低的通用分母领域，在这里，人们摒弃了天赋和狡猾，而倾向于可维护性和易懂性。太冒险了。

我想不出有一次我在评论中看到过代码，这会让我转为“哦，很酷”。我只能假设，如果确实遇到过这样的代码，它将落入“尚待接受”的阵营。

您还会遇到无法获得积极反馈的人的问题，他们可能会努力尝试并最终搞砸“相信我，它有效！”。

代码审查可以在团队中分散代码质量责任，即如果以后出现严重问题，则不能责怪单个开发人员。用它来发现问题，并用它来从怪异的东西的原始开发人员那里获得解释，以防万一您最终不得不维护它。就个人而言，我对收到负面反馈更感兴趣。客户不关心代码的凉爽性，而只是关心代码的作用。

将回拍留给酒吧。

这对我很重要。为了阳性，我不想要绒毛评论或阳性。如果我编写的所有代码都很烂，请告诉我原因，让我们对其进行纠正并学习。但是，如果我做对了，一次又一次地听到它会很高兴。我所做的一切都是“正确的”，我不需要积极的加强，但是即使是“让我们改进X，Y和Z，但其余的看起来都不错”，也很重要。

没有诚实的反馈那么重要。我在一家大型金融公司工作，我们的客户不在乎程序员是在努力还是做一个好人，或者通常编写好的代码！他们需要有效的软件。

我认为完全客观很重要。试图通过发表正面评论来鼓舞士气，这在我看来是浪费时间。

这可能意味着代码审查过分关键-但这不是重点。我们也应该批评自己。我发现，我编写的代码可能完全是垃圾，而且肯定可以改进的假设驱使我提高代码和技能水平。

如果您未收到任何评论，则可以认为您做得很好。

口头禅很简单：如果人们想要高质量的代码（实际上是很少的），那么就必须采用适当的审核方法。话虽如此，积极的反馈有助于开发人员/程序员思考并提出想法/解决方案/修正。不要太苛刻，但要坚决。问答管理人员应了解良好的方法和做法，以便他/她可以向正确的方向指导团队（或成员）。这导致质量。期。

当代码是用于比赛或为求职面试而提交的（换句话说，已编写且无法重写的代码）时，必须要有积极的评论。实际上，您应该确保有正面的反馈（如果可能！）以及负面的反馈。这样，编码人员便知道自己的长处和短处在哪里，并可以进行补偿。

但是，您似乎是在可以重写代码的工作环境中讲话。在这种情况下，您将尝试从系统中获取错误。因此，在那种情况下，只有负面的错误才有价值。

如果您对此感到不舒服，请每周召开一次代码审查会议，每个人都可以讨论好的代码和坏的代码。

编辑：虽然我会说，如果某件事给您足够深刻的印象，没有什么可以阻止您亲自表扬您的赞美。但是，该跟踪器似乎仅用于生产代码审查。