代码审查真的可以在真正的敏捷环境中工作吗？

因此，我开始为一家大型公司工作，其中一家公司名称中有3个字母，他们试图成为敏捷公司，但是却有大量流程，我认为这些流程不是敏捷的。

让我最受困扰的是代码审查。我最后的工作是在一家初创公司中工作，我可以说这是我见过，曾经和/或从未听说过的最敏捷的开发团队。

无论如何，我的观点是，代码审查在UX / UI极端/强烈（想想Apple / Steve Jobs完美）的迭代或敏捷开发中浪费时间。也许有人在解雇我之前可以帮助您理解？

这是我的开发过程，也是我上次启动的过程。非常敏捷。

我们进行早期功能工作以对开发任务/待办事项进行排序。我们将模拟几个版本并将其呈现给用户，团队和市场，以获取反馈。然后，我们进行另一次样机迭代，以从上述相同的涉众获得一轮机会。然后，我们将工作分拆并开始。我们有一些里程碑和日期可以见面，但我们一直在努力。在此期间，我们没有任何代码审查。在我们开发的几周中，我们几次与利益相关者进行讨论，以了解他们是否仍然同意功能/功能/ UX / UI仍然是合适的目标。

随着8周迭代周期即将结束，质量检查人员开始进行测试，然后测试对象为alpha用户，最后是beta用户。但是在Alpha和Beta测试期间，开发人员将研究新功能和旧功能，对UI进行每日或每小时迭代更改，以改善UX。因此，此版本正在开发的功能可能会在过去四周内被更改3次以上，以进行改进和完善，或者添加一些微小的功能（例如，使组件更光滑或更智能）。有时这些更改可能是肤浅的，这意味着没有更改或修改任何CRUD操作，而仅更改所有UI。

因此，使用这种类型的开发过程（极端敏捷），代码审查不会浪费时间吗？这意味着如果我有另一个开发人员或两个开发人员来检查我的代码，但是由于所有UI / UX的改进，代码在发布之前又要更改3次，我们是否不浪费时间来检查代码的前3次？该代码/组件/ UI被废弃了吗？

我们在此过程中从来没有遇到过很多质量问题，是的，如果开发人员将所有知识都排除在外，但是我们总是找到聪明的开发人员来接管并接管。

是的，我们有很多测试人员，因为他们可能必须重新测试3到4次。另外，请不要挂断询问为什么所有的UI / UX都会发生变化...那就是事情的完成方式...那么那就是为什么该应用程序会赢得大量的UI / UX奖并且用户会因此而丧命应用程式。思考的过程是，如果我可以多花2个小时来改善某件事，那么我可以将其提高2％。用户会更快乐，这意味着更多的$或用户。是的，我们的用户可以继续更改应用程序，因为这是自第一天以来的工作方式，因此他们不会认为它是不好的还是负面的。

希望这篇文章不会那么夸张，但是我看不出代码审查是不是浪费。也许我们所审查的代码中所有代码的2％都有错误。每个版本的代码审查可能会发现3个错误。因此，最终每个开发人员每个版本需要40个小时的代码审查（4 x 40 = 160个小时），才能发现3到5个错误？无论如何，质量保证会发现3到5个错误的可能性是50％。每个开发人员花40个小时来添加新功能或改进现有功能会更好吗？

代码审查可以为您做一些事情，而代码审查则做不到。支持代码审查的论点：

• 集体所有权
• 查找错误（QC）
• 实施一致的样式（QA）
• 指导

许多敏捷过程以不同的方式解决这些问题：

• 集体所有权：团队中的每个人都对项目负责，这意味着在任何给定时间，每个人的眼睛都将关注代码。
• 免费重构：将代码审查提高到一个新水平，并允许团队中的任何人根据需要执行重构。
• 单元测试（QC）：与外观检查相比，单元测试效率更高，更不容易出现人为错误。实际上，我还没有找到更有效的方法。
• 配对编程（QA）：负责指导并在编写代码时提供早期的重构建议。这仍然是一个有争议的话题，但是我发现它在增加新开发人员时会有所帮助。这也是实施编码标准的好时机。

本质上，还有其他途径来照顾您通常在同行评审中获得的潜在收益。我对同行评审的个人经验是，它们是非常低效的机制，不能有效地发现错误或更大的设计缺陷。但是，它们确实在某些团队中占有一席之地，并且在敏捷性不可行（无论出于何种原因）的项目中，它们是非常必要的。

