衡量成功重构的指标[已关闭]

在重构之前和之后运行findbugs、crap或checkstyle是否是检查代码是否确实得到了改进而不仅仅是更改的一种有用方法?

事实上,正如我在问题中详述的那样 "What is the fascination with code metrics?" , the 趋势 在任何指标(findbugs、crap、随便什么)中,都是指标的真正附加值。
它(度量的演进)允许您 优先次序 您真正需要对代码执行的主要修复操作(而不是盲目地尝试尊重现有的每个度量标准)

像工具一样 Sonar 可以,在这个领域(监控度量)是非常有用的。

萨尔在评论中补充道:

真正的问题是检查哪些代码更改会增加值,而不仅仅是添加更改

因此,测试覆盖率非常重要,因为只有测试(单元测试,也就是更大的“功能测试”)才能给出有效的答案。
但是,如果没有明确的目标,就不应该进行重构。仅仅因为它“更优雅”甚至“更容易维护”而这样做本身可能不是一个好理由。 足够地 更改代码。
应该有其他的措施,比如一些将在流程中修复的错误,或者一些由于“重构”代码而实现得更快的新函数。
简而言之,重构的附加值不仅是用度量来衡量的,而且还应该根据目标和/或里程碑来评估。

失败的UnitTests数必须小于或等于零:)

根据您的具体目标,指标如下 cyclomatic complexity 可以提供成功的指标。最后,每一个指标都可以被颠覆,因为它们不能捕获智能和/或常识。

但是,一个健康的代码审查过程可能会产生奇迹。

代码大小。任何能在不破坏功能的情况下减少它的东西都是我书中的一个改进(当然,删除注释和缩短标识符也不算数)

无论您做什么,只要确保这个度量标准不用于评估程序员的性能、决定提升或类似的任何事情。

我将远离度量重构成功的度量标准(除了单元测试失败==0)。相反,我会使用代码审查。

找到重构的明显目标并不需要很多工作:“我以前没见过完全相同的代码吗?”对于其余的,您应该围绕不应该做的事情创建一些指导原则,并确保您的开发人员了解它们。然后他们就可以找到其他开发人员不遵守标准的地方。

对于更高级别的重构,更高级的开发人员和架构师将需要根据代码库移动的位置来查看代码。例如,代码现在拥有静态结构可能是完全合理的;但是如果他们知道或怀疑需要更动态的结构,他们可能建议使用工厂方法而不是使用 新的 或者从类中提取接口,因为他们知道在下一个版本中将有另一个实现。

这些都不会从度量标准中受益。

是的,一些代码质量度量可以告诉您重构是否提高了代码的质量。

• 重复。 一般来说,减少重复会更好。但是,我使用的重复查找器有时会识别出结构上类似但在语义上与另一个块没有任何关系的重复块,因此不应消除重复。准备好压制或忽视那些误报。

• 代码覆盖率。 一般来说,这是我最喜欢的度量标准,但它只是与重构间接相关。您可以并且应该通过编写更多的测试来提高低覆盖率,但这不是重构。但是,您应该在重构时监视代码覆盖率(与对代码的任何其他更改一样),以确保代码覆盖率不会下降。重构可以通过删除重复代码的未测试副本来提高代码覆盖率。

• 尺寸度量 例如代码行、总计和每类、方法、函数等。 A Jeff Atwood post 列出更多。如果重构在保持清晰的同时减少了代码行数,那么质量就会提高。异常长的类、方法等可能是重构的好目标。准备好用判断来决定一个类、方法等何时真的需要比平时更长的时间来完成它的工作。

• 复杂性指标 例如圈复杂度。重构应该尽量减少复杂性,而不是在没有经过深思熟虑的原因的情况下增加复杂性。高复杂度的方法/函数是很好的重构目标。

• 罗伯特·C·马丁的 package-design 韵律学 :抽象、不稳定和与抽象不稳定主序列的距离。他用 his article on Stability in C++ Report 他的书 Agile Software Development, Principles, Patterns, and Practices . JDepend 是一种测量它们的工具。改进包设计的重构应该最小化d。

我已经使用并继续使用所有这些工具来监控我的软件项目的质量。

重构有两个结果。你希望团队保持可持续的步伐,你希望在生产中零缺陷。

重构发生在测试驱动开发(TDD)期间的代码和单元测试构建上。重构可以很小,并且可以在完成故事卡片所需的代码上完成。或者,重构可能很大,需要一个技术故事卡来解决技术债务。故事卡可以放在产品积压工作上,并与业务合作伙伴进行优先级排序。

此外,当您像编写TDD一样编写单元测试时,您将在开发代码时继续重构测试。

记住,在敏捷中,Scrum中定义的管理实践将为您提供协作,并确保您了解业务合作伙伴的需求,以及您开发的代码满足业务需求。然而,如果没有适当的工程实践(由极限编程定义),您的项目将失去可持续的步伐。许多不采用工程实践的敏捷项目需要救援。另一方面,一个训练有素、同时采用管理和工程敏捷实践的团队能够无限期地维持交付。

因此,如果您的代码发布时有许多缺陷,或者您的团队放松了速度、重构,以及其他工程实践(TDD、裁剪、自动化测试、简单的进化设计等),那么这些都没有被正确地使用。

我从嗅觉的角度看这个问题。气味可以作为质量问题的指示器,因此,识别出的气味实例的数量可以揭示软件代码的质量。

气味可以根据其粒度和潜在影响进行分类。例如,可能存在实现气味、设计气味和架构气味。您需要在重构之前和之后识别所有粒度级别的气味,以显示重构操作的收益。事实上,重构可以通过识别出的气味来指导。

实例:

• 实现气味: 长方法、复杂条件、缺少默认大小写、复杂方法、长语句和幻数。
• 设计气味: 多面抽象、缺失抽象、封装不足、未利用封装、类集线器模块化、循环依赖模块化、宽层次结构和破碎层次结构。有关设计气味的更多信息,请参见 book .
• 建筑气味: 缺少层、包中的循环依赖、违反层、不明确的接口和分散的寄生功能。查找有关建筑气味的更多信息 here .