tfs - TFS 中的代码审查

Question

我是 TFS 配置的新手。

目前我们的项目已完成 50%，但我们发现我们的代码非常糟糕。我们考虑了对静态代码分析(如 Resharper)或其他产品(如 StyleCop、CodeAnalysis 和 FxCop)的需求。

我们希望将 TFS 配置为在 checkin 包含触发代码分析警告的代码时拒绝 checkin 。

但对于之前的代码，我们希望抑制现有的警告，以防止代码变得比现在更糟。

Answer 1

正如 Ivan 所提到的，您的根本原因不是缺乏分析工具，而是可能在于开发团队与其项目发起人之间商定的(或当前在团队成员之间强制执行的)质量和严格程度。可能是团队压力太大，导致重要的评审 Action 被跳过，或者是团队(或发起人!)对质量的渴望与你或发起人不一样。或者团队没有适当的知识水平来防止这些问题的发生。

解决此问题的最佳方法是在短时间内尽可能多地修复。

Warning: I've experienced with a number of teams the effect of turning on too many rules all at once. Generally, there is a reluctance for people to concede that their work hasn't been up to par and turning on rules that do not directly cause bug ("The identifier is cased incorrectly" for example) can cause frustration that can severely hamper your momentum. Carefully selecting which rules need to be solved now and which can wait for later worked much better in my experience. Once the team has developed a way to solve these kinds of problem, you can easily apply more.

打开类似 configuring Code Analysis for your solution 的工具或使用 Resharper 的解决方案范围分析功能，可以帮助您发现问题，但它不会解决问题或防止类似问题在未来突然出现，除非您的团队停止创建它们。

Tip: Note that you can turn on Resharper during your build as well using the Resharper CLI features.

StyleCop 如果代码本身糟糕到足以触发可能存在错误和问题的大量警告，我不会(目前)对这个团队强制执行。先解决这些问题，再把代码弄得漂亮一些。您现在的首要任务是消除任何可能的错误。

CodeAnalysis 和 FxCop 是相同的东西，因此您不需要同时启用两者。像 Resharper 这样的工具可以帮助您的开发人员通过使用魔术键 ALT+ENTER 快速消除许多问题。

如果您想创建一个干净的基线，您可以运行一次代码分析，然后选择生成的所有警告，然后选择在全局抑制文件中抑制。这将适用于代码分析问题，但不会抑制任何编译器警告，没有简单的方法可以快速抑制所有当前编译器警告。

Tip: It sometimes helps to temporarily rename any existing globalsupressions.cs files, so that this "baseline" is stored separately. You then know which warnings you'll have to fix at a later point in time.

Tip: When a developer suppresses a warning, have them add a Justification="Reason for suppression" to the suppression that is generated, that way you can distinguish between carefully considered suppression and temporary ones.

根据您是否已经拥有构建服务器，您的下一步是 install Team Build一旦你有了构建服务器，你就需要 setup a Build Definition .这blog post covers most of the steps .

在构建定义中，将触发器设置为“Gated Checkin”，并确保在“Process”选项卡上将“Code Analysis”设置为“Always”。 If you want to fail your build based on Code Analysis errors, you need to create a custom ruleset and configure that for your solution .

要使编译器错误导致构建失败，您还可以启用“将警告视为错误”

启用门控 checkin 构建后，将提示所有开发人员更改以等待他们的构建完成。 You can turn on alerts (using Web access) or use the Build Notification Tool to get notified when the changes were successfully submitted .

Tip: Instead of turning on all rules at once (or switching them all to cause an ERROR during builds) you can also opt to turn on rules a couple at a time and fix them. Turning on rules by category gives you a nice opportunity to teach people the importance of the rules being turned on and possible solutions for fixing them.

一个更高级的解决方案是在您的 Team Build 环境中安装和配置 SonarQube。 The ALM Rangers and Sonar have recently worked together to create installation guidance and a number of extensions to enable Team Build and SonarQube integration .你可以find the installation guide here .