代码审查只是为了发现错误吗？您似乎以为是对的，但我不是。

我认为，代码审查可以更多地涉及代码的集体所有权，确保知识掌握在多个方面，并准备让其他人继承可能适用于新功能和错误的代码。我喜欢将代码检查作为对系统进行一些检查和平衡的一种方式，因为您永远不知道何时有人会知道在什么地方可以重写某些东西以维护约定。

配对编程是XP进行代码审查的答案。本质上，每行代码在编写时都会进行审查。这是代码审查的极致。

代码审查和测试通常不会捕获到相同类型的错误，并且由于已知错误的位置，因此代码审查捕获的错误可能更易于修复。

您不能仅仅因为代码通过了测试而没有记录任何代码就知道代码是否没有错误。“测试只能证明存在错误，而不能证明存在。” （Dijkstra？）

代码审查还使代码样式保持不变，并且能够找到代码不好但可以立即使用的地方。这样可以节省未来的维护成本。

而且，大型公司和初创公司的需求是不同的。启动通常会失败，并且必须快速发展。大型企业通过正确地做事而不是尽可能快地获取更多的价值。与大公司相比，您可能更喜欢在初创公司工作，但这不是试图在不合适的地方强加启动策略的原因。

您的代码审查是否只会出现UI / UX更改？我认为这不是代码审查，而是可用性测试。代码审查更多地是关于解决用户/测试人员/业务/任​​何人从未见过的问题，因为它们在代码中。线索就在名称中。

现在，我将与您达成一致，在某处划一条线。您是否审查了同一UI更改的4次迭代？还是您经历了4次迭代，每次迭代都有可能使代码的可维护性降低？我会说尝试衡量这两种方法并为您的团队找到合适的平衡点，但是不要完全放弃代码审查。

即使代码复审从不出现问题，它的好处是直到很少出现之前您几乎不会注意到：每一个代码都是由两个开发人员查看的，所以两个开发人员都知道更改是什么以及要实现的目标。因此，他们中的一个人第二天病倒，休假一周，另一个人可以接受他们正在做的任何紧急工作。

我倾向于同意，集体代码的所有权和与TDD和CI的配对是正式代码审查会议的敏捷解毒剂。

即使在UP / Spiral下，我也不喜欢特定过程步骤的“代码审查”，因为在我看来，发现相同问题的可能性要比发现相同问题的时间要晚一些。协作和一些简单的自动化。

我之所以这么认为是因为：-对设计进行一些共同的审查（通常至少在白板上以UML表示），这意味着大规模的设计问题或对API的不良使用等，在编写大量代码之前就被抓住了。-FxCop，CheckStyle，FindBugs（或类似版本）与自动连续集成一起运行，以捕获命名，样式，可见性，代码重复等。

与下游代码审查习惯相比，我们能够更早地失败并获得反馈。

我并不是说坐下来偶尔看一下您的代码库是在浪费时间，但是让代码检查成为调用已完成事情的重要步骤似乎像是在进行很多本可以进行的工作避免在上游进行更好的检查/合作。

我期望代码审查的主要目标之一是增加代码维护的便利性。代码审查应帮助每个人编写合理地符合良好编码标准的清晰代码。大多数代码都需要大量维护，尤其是在大公司中。可维护代码的回报应在代码发布之前开始，然后再继续。

本身的代码审阅绝不应该导致代码更改。如果代码检查表明需要更改，则实施更改将导致代码更改。

审查可能会导致代码状态发生变化，但这应该与您提到的问题无关。

如果代码检查导致多个代码更改，那么在您的开发过程中会出现问题。考虑到您拥有的测试人员数量，可能会碰壁，让测试人员发现问题的心态。

事情应该在完成状态下交给测试人员。应该将尽可能多的测试自动化，以便测试人员不会一次又一次地重新测试相同的东西。

UI / UX确实需要一些测试时间，但是在前端聘请设计/开发专家应该可以减少测试时间。它还需要屏幕前面有一张脸。但是，在我使用过的所有应用程序中，它只是代码的一小部分。

实施更改（包括错误修复）的成本通常在其经历的每个阶段都会增加。在开发中发现错误通常比在测试发现它们后对其进行修复要便宜。