是否有衡量代码重构的客观指标？
在重构之前和之后运行findbugs，CRAP或checkstyle是检查代码是否实际改进而不仅仅是改变的有用方法吗？
我正在寻找可以捕获的趋势，这些趋势可以帮助我们改进代码审查流程，而不会浪费时间在简单的个人偏好上进行更改的代码。
答案 0 :(得分：5)
失败的单位测试次数必须小于或等于零：）
答案 1 :(得分：5)
根据您的具体目标，cyclomatic complexity等指标可以提供成功指标。最后，每个指标都可能被颠覆，因为它们无法捕获智能和/或常识。
健康的代码审核流程可能会产生奇迹。
答案 2 :(得分：4)
在重构之前和之后运行findbugs，CRAP或checkstyle是检查代码是否实际改进而不仅仅是改变的有用方法吗？
实际上，正如我在问题"What is the fascination with code metrics?"中详述的那样，任何指标的趋势（findbugs，CRAP，等等）都是指标的真正附加价值。
它（指标的演变）允许您优先排序您真正需要对代码进行的主要修复操作（而不是盲目地尝试尊重每个指标）
像Sonar这样的工具可以在此域（指标监控）中非常有用。
Sal在评论中补充道：
真正的问题是检查哪些代码更改会增加值而不仅仅是添加更改
为此，测试覆盖率非常重要，因为只有测试（单元测试，但更大的“功能测试”）才能给出有效答案。
但是，如果没有明确的目标，不应该进行重构。要做到这一点只是因为它“更优雅”或甚至“更容易维护”本身并不是一个很好的理由足够来改变代码。
应该有其他一些措施，例如一些将在过程中修复的错误，或者一些新功能，由于“重构”代码，它们将更快地实现。
简而言之，重构的附加价值不仅仅用指标衡量，还应根据目标和/或里程碑进行评估。
答案 3 :(得分：2)
代码大小。任何减少它而不破坏功能的东西都是我书中的改进（删除评论和缩短标识符当然不算数）
答案 4 :(得分：1)
无论你做什么，只要确保这个度量标准不用于评估程序员的表现，决定促销或类似的东西。
答案 5 :(得分：1)
我会远离衡量重构成功的指标（除了#unit test failures == 0）。相反，我会去代码审查。
找到明显的重构目标并不需要太多工作：“我之前没有看过完全相同的代码吗？”对于其他人，您应该针对不应该做的事情制定一些指导原则，并确保您的开发人员了解它们。然后，他们将能够找到其他开发人员不遵守标准的地方。
对于更高级别的重构，更高级的开发人员和架构师需要根据他们看到代码库移动的位置来查看代码。例如，代码今天具有静态结构可能是完全合理的;但是如果他们知道或怀疑需要更加动态的结构，他们可能会建议使用工厂方法而不是使用 new ，或者从类中提取接口，因为他们知道会有另一个实现下一个版本。
这些都不会从指标中受益。
答案 6 :(得分：1)
是的，代码质量的几种衡量标准可以告诉您重构是否会提高代码的质量。
重复。一般来说，重复次数越少越好。但是，我使用的复制查找器有时会识别仅在结构上相似但在语义上彼此无关的重复块，因此不应进行重复数据删除。准备好压制或忽略那些误报。
代码覆盖率。这是目前我最喜欢的指标，但它只是与重构间接相关。您可以而且应该通过编写更多测试来提高覆盖率，但这不是重构。但是，您应该在重构时监视代码覆盖率（与代码的任何其他更改一样），以确保它不会出现故障。重构可以通过删除未经测试的重复代码副本来改善代码覆盖率。
大小指标，例如代码行，总计和每个类，方法，函数等。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。
我已经使用并继续使用所有这些来监控我的软件项目的质量。
答案 7 :(得分：0)
重构需要两个结果。您希望团队保持可持续的步伐，并且您希望生产中没有任何缺陷。
在测试驱动开发（TDD）期间，对代码和单元测试构建进行重构。重构可以很小，并在完成故事卡所需的一段代码上完成。或者，重构可能很大，需要技术故事卡来解决技术债务问题。故事卡可以放在产品待办事项上，并与业务合作伙伴一起确定优先顺序。
此外，当您像编写TDD一样编写单元测试时，随着代码的开发，您将继续重构测试。
请记住，在敏捷方面，SCRUM中定义的管理实践将为您提供协作，并确保您了解业务合作伙伴的需求，并且您开发的代码符合业务需求。但是，如果没有适当的工程实践（由极限编程定义），您的项目将失去可持续的步伐。许多没有采用工程实践的敏捷项目需要救援。另一方面，一支训练有素且兼顾管理和工程敏捷实践的团队能够无限期地维持交付。
因此，如果您的代码发布时存在许多缺陷，或者您的团队失去速度，重构和其他工程实践（TDD，配对，自动化测试，简单的演化设计等），则无法正确使用。
答案 8 :(得分：0)
我从气味的角度来看问题。可以将气味视为质量问题的指标，因此，识别出的气味实例的量可以揭示软件代码质量。
可以根据其粒度及其潜在影响对气味进行分类。例如，可能存在实现气味，设计气味和建筑气味。您需要在之前和之后识别所有粒度级别的气味，以显示重构练习的收益。事实上，重构可以通过确定的气味来指导。
<强>示例：