是否有衡量代码重构的客观指标？
在重构前后运行 findbugs、CRAP 或 checkstyle 是否是检查代码是否真正得到改进而不是仅仅改变的有用方法？
我正在寻找可以确定和测试的指标，以帮助改进代码审查流程。
【问题讨论】：
标签： language-agnostic refactoring agile code-metrics
是的，有几个代码质量衡量标准可以告诉您重构是否提高了代码质量。
重复。 一般来说，重复越少越好。然而，我使用的重复查找器有时会识别出重复的块，这些重复块只是在结构上相似，但在语义上彼此无关，因此不应进行重复数据删除。准备好压制或忽略那些误报。
代码覆盖率。这是迄今为止我最喜欢的指标，但它只是与重构间接相关。您可以并且应该通过编写更多测试来提高低覆盖率，但这不是重构。但是，您应该在重构时监视代码覆盖率（与对代码的任何其他更改一样）以确保它不会下降。重构可以通过删除重复代码的未经测试的副本来提高代码覆盖率。
大小指标，例如代码行数、总数和每个类、方法、函数等。A Jeff Atwood post 列出了更多。如果重构在保持清晰度的同时减少了代码行数，那么质量就会提高。异常长的类、方法等很可能是重构的好目标。准备好使用判断来决定类、方法等何时确实需要比平时更长的时间才能完成其工作。
复杂度指标，例如圈复杂度。重构应该尽量降低复杂性，而不是在没有经过深思熟虑的理由的情况下增加复杂性。高复杂度的方法/函数是很好的重构目标。
Robert C. Martin 的 package-design 指标：抽象性、不稳定性以及与抽象性-不稳定性主序列的距离。他在his article on Stability in C++ Report 和他的书Agile Software Development, Principles, Patterns, and Practices 中描述了它们。 JDepend 是一种测量它们的工具。改进包设计的重构应该最小化 D.
我已经并继续使用所有这些来监控我的软件项目的质量。
【讨论】：
我从气味的角度来看问题。气味可以被视为质量问题的指标，因此，识别出的气味实例的数量可以揭示软件代码的质量。
气味可以根据其粒度和潜在影响进行分类。例如，可能有实现气味、设计气味和架构气味。您需要在之前和之后识别所有粒度级别的气味，以显示重构练习的收益。事实上，重构可以通过识别的气味来指导。
示例：
【讨论】：
重构有两个结果。您希望团队保持可持续的步伐，并且希望生产中的缺陷为零。
在测试驱动开发 (TDD) 期间对代码和单元测试构建进行重构。重构可以很小，并且可以在完成故事卡所需的一段代码上完成。或者，重构可能很大，需要一张技术故事卡来解决技术债务。故事卡可以放在产品待办列表中，并与业务合作伙伴一起确定优先级。
此外，当您像编写 TDD 一样编写单元测试时，随着代码的开发，您将继续重构测试。
请记住，在敏捷中，SCRUM 中定义的管理实践将为您提供协作，并确保您了解业务合作伙伴的需求，并且您开发的代码满足业务需求。但是，如果没有适当的工程实践（如极限编程所定义），您的项目将失去可持续的步伐。许多没有采用工程实践的敏捷项目需要救援。另一方面，一个纪律严明并采用管理和工程敏捷实践的团队能够无限期地维持交付。
因此，如果您的代码在发布时存在许多缺陷，或者您的团队失去了速度、重构和其他工程实践（TDD、配对、自动化测试、简单的进化设计等），则没有得到适当的使用。
【讨论】：
在重构前后运行 findbugs、CRAP 或 checkstyle 是否是检查代码是否真正得到改进而不是仅仅改变的有用方法？
实际上，正如我在问题 "What is the fascination with code metrics?" 中详述的那样，任何指标（findbugs、CRAP 等）的趋势都是指标的真正附加值。
它（指标的演变）允许您优先考虑您真正需要对代码进行的主要修复操作（而不是盲目地尝试尊重那里的每个指标）
像Sonar 这样的工具可以在这个领域（监控指标）非常有用。
Sal 在 cmets 中添加：
真正的问题是检查哪些代码更改会增加价值，而不仅仅是添加更改
为此，测试覆盖率非常重要，因为只有测试（单元测试，还有更大的“功能测试”）才能为您提供有效的答案。
但是无论如何，重构都不应该在没有明确目标的情况下进行。仅仅因为它“更优雅”甚至“更容易维护”而这样做可能本身并不是一个很好的理由足够来更改代码。
应该有其他措施，例如将在此过程中修复的一些错误，或者由于“重构”代码而实现更快的一些新功能。
简而言之，重构的附加价值不仅仅通过指标来衡量，还应该根据目标和/或里程碑进行评估。
【讨论】：
我会远离衡量重构成功的指标（除了#unit test failures == 0）。相反，我会选择代码审查。
找到明显的重构目标并不需要太多工作：“我以前没有见过完全相同的代码吗？”对于其余部分，您应该针对不该做的事情制定一定的指导方针，并确保您的开发人员了解它们。然后他们将能够找到其他开发人员没有遵循标准的地方。
对于更高级别的重构，更高级的开发人员和架构师将需要根据他们看到代码库移动的位置来查看代码。例如，今天的代码具有静态结构可能是完全合理的；但如果他们知道或怀疑需要更动态的结构，他们可能会建议使用工厂方法而不是使用 new，或者从类中提取接口，因为他们知道在下一个版本。
这些东西都不会从指标中受益。
【讨论】：
无论你做什么，只要确保这个指标不用于评估程序员的表现、决定晋升或类似的事情。
【讨论】：
代码大小。在不破坏功能的情况下减少它的任何东西都是我书中的改进（当然，删除 cmets 和缩短标识符不算数）
【讨论】：
根据您的具体目标，cyclomatic complexity 等指标可以提供成功的指标。最后，每个指标都可能被颠覆，因为它们无法捕捉情报和/或常识。
不过，一个健康的代码审查过程可能会产生奇迹。
【讨论】：
失败的单元测试数必须小于或等于零:)
【讨论】：