初级开发人员是否需要进行代码审查？

我曾在两家公司工作过，在进行代码审查时，每个公司都有不同的方法：

在第一家公司中，团队负责人进行了代码审查，并且在完成每个模块后都需要进行代码审查。

但是，在第二家公司中，不需要团队负责人进行任何代码审查，而只是检查功能和设计问题。

所以我很困惑。确实需要代码审查过程吗？如果是，为什么？如果不是，为什么不呢？

我个人认为每段代码都应该经过代码审查，无论您是初级还是高级开发人员，都没有关系。

为什么？对于初学者，您的头衔并没有说明您的开发方式，高级开发人员可以向初级学习。在我们公司，我们会四处走动，因此团队中的其他成员之一会审核您的代码...大多数情况下，我们都是由“初级”和“高级”组成的团队，因此所有日常事务都可以陷入了跟进。如果大四不喜欢初中的代码，他应该听听初中的原因，然后看看它，看看这是否是可行的解决方案，将来可能会使用……无论如何都要变得更明智你是谁。

关于代码审查的重要一件事不是太好，如果您是一个好人，那么您只会允许越来越多的混乱代码在系统中发展。就像昨天一样，我开始重新设计一个以前雇用的juniordeveloper编写的完整应用程序，我的天哪，代码在他离开之前可能需要进行审查。

我不明白为什么应该只由团队负责人来进行审查，但是它要求一个人不惧于对一段开发不良的代码进行“斗争”，而必须是一个关心代码应该如何工作的人是。并非所有公司都会雇用真正关心他们所做工作的人员，并且不应该允许IMO对那些不好的蛋进行代码审查，因为它们可能只是耸耸肩，对不好的代码说“好”。

基本上，无论经验如何，所有程序员都需要进行代码审查。这是软件开发的质量控制，也是开源质量很高的原因之一。

编辑：原因是今天的代码审阅者的角色与以后的维护者完全相同。如果今天的代码对他来说没有意义，那么以后也将毫无意义，从而使错误修复成本更高。因此，在开发人员仍记得该代码的同时，使其今天可以理解。审阅者还可能会看到开发人员遗漏的错误或遗漏。

不幸的是，很少有人愿意这样做，但是从商业角度来看，它应该是强制性的。

我在一个现在需要进行代码审查的地方工作，但至少在3年前。它极大地改善了我们的代码以及其他人以后维护代码的能力。即使是资深，经验丰富的开发人员也会犯下错误，可以在QA发现错误之前轻松地在代码审查中修正错误，或者在客户找到错误之前更糟。此外，除原始开发人员外，至少还有一个人熟悉该代码。

通常，当组织尝试一些新事物时，就像我们对代码审查所做的那样，对变更存在很大的阻力。我几乎没有看到带有代码审查的内容（我们也很高兴获得正式的质量检查部门。）只需花费一两个评论即可看到其价值。

我发现在对他人的工作进行代码审查或对我的代码进行审查时都没有考虑过的新技术。通过进行代码审查，更重要的是根据他们对代码审查的响应方式，我们发现新员工的能力问题相对较快。我们已经学习了哪些东西现在似乎已经很清楚了，这在编程该部分的内容中是显而易见的，而在维护中这些部分将是不清楚的。这是无价的。可能唯一需要做的就是评论为什么要做某事。我们发现了一些有关数据库设计的基本误解，需要纠正这些错误才能使报告实际具有正确的信息。

我在代码审查中经常看到的是，通过向他人解释某些事情的行为，开发人员会打开一个灯泡，并意识到审查者没有看到一个错误。

男孩可以通过代码审查来识别那些不会遵循任何标准或使用强制性工具并且其代码几乎无法被其他任何人维护的牛仔程序员。而且它可以迫使他们加入该程序或退出该程序。

最抵制代码审查的人员通常是组织最需要摆脱的人员，因为他们内心知道他们的代码无法通过代码审查。

敏捷的家伙会说：“您不需要代码审查，只需进行配对编程并编写好的测试即可” :)

