改进旧代码质量的日常挑战

我相信代码质量工具应该集成到代码审查过程中，并且提交到项目中的所有代码都应该通过这些工具设置的标准。本文将定义我所说的代码质量工具，并讨论团队在将其用作代码审查过程的一部分时面临的挑战。

这里我将至少指定三种类型的工具

1. 风格强制执行工具

2. 静态分析工具

3. 重复代码查找器

CQT 类型	Visual Studio / C#	Eclipse / Java 参见 http://www.ibm.com/developerworks/java/library/j-ap01117/
风格强制执行	StyleCop http://blogs.msdn.com/sourceanalysis/	CheckStyle http://eclipse-cs.sourceforge.net/ 或 Eclipse 内置的 Java 代码风格选项。
静态分析	FxCop http://blogs.msdn.com/fxcop/	PMD http://pmd.sourceforge.net/ FindBugs http://findbugs.sourceforge.net/
重复代码查找器	DuplicateFinder http://www.codeplex.com/DuplicateFinder	CPD (PMD 的一部分)

在本文的其余部分，我将讨论风格标准。但是，完全相同的论点也适用于团队在标准化静态分析工具或调用重复代码段的工具时。（我很想找到一个与 Visual Studio 集成的免费重复代码查找器工具，但目前还没有找到。DuplicateFinder 声称与 MSBuild 集成。）

风格标准的优缺点

当您的团队标准化一组代码风格规则时，它消除了代码审查过程中关于编码风格和约定的无意义争论。 然后，代码审查可以更侧重于正确性、可维护性、性能、设计等方面的高级问题。 此外，拥有整个代码库通用的可预测风格可以提高任何必须阅读代码的人的整体可读性。

团队内部对于使用最佳风格约定总会有不同的意见，并且很少有人会 100% 同意该标准。 因此，遵守是一个“来自高层的诫命”是必要的。 在编写有效代码时，关于这条规则或那条规则是否有意义的争论会浪费时间。 也就是说，总会有一些特殊情况，遵循该工具带来的麻烦会比其价值更大。 这是可以接受的。 向标准工具的作者提交一个错误报告，然后继续前进。

问题

考虑一个常见的情况，即存在一个现有代码库，并且一个善意的开发人员说服了他的团队负责人，应该根据我们命名的工具 ClearStyle 来标准化代码风格。 ClearStyle 有插件，可以将其与所有不同团队成员喜欢的 IDE 和文本编辑器集成。 此外，它可以与团队的构建系统很好地集成，以便对以“偏差”风格编写的代码发出警告。

代码量太大，而待处理的功能工作太重要，无法让任何人一次性将所有代码都符合 ClearStyle 标准。 必须找到一个商定的策略，以逐渐使代码符合正在发生代码更改的文件。

我们团队的一名成员，我们称她为凯蒂，正在修复分配给她的 Bug X。为了便于讨论，该修复程序在一个开发分支中，涉及一个代码文件 ComplicatedLogic.cs，该文件严重不符合 ClearStyle 标准。她有几个选项

1. 随您的错误修复一起将 ComplicatedLogic.cs 转换为合规状态。她的审查者会抱怨他们无法轻易地将错误修复与所有与风格相关的更改区分开来，这使得代码审查过于困难。

2. 在问题跟踪系统中提交一个工作项，表明需要使特定文件符合标准，然后

a. 先进行风格修复，在进行错误修复的更改之前进行审查和签入，或者

b. 通过在不进行风格更改的情况下处理它来优先处理她的错误修复。 希望她或其他人实际上会修复“风格错误”，而不是在很短的时间内将其解决为“不修复”。

当然，对于仅用于发布热修复等的分支，我不建议您担心风格问题。 在这种情况下，错误修复本身显然具有最高的优先级。

我很想听听关于其他团队如何解决这个问题的评论。 还有我没有想到的其他选择吗？ 我听说在 Google，他们非常重视风格标准，但我还没有听说他们的流程的详细信息。

历史

2009 年 6 月 7 日 原始帖子，从 http://ars-excellentia.vox.com/ 交叉发布