代码是否正在审查良好做法？

当我工作的公司雇用新的经理时，他们为我们提供了在每次会议上概述某人的代码的机会。我们每两周开会一次，因此每次开发人员要在投影机上展示他/她的代码时，其他人都将讨论它。

我认为这会很棒：每个开发人员在编写代码时都会更加小心，我们可以更好地分享我们的经验。但是不知何故，我们忘记了这一要约，而要约仍然是要约。

这有什么好处，有什么缺点吗？

代码审查是一种很好的做法。

这可能是学习错误并了解其他人如何解决某些问题的最佳方法。这也是在代码库中保持质量的最佳方法之一。

许多公司都进行代码审查，尽管很难说他们都遵循特定的过程。

在更正式的代码审查中，一个（或几个）资深人员将与开发人员坐在一起，以审查他们的代码，同时提供建议和教学。

代码审查的其他好处（对此问题进行评论）包括：

• 教与学的好方法
• 它们是改善和保持代码库（样式和习惯用语）一致性的最佳方法之一。
• 它们有助于确保所有团队成员了解项目中使用的样式和习惯用法以及如何使用它们
• 代码审查将尽早发现错误和设计缺陷，从而加快开发速度（因此，尽管它们可能会减慢最初的开发速度，但他们会在以后的开发周期中分红）
• 有工具支持可帮助简化代码审查过程

代码审查是非常有用的学习工具，尤其是当您有新的团队成员时。好吧，这也被称为同行评审过程：）

有不同类型的代码审查：

• 肩扛式开发–在开发人员浏览代码时，一名开发人员看着代码作者的肩膀。
• 电子邮件传递-签入后，源代码管理系统自动将代码通过电子邮件发送给审阅者。摘录自注释：未能说服管理层为任何形式的正式代码审查分配时间，但我每次使用Tortise内置的历史记录/差异工具从源代码管理中提取新修订时，都会考虑查看同事的更改。
• 配对编程 –两位作者在同一工作站上一起开发代码，这在Extreme Programming中很常见。
• 工具辅助的代码审阅 –作者和审阅者使用专门用于同行代码审阅的工具。

只有一种associated disadvantage形式的正式代码审查需要大量投资来准备审查事件和执行时间。

下面列出了更多参考资料（以获取更多的深入资料）

• MSDN-代码审查
• 在发布应用程序之前查找并修复漏洞
• 维基链接

这种特定的做法似乎效率低下并且可能令人尴尬-他们希望将自己的错误指向整个人群。因此，如果他们不能选择要审查的内容并且代码尚未投入生产，则可能会使人们感到不舒服。

取决于何时审查代码，对代码审查注释是否将其纳入代码有很大的不同。如果开发人员可以选择仅选择生产代码，则评论注释不太可能实现。召开会议很高兴，开发人员可以炫耀他们学到的其他人会感兴趣的精妙技巧，但这不是代码审查。那是训练。

在对每段代码进行质量检查之前，我们都会对其进行代码审查。每一件。它通常只涉及代码审阅者和开发人员。直到代码审阅者正式通过它之前，它都不会进行质量检查。因此，开发人员必须进行更改。我们已经找到并迅速解决了QA可能未发现的许多问题（它们也找到了我们在代码审查中看不到的问题）。此外，它可以减少牛仔编码，并迅速识别出表现不佳的人，以便我们解决他们的问题，并在他们损害我们的应用程序之前对其进行培训或消除。在计划工作时，代码审查时间是我们估计时间的一部分，因此它根本不影响截止日期。实际上，从长远来看，它可以节省时间，因为发现问题越早，修复起来就越容易。

我本人通过代码审查向经验不足的开发人员教了许多更好的技术，而我本人通过审查其他人的代码以及他们对我的代码的评论，学会了一些更好的技术。进一步的代码检查可确保其他人理解该代码，这对于使代码更具可维护性大有帮助。有时，该代码有效，但是由于存在问题，因此审查的问题清楚地表明，将会存在维护方面的问题，因为该代码难以理解。在这些情况下，最好还是在一年之后重新构建代码，而不是一年后甚至连代码编写者都ing之以鼻，想知道为什么代码会如此反复。

这种代码审查的问题是，每两周一名开发人员，进度会很慢。可能要几个月后，每个人才能引起关注。

虽然代码审查可能很好，但是在它们后面以及在执行这些过程的过程中一定有原因。

必须确定几个问题：

• 谁会选择开发商，他们会得到多少通知。没有通知的评论是陷阱。
• 谁会选择要检查的代码部分：管理层，项目的高级开发人员或正在检查的开发人员。
• 目的是教那些在投影机上有密码的人如何做得更好，或者目的是教那些在投影机上有密码的人教房间内的其他所有人如何改进他们的代码。
• 将以这种方式审查多少百分比的代码，这将成为质量检查流程的一部分吗？

如果提出该计划的人尚未对这些问题有答案，则有可能他们阅读了有关所有优秀公司如何进行代码审查的文章，因此我们也应该这样做，而不了解其背后的目的。

