在添加新功能的过程中，何时应查看代码？如果我们将其保留到代码完成之前，则可能已经浪费了很多时间来朝错误的方向前进。太早了，想法只形成了一半。那么，最佳点在哪里，我们又将如何决定呢？

解决方案

回答

每当我们完成一项功能时，在我们开始测试该功能之前，我们都会进行代码审查，只是非常简短。这样可以避免大多数丑陋的代码，然后每周执行一次，以对自上次迭代(我们是一家敏捷商店)以来所有功能进行完整的代码审查，而所有没有良好代码审查的功能都会在我们每两周的迭代中，测试未视为完成。

回答

我说最好在整个开发周期中都这样做，尤其是对于我们可能不信任其实践的新开发人员。

在编写除原型代码之外的任何内容之前，我必须先向设计者提交设计文档，以便尽早发现任何糟糕的体系结构决策。另一个好处是，我在遵循我们团队的实践方面积累了丰富的经验。审查之后，在实施代码时我进行了几次审查会议。

我觉得没有理由在设计阶段到最终评审之间不应该进行多次评审。

回答

我的观点是，我们应该在开发的早期进行高级别的审查，重点是设计和体系结构，而在开发的后期进行低级的审查，重点是效率和技术。

有多少条评论取决于我们，具体取决于可用时间和其他因素。

回答

理想情况下，将功能分解为较小的部分，以使任何一项"任务"都不会超过几个小时的工作，甚至一天。当这些步骤中的任何一个完成后，并且已经由开发人员进行了工作进行了单元测试时，就该进行代码审查了。在一个复杂的项目中，我们一次不应该让人们一次连续数周"昏暗"，在此期间没有任何签入或者评论。

回答

我们必须要审查的代码-所以不能太早。审查未完成的代码没有任何意义。查看未完成的代码意味着我们浪费了太多时间。

当编码人员认为代码是通过离散功能或者错误修复完成时，请复查代码。然后要求他们负责跟进并做出建议中的更改。

代码审查的目的并非专门用来修复正在审查的代码。这是团队合作的机会。在花了一些时间之后，希望这些评论会减少团队中的问题，并为团队带来更多的见解。

在某些情况下，当我们要培训Jr. Dev时，我们可以通过指导和结对编程"查看"他们的代码，但这不是官方的代码审阅。

查看此问题以获取一些代码检查资源。还要检查代码协作者。

回答

现在是进行代码审查的最佳时间。只要对方休息一天，代码审查就如事后思考一样，在最后完成时效果最差。它们应成为开发过程的一部分。

没有比阅读其他人的代码页还要糟糕的了。开始略读而不是在100％的时间里付出100％的努力只是人类的本分

回答

我发现最有效的代码审查形式是实时代码审查。也就是说，请在编写代码时对其进行检查，并积极参与代码的设计和实现。

回答

我认为编写代码后，任何新功能的方向都不应变得显而易见。也就是说，任何新系统的实际实施都不应令有关方面感到惊讶。以前，我使用的是提案系统，即使我所在的团队不采用它，我仍然会使用该系统。

基本上，此功能有一个高级摘要，一个说明图(可以是UML，流程或者任何能在视觉上最好地表示所建议系统的东西)，以及一些有关棘手算法的实现级别的讨论。进行这项工作的一个关键因素是尝试提出两种解决方案，并在争辩其中之一时描述两者的局限性。

这有助于防止人们沉迷于他们的第一个想法，以至于他们不考虑替代方案。

然后，所有感兴趣的各方都可以对提案进行评论，并提出问题(维基对此非常有用)。原始作者可能会根据反馈一两次修改提案。如果没有指出特别大的"陷阱"，则开始实施。

仅当第一个可用的实现出现并且可以对代码进行测试时，才需要审核实现的细节(例如：代码)。有人假设要求个人遵循他们提出的提案的修订版本。

回答

以我的经验，最好的时间是在程序员完成对合理大小的功能/迭代的编码，并进行必要的单元测试以确保该功能真正起作用之后，进行代码审查。这两件事应该使程序员花了不到5天的时间，否则我们正在查看过多的代码以彻底检查该步骤。

程序员应该能够意识到任务什么时候都没有进展，并且可以在任务分配的时间用完之前寻求帮助，因此从理论上讲，解决方案的"正确性"不应成为代码审查的重点，因为与达成解决方案的方式，编码样式(如果公司已安装它们)，可读性和文档类似。我们可能还希望在代码审查中查看哪些单元测试，以确保不会遗漏合理的情况。

回答

我获得的最大成功是为4至5人的小组安排了定期的每周评论。每个人都会带来他们的代码，每个人都会被选中。

我曾经经历过的最糟糕的经历是，我们曾经等到项目结束时才去做。那时，进行更改为时已晚，并且有太多代码无法有效地进行审查。

回答

我假设我们正在事先审查建议，以查看它们是否"偏离轨道"并浪费每个人的时间。 ;-)

如果是这样，那么我将对设计进行一次检查。

取决于"遗失但必不可少的信息的披露量"(-：我将在开发过程中以敏捷的方式审查进度和更新。

没有什么比让某人在几天/几周/几月内在黑暗中躲避海狸更糟糕的了，只是让我们发现他们以完全错误的方式/技术/样式/等实施了某些东西。 )-：

此外，在部署代码之前，使用Fagan类型的无自我技巧进行代码审查是必不可少的。

回答

当代码功能完整但在实现者的脑海中仍然新鲜(否则她将很难解释某些决定)时，将完成代码审查。

功能的设计(功能的实现方式，涉及的模块，调用的方式，调用的人，使用的全局/本地数据，对处理，其他模块，I / O的影响)完成时，将进行设计审查。 ，满足的要求，特殊的特殊情况等)，并记录在案。

设计审查应该提供足够的信息，以便人们可以在实施和调试代码之前就知道这是否是错误的方向。