使用持续集成时，您在代码审查中寻找什么样的内容？似乎很多关于代码评论的文献都提到了编码风格，拼写错误，资源使用情况，错误处理等问题（可能不是这样的顺序:-)然而，像FxCop和StyleCop这样的工具似乎最能挑选出的微不足道的问题。代码评论与CI
我认为尽可能多的检查应该推入CI以节省时间并确保这些检查一致地完成。如果你采取这种方法，似乎在审查中寻找的主要内容是设计不佳，未能正确使用现有代码结构，可能在测试中错过的微妙缺陷等。
其他人在CI的地方进行评论？您在评论中还有哪些其他内容？
差不多，不管不能由机器自动测试（也许除了对于性能/安全问题，但它们对于人类来说更容易检测）。
在我的经验中，代码评论更多的是确保以最好的方式完成任务。通常审查的结果是一些重构。如果代码有点不礼貌，可能需要修正其他问题。像FxCop和ReSharper这样的产品可以提高代码质量。
代码审查的一个关键方面是确保所有的马都朝着相同的方向前进：即代码与团队哲学一致。在选项A或选项B合理但不应混合的情况下，有任何一些小的变化和辩论。例如单元测试getter/setters 100％的代码覆盖率，或使用构造函数与setter初始化的春天。我们可以辩论这些，但一旦确定下来，团队应该坚持一致的决定。
由于选择合理（或模糊），所以很难测试CI中的违规情况。通过评论来感受“同侪压力”要容易得多。
过去我已经有blogged on this关于某些细节：代码覆盖率，国际化和数据版本化。这些只是一些与团队哲学的一致性很重要的问题。
代码的可读性和未来的可维护性是一个很大的问题，从自动化解决方案中被遗漏。无证的副作用和对方法的要求急剧增加。称为changeX()的方法不会更改X，并且称为getFoo()的方法返回foo的值，并且还秘密地将7添加到对象的内部状态。
该代码提供了尽可能最佳的商业价值。此外，代码评审不仅仅针对已编写的代码，而且还有助于塑造将来编写的代码。使用目前可用的工具，我们过去寻找的许多工具已经（至少大部分）由时间代码致力于源代码控制。至少我认为这是应该完成的。详细说明这里是我之前就这个主题写过的东西的一小部分。
“。近年来，网络代码审查工具不断改进，取消了代码审查的一些传统必要性，但不是最有价值的方面。有像FxCop这样的静态分析工具可以自动查看所有代码确定性行业标准指南。有像微软最近发布的源代码分析（a.k.a. StyleCop）等源代码分析工具来检查所做的所有源代码样式选择。通过持续集成和TDD代码进行审查，以确保其构建并满足预期的业务场景。最近推出了像NDepend这样的产品来审查代码并提供统计信息，以帮助确定设计是否遵循导致可持续性的原则。所有这些类型的工具都增强了我们审查软件的生态系统。但是，他们都没有提供任何关于代码审查最关键方面的帮助 - “这个代码是否为业务领域提供了最佳价值？”这个问题的答案仅仅是因为代码通过FxCop，StyleCop在NDepend中看起来不错并通过自动化测试并不意味着它提供了最佳的商业价值。这些工具是无领域代码审查生态系统的一部分，他们对我们创建软件的任何业务或我们的代码为该域提供服务的程度没有任何洞察力。 “最佳价值”问题的答案在某种程度上是主观的，但最有能力提供答案的人是该领域的编码人员使用他们仅保留的隐性技术和商业知识。代码审查是应用和共享隐性知识，并找到答案的“最佳价值”问题的方式。” - TeamReview - New Business Value From Code Review
这一点，再加上（或许更重要的？）的测试覆盖率 – metao 2008-09-22 03:24:50