Answers:
如果您必须为此类基本内容辩护，那么您会遇到更大的问题。
您是专家，您的团队应决定使用哪种做法。也许您应该开始说服老板相信这一非常重要的原则。
您的老板应该决定要做什么，更重要的是为什么要这样做。您应该注意如何构建它
（这当然并不意味着您不能建议您在公司中做什么以及为什么要这样做）。一位出色的老板应鼓励其员工参与企业战略）
但是，这是我如何查看对等代码的评论：
因为编程是一项非常密集的智力工作，所以一个人无法确保所有内容都是完美的。因此，代码检查可确保：
每个人都从中直接受益：
代码审查可以使多个开发人员熟悉相同的代码。这是一件好事。如果原始作者决定退出或更糟的情况，那么他会遇到不好的事情。如果定期进行代码审查，其他人可以迅速接管。
同行也许可以在代码审查期间发现潜在的错误或性能问题。这样可以减少质量检查和开发工作。这可以补偿代码审查中涉及的额外费用。
代码审查可促进知识共享。同行可以说出更好的方法或做事的替代方法。我自己已经通过代码审查从同行那里学到了很多东西。
代码审查有助于加强团队遵循的编码准则。如果团队没有成员，则需要纠正。代码只能编写一次并读取多次。编码准则是迈向可读代码的一步。代码意味着对等体可以读取。有什么比进行代码审查来确保可读性更好的方法呢？
这里有很多很棒的答案。我会添加一些内容：
当您不得不向其他人解释代码时，通常在解释过程中，开发人员可能会突然意识到他有错误。我已经看到它一次又一次地发生，开发人员停在他的轨道上，并在审阅者足够了解该错误之前说“哦，这是错误的”。
知道您的代码将被其他人检查可以使您更有动力使用编码标准（使维护更加容易）或使用更少的“牛仔”方法，只有您自己（有时甚至您自己）都无法理解。当您向他人展示您的代码时，您不想感到尴尬，因此首先您可以在代码上做得更好。由于尴尬的原因，它很少用以下代码注释：“我不知道为什么这样做，但不要弄乱它。” 在代码库中。
容易确定需要更广泛的监督或培训的开发人员。彻底的无能也是如此。您越早发现并解决性能问题，整个团队的工作就会越好，应用程序的质量也会越高。在选拔需要培训的新手之前，先找出这些信息，然后将其分配给应用程序中最困难，最关键的部分。
有时，只是纠正错误的看法而已，这可以避免在其他许多地方犯同样的错误。例如，我们最近正在审查一些复杂报表的SQL，发现我们的一些新开发人员对在数据库中何处查找特定信息存在相同的误解（诚然，他们选择的位置似乎合乎逻辑，这是我们在数据库设计中遇到的问题）还需要修复），这对于正确编写所有报告至关重要。通过发现问题并在他们编写的第一份报告中予以纠正，它避免了其余报告中发生的相同错误。某些较老的（过去在这里工作而不是年龄的）开发人员已经习惯了，他们认为不需要解释。
大三学生可以从大四学生编写的更复杂的代码中学习（例如，他们倾向于更好地理解错误陷阱和边缘情况），大四学生可以从大三学生使用的尚未接触过的新技术中学习。
有时，在应用程序不同但相关的部分上工作的人们意识到，他们朝着两个不同且互斥的方向前进。糟糕，现在更容易修复。
潜入硬编码的值并不是一件容易的事，这些值会随着时间的流逝而改变，以使事情立即生效。这样可以防止将来出现许多错误，例如在每个会计年度开始时发生更改的错误。
有时，我一直被困在如何做某事上，并学到了一种新技术，正是我希望通过代码审查别人的东西来获得的。
如果您熟悉团队其他成员的想法（哪种代码审查有助于您了解），那么以后解决问题将变得更加容易，因为您将从了解Joe如何处理此类问题开始。问题。
代码审查可以：
缺点
如果这是事实，那么我们似乎总是有时间为同一位客户做两三遍，但我们却没有足够的时间在第一时间做对。
如何运行由两个团队并行执行的演示（一个为期一周的“米老鼠”式项目），一个团队使用代码审查，而另一个则没有。
在一周结束时，评估每个团队的工作质量，我很确定代码审查员会变得更好。
史蒂夫·麦康奈尔（Steve Mcconnel）的Construx 提出的改进软件实践的业务案例以及软件软件开发的“垂手可得”（LHF）都可以解决这一问题。在后者的“高层管理人员不会抵抗的LHF”中列出了检查。