静态代码分析方法

时间:2010-08-09 05:46:53

标签: code-analysis static-analysis

您将使用静态代码分析工具使用哪种方法?

您何时何地进行分析?多久一次?

如何在日常构建中将其集成到持续构建环境中?只是每晚?

3 个答案:

答案 0 :(得分:3)

如果我正在使用新的代码库,我会按照我想要的方式设置它们。如果我在现有代码库中使用它们,我会分阶段启用消息,以便报告特定类别的问题。清除特定类型的消息后,我添加下一个类别。

我将静态分析工具看作是编译器的一部分。每个开发人员在每次构建时都会运行它们。如果可能的话,我也会像处理编译器警告一样对待它们 - 作为错误。这样,带有警告的代码根本不会进入构建服务器。如果您在特定情况下无法关闭警告,则会出现问题......并且只能通过协议关闭警告。

答案 1 :(得分:3)

我的经验是,一般来说,静态分析应该在开发过程的早期使用,最好(或理想地)在单元测试和代码签入之前使用。静态分析的报告也可以在代码审查过程中使用。这使得软件开发人员能够开发健壮的代码,并且在某些情况下可以编写可以通过静态分析工具更准确地分析的代码。

早期使用的挑战是软件开发人员必须接受充分的培训才能使用静态分析工具,并能够有效地对获得的结果进行分类。这样,他们就可以采取具体步骤来提高软件的质量。否则,工具的使用会减少或标记的问题会被忽略,静态分析的使用会随着时间的推移而减少。

在实践中,大多数开发组织在开发过程的后期使用静态分析。在这些阶段,质量或测试工程师使用静态分析工具。在许多情况下,它与构建系统相结合,以产生质量指标,并提供有关软件安全性和可靠性的指导。但是,如果已识别的问题累积并跨越多个代码组件,则所有问题将被修复的可能性将降低。因此,一般来说,后期使用静态分析可能需要更多的时间和资源来解决已发现的问题。

答案 2 :(得分:0)

在检查服务器中的源代码之前,建立代码审查任务(其他开发人员的同行代码审查)以及使用静态分析工具也是一个好主意。因此,它有助于提高代码质量,防止无用的代码行有一天成为无用的遗留代码。