代码审查是通过团队传播知识和良好实践的好方法。以我的经验，最好确保所有代码都经过审查，并尝试改变谁审查哪些代码。

在我目前的团队中，每个人的代码都受到同样的审查，并且程序员和审阅者都必须对代码满意，然后才能发布它们。这同样适用于由更多初级开发人员审查的高级开发人员，正在审查另一个的初级开发人员或其他相互审查的高级开发人员。如果审阅者没有经验或不喜欢审阅任何特定的代码段，则他们将与另一位开发人员（也可能是原始开发人员）合作进行一组审阅。

我从事该行业已有20多年，曾在软件公司和不同行业工作，这些地方都没有代码审查流程。但是，我可以理解并欣赏拥有一个的好处。从本质上讲，据我所知，应该使用它们来确保遵守标准，为了使其他人将来能够更轻松地维护代码，应该遵循这些标准。在检查过程中也可能会检查代码的可读性，因为这也将确保维护可以有效地使用代码。

目前，我在一家单一开发商的小商店里工作。有时我们会请承包商来帮助解决积压问题。这些承包商中至少有一两个编写的代码不一定符合我的或公司的标准，但它确实运行良好，并且至少可以理解。当我向管理人员指出这个问题时，他们不在乎，他们只是想知道它是否做了我们付给他们的事情。因此，我想这取决于公司，以及是否需要干净，易于维护的代码是所需的产品，还是他们只是想要一些物有所值的产品。

显然，作为一名开发人员和必须维护代码的开发人员，我想使用遵循某种标准的干净代码，但是我并不总是那么奢侈，因此我会尽力而为，并处理我所拥有的东西，即使这意味着有时不得不以我自己的标准重新编写一些代码。

当问题更容易（更便宜）解决时，代码审查可以在软件生命周期的早期发现缺陷。在SmartBear，我们开发了对等代码审查工具，并且还对如何使代码审查有效进行了大量研究。根据我们客户的数据，在代码审查中发现和发现的缺陷比在质量检查中发现的缺陷便宜8-12倍。光是节省成本就可以使代码审查值得，但不仅仅是价值。代码评审是团队中每个人作为软件开发人员学习和改进的一种极好的方式。

有一些陷阱可能导致代码审查的效率降低，并且您的组织似乎陷入了其中之一。对代码进行审核，而不是对人员进行审核。标题在代码审查中没有任何意义。呼吁权威（因为我是团队的领导，所以必须尽我所能）弊大于利。代替。高级工程师应该解释为什么应该按照自己的方式进行，而不仅仅是要求这样做。如果您很难解释一个概念，那么这对您也是一种学习经验。你们俩都会为您付出的努力成为更好的开发人员。

我认为审查所有代码的代码是过大的。复查所有代码所花费的时间可以在其他地方花费更多。Alterntivley我认为关键代码，或者特别是复杂的代码需要进行代码审查，但是当然不是每一行代码。

我认为，公司将使用的代码，无论是由初级开发人员还是高级开发人员编写的，都应始终进行审查。为什么？因为如果代码有几个错误怎么办？如果在使用此代码的过程中程序崩溃了怎么办？为了阻止这些事情发生，应在使用之前检查所有代码。

但是那些不审查代码的公司呢？他们可能是存在很多技术问题的公司，而且正如他们告诉消费者的那样，它们很多都是“崩溃” ；-)。

因此，让我回答您的所有问题：

• 是的，审核过程是必要的。
• 为什么？由于上述原因。

代码审查：代码审查过程对于所有人来说都是至关重要的过程，我将解释谁因进行代码审查而从中受益，以及他们将获得什么好处。

1.公司通过进行代码审查而获得的好处： 如果进行频繁的代码审查，则公司可以以更好的最佳方式获得最终产品，这将有助于他们在市场上获得品牌知名度，并帮助公司获得或提高其当前的CMMI水平。

2.进行代码审查对团队负责人的好处： 众所周知，教师可以很容易地发现错误，因为他们可以更频繁地审查学生的答案，因此他们可以获得一个想法，在哪些方面可以有可能发生错误的事情。同样，团队负责人也知道这方面出了什么问题。我们如何纠正这些问题，还帮助团队负责人也从初级开发人员那里获取新闻创意。

