使用持续集成时，我们在代码审查中需要什么样的东西？似乎很多关于代码审查的文献都提到了诸如编码风格，拼写错误，资源使用，错误处理等问题(也许不按此顺序：-)，但是FxCop和StyleCop之类的工具似乎使用最多。琐碎的问题。

我认为应将尽可能多的检查放入CI中，以节省时间并确保这些检查始终如一地进行。如果我们采用这种方法，那么似乎在审查中要寻找的主要内容是诸如不良的设计，无法正确使用现有代码结构，测试中可能遗漏的细微缺陷等。

其他所有人如何使用CI进行评论？我们还会在评论中寻找什么？

解决方案

• 安全问题
• 性能问题
• GUI的可用性
• 易性
• 好评论

几乎，任何机器无法自动测试的东西(也许除了性能/安全性问题外，但人类更容易检测到它们)。

根据我的经验，代码审查更多地是关于确保事情以最好的方式完成。通常，审查的结果将是一些重构。如果代码有点晦涩难懂，则可能需要修复其他问题。诸如FxCop和ReSharper之类的产品可以极大地帮助提高代码质量。

代码审查的一个关键方面是确保所有人员都朝着同一方向发展：即，代码与团队理念保持一致。在方案A或者方案B合理但不应混为一谈的情况下，有许多小的变化和争论。例如对100％的代码覆盖率进行单元测试getter / setter，或者对Spring使用构造函数与setter初始化。我们可以辩论这些问题，但是一旦解决，团队就应该真正坚持一致的决定。

由于选择是合理的(或者模糊的)，因此很难测试CI中的违规情况。通过评论获得"同伴压力"的感觉要容易得多。

过去，我就某些细节进行过博客撰写：代码覆盖率，国际化和数据版本控制。这些只是与团队哲学保持一致很重要的一些问题。

代码的可读性和未来的可维护性是一个巨大的问题，自动化解决方案会忽略它。未记录的副作用和对方法的要求急剧增加。名为changeX()的方法不会更改X，而名为getFoo()的方法将返回foo的值，并且还秘密地将7加到对象的内部状态。

该代码正在提供最大的业务价值。另外，代码审查不仅是针对已编写的代码，还有助于塑造将来将要编写的代码。如今，借助这些可用的工具，我们将要查找的大部分内容(至少是大多数情况)在将代码提交到源代码控制时已经得到了照顾。我认为至少应该这样做。详细说明一下，这是我之前写过的关于此主题的片段。

" .Net代码审查工具近年来得到了改进，并消除了一些传统的代码审查必要性，但并不是最有价值的方面。FxCop等静态分析工具可以自动审查所有代码确定性的行业标准指南。有一些源代码分析工具，例如Microsoft最近发布的Source Analysis(又称StyleCop)，用于审查所做的所有源代码样式选择；使用Continuous Integration和TDD代码进行审查，以确保其构建并满足预期的业务场景。最近推出以审查代码并提供统计信息，以帮助确定设计是否遵循了导致可持续性的原则。所有这些类型的工具都增强了我们审查软件的生态系统。代码的最关键方面审查问题的答案，该代码是否为业务领域提供了最佳价值?？仅仅因为代码通过FxCop，StyleCop，在NDepend中看起来不错并且通过自动化测试并不意味着它提供了最佳的业务价值。这些工具是无域代码审查生态系统的一部分，它们对我们为之创建软件的任何业务或者我们的代码在该域中的服务水平都没有任何见识。最佳价值问题的答案在某些方面是主观的，但是最有能力提供答案的人是该领域的编码人员，他们使用仅保留的默认技术和业务知识。代码审查是应用和共享这些隐性知识并找到最佳价值问题答案的方法。" TeamReview来自代码审查的新业务价值