在进行代码评审时，是否应该将重点放在需求的完整性上？

Question

考虑到审阅者不是项目的一部分，而是被指派进行评审，因为他已经为正在更新/增强的应用程序编写了一些代码。

审核人员的职责是确保需求是完整和正确的吗？或者这是QA和业务测试人员的责任？

如果开发人员和审查员错过了在UAT中发现的需求，那么审查员是否也有错误(可能程度较小)？

Answer 1

这显然取决于您的代码评审过程，但就我个人而言，我认为需求的功能完整性更多地是在QA / Test的职权范围内，而不是在代码审查员的职权范围内。

这并不是说代码审查员不应该发现他们发现的功能的问题(假设他们有识别它们的知识)，只是说这不是他们的主要目标。

我通常认为代码评审是为了发现编码错误和效率低下、漏洞、内存泄漏，这并不是根据规范检查已经实现的内容是否正确，而是检查它本身是否“正确”。

如果您确实希望将其扩展到更多的功能评审，您需要接受这将对您需要投入的时间产生影响。如果您希望审阅者完全熟悉功能需求并对它们进行检查，那么您显然需要更多的时间来阅读和理解需求，并根据它们检查代码。

但是它不应该被看作是正确的QA和测试的替代品，这最多是一个额外的层。

广义地说：

• 代码评审-是生成高效、安全和健壮的代码。
• QA -它做的是规范中的大纲吗？
• UAT -完成的应用程序实际上在业务中工作吗？

Answer 2

如果审查员发现了任何问题，他肯定应该提到这些问题(特别是如果他是中小企业)。

但是当我收到需要检查的代码时，我会集中在功能级别上。我认为我作为审查员的主要工作是确保代码在将来是可读的和可维护的(如果我发现了but，我会指出它们，但我不会编写单元测试(虽然我发现缺少的单元测试，我会指出))。

可维护性涵盖了很多方面。我寻找的一些东西是:风格(尽管我在风格中指出的任何东西都是建议，我不要求它们是固定的)。明显的错误或编码样式可能会导致问题，或者会使代码难以扩展。算法是非常有效的(而且有一个简单的更好的算法)。任何不是琐碎的自我文档，没有描述代码的目标。

这是测试和QA的工作，以确保它做了一个充分的工作。

Answer 3

您在代码评审中寻找什么取决于您希望完成什么任务，以及希望实现什么正在进行的代码检查类型。一些代码评审侧重于安全性和寻找漏洞，另一些则关注编码准则的风格和一致性，而另一些则仅仅是对代码的正确检查。通常，审查员会被告知(无论是根据指南还是以核对表的形式)，代码评审正在寻找哪种类型的问题，因此他们的注意力可以集中在关键部分。

如果你关心的是高质量，你可能想在每个阶段引入评论。需求评审可以用来确保需求的完整性和可理解性。设计评审用于确保系统的体系结构和设计能够满足所有需求。代码评审可以用于确保代码与设计匹配，并且在测试之前不包含错误，以及检查测试用例的强度。

当涉及到确保需求得到正确的实现时，从需求工程师到架构师和开发人员，每个人都有责任记录它，了解它，为它设计，并实现它给编写测试用例和测试过程的测试人员。如果有人识别出不符合特定要求的模糊、冲突的需求或系统的某些方面，则该个人需要将其记录下来，并以某种方式报告它(通常通过报告bug跟踪器中的缺陷)。