3.进行代码审查对初级开发人员的好处： 初级开发人员可以轻松掌握有关代码审查流程的想法，他们还可以获得什么编码标准，例如：以适当的方式创建API，他们将学习编码的标准化，这可能会在将来成为高级职位时特别帮助他们。

所以我的结论是，代码审查对所有人（甚至对团队成员而言）都是非常重要的过程，因为代码审查有助于我们纠正代码中的粗心错误，因为我们都是人，因此我们无法预测我们永远不会在代码中犯粗心大意的错误。

在检入代码（审阅）之前或之后由于错误，太聪明/难以理解或不遵循公认的标准惯例而干扰您的想法有什么区别？是你的自我吗？

您不能无视代码审查或其他任何东西的优点，仅因为它是由您不尊重的，素质较低的团队成员实施得不好所致。代码审查不是一个只有几个超级程序员才能掌握的高度复杂的过程。我不确定是否有很多程序员或专业作家有能力或有时间进行自我编辑。

几个月后，您是否曾经返回过一段代码，想知道我在想什么？通过代码审查会更好地抓住它。您刚刚抓住了它，并且只比之前的程序员略胜一筹-我希望。

IMO的代码审查对所有开发人员都应该是必不可少的，但前提是进行审查的人员必须胜任。过去，我在审查中拒绝了代码，因为，我跟你说过，我SOLID没有让你做依赖注入，并且根据逻辑设计将代码组织到了名称空间和文件夹中，并且包括一小套单元测试，验证代码。代码被拒绝为“太复杂”，我被告知使用一个将所有内容混在一起的类并删除测试，因为这不是公司编写代码的方式。

像这样的代码审查是毫无价值的，但是与有能力的团队一起进行代码审查通常可以阐明有关设计的某些信息（例如，为什么要执行X和Y而不是Z）或指出实际的缺陷（例如，执行X会导致Y失败）由于不正确的原因）。

当然不需要代码审查。再说一次，测试，持续集成，源代码控制，客户参与，分析，静态分析，体面的硬件，一键式构建，错误跟踪，列表都没有。

与代码审查一起，我上面提到的东西是有助于确保软件质量的工具。结合技巧，运气，时间和决心；您可以在没有任何这些东西的情况下提供高质量的软件，但更有可能您不会。

在您的方案中，没有什么可混淆的。并非每个组织都沉迷于每种最佳实践。他们可能不同意这一点，可能与他们确实实施的另一种最佳实践相冲突，或者他们可能认为此时实施该方法的开销对他们来说太大了。根据他们的情况，他们这样做可能是正确的，或者可能是虚假的节约。对于某些工具（例如源代码控制），投资回报/工作量比率是如此之好，以至于使用它就很容易了。对于其他人则不清楚。

毫无疑问，代码审查是一种引入大量开销的做法。因此，组织将通过完全不执行或仅在某些情况下（例如，对于初级团队成员或特别麻烦的更改）来最小化该开销。回报并不总是很明显（在捕获错误，减少技术债务或共享知识方面）比其付出的代价还多。大部分回报很难量化，而很容易计算您的组织用于审核的工时数。最容易量化的部分（减少的错误数）很容易归因于其他因素（例如“当然，错误更少，更成熟了”）。

我们在土耳其制作在线足球游戏。许多用户和游戏大师都可以帮助我们实现功能。他们还会对所需功能进行评论。因此，我认为，如果您有很多用户，则可以进行功能测试以帮助获得徽章。开发人员，游戏大师和用户与论坛，支持团队和私人测试环境的合作创建了一个社交项目。

当然，必须进行代码审查并在开发团队之间共享经验，但是如果不是很关键，则不必强迫自己。

我认为，第二方检查的详细程度取决于您的生命周期，无论您是更敏捷的工作，还是流程中更多的瀑布。我认为进行高级设计/检查以及更详细级别的设计检查是合理的。我认为让团队的几个成员进行检查也很好。

由于他们经验不足，因此绝对必要。