仅当代码审查的想法来自开发团队时，代码审查才是好习惯。开发人员不需要投影仪和演示文稿即可互相检查代码。如果他们愿意-他们将更愿意参加会议。

当代码审查的想法来自管理层时-听起来像是对软件质量低下的调查，并且会使开发团队丧气。我认为管理团队不应参与代码审查过程。与管理团队并行进行代码审查-非常糟糕，致命和具有破坏性的做法。

代码审查是一种很好的做法，特别是如果它是由开发人员完成的，以分享知识，并且预先设置了基本规则，则建议和批评应具有建设性，而不是让单个开发人员来进行目标实践。

如果非开发人员的经理决定进行代码审查，他们将受到怀疑。大多数经理类型都不想进入开发人员在查看代码时固有的细节。大多数管理人员也不会理解为什么开发人员批评一种方法而不是另一种方法。

如果您想展示开发人员在管理方面所做的出色工作，则“代码审查”具有不同的含义，并且不应与为指导/提高开发人员的代码质量而进行的代码审查一样详细。如果演示可以是更高级别的，而不是特定于代码的，则这种演示可能有助于演示开发人员的工作，重点是管理人员可以理解的内容（价值，ROI等）。这可能会使管理人员理解乔通过建立X可以为公司增加可观的价值，我们可以证明节省了Y的时间，或每张订单节省了Z美元，等等。您团队的成员。但是请记住，请务必小心，不要用术语或过多的细节淹没听众。

虽然我完全同意代码审查对于教学非常有建设性，但无论如何我还是要强调对我来说，这是为了确保正确遵循团队的设计模式。

我们编写了一些原型工作，并重构了一些代码，尽管最终我们对产品感到满意，但可读性已受到破坏-人们无法看清楚它的来龙去脉。

当您陷入某些特定的思维模式时，我发现独立的眼睛总是有益的，这是所有经验的水平。您在设计和代码上花费了数小时，因此，如果担心您的工作将被扔掉，则代码审查将很难处理。但最终，希望您最终得到了一个更清洁，更精简和更易于管理的应用程序，并且经验根深蒂固。

对于我们的团队，我们就像@ElYusubov提到的那样使用，并使用专门用于代码审查的工具-Crucible。人们检查，评论并签下代码。每周我们都会坐下来面对面回顾有趣和/或复杂的代码。

作为软件工程实习生，我发现代码审查非常有帮助。

在我的团队中，每次提交都需要进行代码审查（大的更改最终成为正式的，小的更改最终成为“快速的外观”）。我绝对感觉这似乎使我的工程/设计能力得到了提升，尤其是因为我知道自己正在被“监视”，所以我比终端机更有可能立即拔出白板。:)

实际上，我认为它可以产生更好的代码，唯一的缺点是开发时间稍慢（我认为，从长远来看，这是值得的，因为您不必修复/扩展非常设计的代码）。另外，我认为如果团队中有初级/实习生，他们将很高兴获得宝贵的反馈意见。我知道我做！

根据我的经验，如果执行得当，Code Review确实很棒。当您有专业/成熟的团队成员和经理时。作为程序员，我们是“解决方案的解决者”。我们的工作不是创建“文本”行。这就是为什么我们必须分享想法，错误，问题和经验。代码审查确实是实现此目的的一种好习惯。

不幸的是，这听起来不错，但实际上在大多数公司中都很难实施。您的团队需要大量的“自治”。说服您的经理或财务部门不创造新功能是有利可图的。

在我的公司中，我们正在尝试进行一些代码审查。但是“追赶兔子”（制作功能）花了太多时间。

如今，使用工具（FXCop等）捕获了许多样式和基本语法类型检查。

但是，代码审查是好的，特别是对于团队的新成员，复杂或影响很大的东西（例如，如果失败或引起业务影响的重要人员会注意到的东西），尤其是在外包或使用短期承包商时（尤其是再次使用）如果他们不是母语使用者，则可能是因为翻译错误/语言问题可能使软件通过所有测试，但实际上并未按照预期进行。

我不喜欢将代码放在投影仪上供团队使用-更好地召开代码审查会议，让另一位团队成员（团队负责人等）与开发人员一起进行清单。这影响较少的人-在样式争论上避免了很多浪费的时间-并且对于开发人员来说也不会感到尴尬。对于开发人员来说，吸收实际问题而不被“我本来会...”这样的注释所蒙蔽，更具建设性且更容易。

我还认为，未经强制执行的代码审查（例如将代码放入共享中或通过电子邮件发送给他人，希望有人放弃午餐时间进行审查）是浪费时间。

在咖啡区坐下来坐满一堆清单，一个记号笔和一杯咖啡非常适合。

这种小组展示和讲述将对新技术或获得几个jr都是有益的。开发人员加快了步伐，但我认为这不如对新代码进行一致的审查那样好。一对一地执行此操作效率更高。

代码审查有助于查看“整体”。单独的开发人员倾向于仅查看其需求/问题。CR从整个角度发现想法和解决方案。CR主要有助于消除不必要工作的浪费。整个产品更便宜，质量更好。