级别： 初级 Anthony (Joey) Bernal, 执行 IT 专家, SDI Corp.
2009 年 4 月 15 日 
无论您认为是功能还是风格才是软件开发方面的更重要元素，规程、效率和一致性始终是开发项目取得成功所必需的。静态分析，即检查应用程序源代码的任务，是您和您的团队可用于实现这些目标的一种方法。本文阐述静态分析的好处，以及要在静态分析工具中期待的重要特征。
来自 IBM WebSphere Developer Technical Journal。
这是艺术吗？
我们称之为软件工程，但同时我们通常坚持认为，软件解决方案包括的艺术方面与包括的科学方面一样多。如果事实的确是这样，那么我们这些从业人员尝试使用的头衔可能是软件艺术家 而不是软件工程师或软件架构师，尽管拥有此头衔的人是否会认真对待此事尚不清楚。我们作为架构师和工程师的目标是产生可靠、可正常工作的代码，这样的代码以可扩展和安全的方式提供所需的结果。我承认，存在使用艺术专业执照的偶然机会——例如，在设计用户界面的时候——但它仍然是功能的问题，而不是最终让用户感动或感到满足的风格问题。换句话说，虽然用户可能由于您的界面优美而喜欢它，但是如果该界面无法正常工作，用户将不会使用它。
几年前在从事某个项目的时候，我的朋友兼同事 Yixing Gong 发表意见说，我们的项目团队构建的每个组件都像是特定开发人员完成的单独作品——当时我们真正需要的是将工作转换到更像装配线的流程中：在更短的时间内制造出质量更好并且更加一致的 Portlet。即使我们起初所能构建的只是 Model T（福特公司的第一款量产车型，泛指很原始的东西），持续的改进终究会在某一天让我们推进到构建更加时髦和现代的东西。
该初始讨论和后续的许多其他项目的经验最终导致我们编写了有关 Portlet 建模的早期 developerWorks 文章集合，并成为了我今天与用户讨论的许多开发最佳实践的先驱。但是，我仍然在寻求更好的方法来运作项目，以及按时和在预算内交付可靠和可伸缩的应用程序。
从开发工作中删除“艺术”主要是出于规程方面的考虑，我认为规程是当今的许多开发团队中所缺少的东西。但是此规程的大部分必须来自于内部；也就是说，来自开发团队或其所在的组织，因为业务看重的是按时和在预算内完成项目，而不是有关如何完成具体事情的细节。如果业务（其支持并资助 IT 工作）没有要求对持续的工作进行独立审核和检查以强制项目规程，那么可能提供帮助的就是这样一组工具，它们使开发人员能够执行系统测量，就像其他类型的工程师测量他们的工作一样。
这样的“软件工程师的工具箱”将包括一组有用的重要组件，可以测量项目或解决方案的元素以实现一致和正确的结果。就像木匠的工具集包括卷尺和水平仪以确保橱柜的大小正确并且安装得当一样，也可以对软件测量类似的一致性。当然，不存在单个适用于所有开发人员和情境的工具箱，但是有一些基本的工具和功能是我们手边全都应该具备的。静态分析就是其中之一，并且是功能较为强大的工具之一。它似乎也是使用得最少的开发工具之一，因此通过列出静态分析的基础以及它何时可以提供帮助并适合于在您的组织或开发项目中使用，也许我可以在行业范围内推动项目规程的传播，并凭一己之力改进项目的质量和价值。（我可以有这样的梦想。）
静态分析
人们通常将静态分析 这个术语与软件中的自动化错误搜索的概念等同起来。虽然静态分析可以帮助查找许多类型的潜在问题，但它不是全方位的错误查找工具。事实上，仅只是执行简单的静态分析通常很难找出错误。当您的生产系统中有运行时错误时，情况尤其是如此。静态分析所做的工作就成为了催化剂，帮助您了解代码的总体质量，帮助您确定可能出现问题的指针，以及确定您可以执行其他分析的领域。
静态分析是检查应用程序源代码文件而不实际运行程序的任务。的确，可以对字节代码以及源代码文件执行静态分析，这可能意味着频繁地编译应用程序，具体取决于您要寻找什么内容以及您选择哪一种方法。就本文而言，我们主要将重点放在源代码检查上。
在我的研究中，我经常尝试新工具。我寻找那些具有最佳功能组合的工具，并且这些工具通常最流行。存在许多用于静态分析的开放源代码工具和商业化产品可用，您可以在 Wikipedia 上找到它们的列表。我不打算在这里全部描述它们，但是我想作为典型示例提及其中四个工具，以使您大致了解全功能的商业化选项和随时可用的开放源代码工具。可能要多个开放源代码工具组合起来才能比得上单个商业化产品的功能。这里列出的工具不是作为建议来提供的，但是它们在行业内众所周知，并且可以让您了解可用于执行自己的产品比较和功能分析的重要功能。
已经存在一些源代码分析与字节代码分析以及哪种分析提供更好结果的比较，但是该讨论超出了本文的范围。我要说的是，您的项目中使用的分析范围不应该受到所使用的分析方法的影响；换句话说，执行任一种类型的静态分析都比不执行静态分析更好。
-
FindBugs
Findbugs 是一个流行的开放源代码工具，它对 Java™ 字节代码执行静态分析以查找常见编程错误。可以将 Findbugs 作为 Ant 任务或作为 Maven Findbugs 插件包括在构建中。大多数构建系统都使用这其中一种方法，因此在系统中整合这个最基本的信息集是非常容易的。
与其他静态分析工具一样，FindBugs 使您可以在分析中内置新的规则。但是与其他某些工具不同，Findbugs 使用字节代码和字节代码工程库，因此学习如何在系统中实现新的规则可能是个挑战。
-
IBM Rational Application Developer
IBM®Rational® Application Developer V7 提供了带有数百个规则的内置错误检测和静态分析工具，这些规则具有相关清楚的描述。其中还包括了许多示例，示例中列出了许多错误和修复错误的方法。
IBM Rational Software Architect 添加了附加的规则，例如 Architectural Discovery for Java 和 UML Model Analysis。如果你们已经在团队中使用 Rational Application Developer，这可能是在项目或组织中实现反馈系统的第一步。附加的功能通过插件提供。
-
CodePro Analytix
Instantiations 推出的 CodePro Analytix 是一个商业化的产品，可作为独立产品或 Eclipse 插件使用。CodePro 带有大约 35 个类别的 900 多个规则，可以通过多种方式考虑您的代码，并为代码的不同方面生成单元测试。
作为商业化产品，CodePro 附带了附加的功能，包括在您编写代码时捕获错误的动态代码审核功能，可以帮助初学的程序员了解他们可能犯的错误，并了解用于修复问题的选项。
开发周期中的构建规程的另一个方面是了解和测量代码库中隐藏的许多度量。在测量为特定项目生成的工作量时，诸如代码行数和类数量等标准度量非常重要。虽然各项开发工作并非始终可以使用这样的一般统计信息进行评估，但是这些数字可用作建立基准的指导原则和用于项目估计目的。
一个有趣的 CodePro 功能是能够对项目的依赖项分析绘制图表。在尝试了解应用程序如何工作，以及确保在系统体系结构中遵循分层的方法时，我发现静态分析的这方面非常重要。
-
Parasoft Jtest
另一个商业化产品 Parasoft Jtest 中的静态分析功能在 35 以上的类别中包括 700 多个可参数化的规则。其静态分析功能分析源代码和字节代码，基于模式以及基于流和基于路径，并且能够跨方法、类和包查找违规行为。除了所有的规则以外，Quick Fix 选项使开发人员能够快速修复 Parasoft Jtest 动态找到的许多问题。RuleWizard 模块允许您在系统中快速构建自己的规则集，只需剪切和粘贴您希望标记的代码并让规则向导自动创建规则即可轻松完成。Parasoft Jtest 的基于流的分析称为 BugDetective，它静态地模拟应用程序执行路径，然后揭示这些路径中可能发生的运行时错误。
Parasoft Jtest 可以通过多种方式检查代码，并自动生成 Junit、Cactus 和 HttpUnit 测试用例，以便测试诸如访问和边界类型异常等问题。还可以将手动编写的测试用例整合到测试运行中，并且可以通过对工作应用程序运行您的用例来添加功能 Junit 测试用例。此外，Parasoft Jtest 可以生成回归测试套件，在代码修改影响现有功能时将向您发出警报。与其他商业化产品一样，Parasoft Jtest 还可以计算有关代码和开发过程的度量，以便您能够测量项目发展和进度，以及通过允许团队在 IDE 中集成代码检查来实现代码检查的自动化。
 |
|
超越工具
有时，您可能还需要分析工具所提供的功能以外的东西。例如，在执行静态代码检查的时候，我可能在文件范围搜索特定项的所有实例；例如，使用 HTTPSession 或 PortletSession 来存储某个内容的所有场合，这在许多应用程序中可能是个薄弱环节。简单地了解会话的访问次数，或者会话中存储有什么数据类型，这本身并不是非常有用。要使此信息有价值，我会与开发团队一起直接检查找到的每个实例，以确定正确的使用并提出问题，例如：
- 该结构中通常存储多少数据？
- 系统访问该数据的频率？
- 该数据是许多客户之间共有的，还是每个客户所特有的？
- 我们是否可以将公共数据移动到单独的缓存或层？
通过进行此类讨论，您可以更好地了解代码是否为采用一致的方式设计的。遗憾的是，这些类型的场景通常没有得到足够好的定义以提供潜在薄弱环节的完整列表。就检查人员而言，这主要是个人经验问题，但是随着行业的成熟，诸如此类的最佳实践将得到更好的定义。
归根结底，我们所描述的就是一般所称的代码检查，尽管它不需要像名称所暗示的那样严格。我很少在实践中看到代码检查，也许是因为许多项目负责人觉得不太精通代码而无法提出建设性的建议，或者是他们担心向开发团队暴露他们缺乏知识。如果您担心后者，下面是一个提示：开发团队也许已经知道了！克服此顾虑，通过积极参与并提出正确的问题来使您的项目更好吧！这是项目领导能力的核心。这第二层的价值应该非常明显，但是除此之外，您还更清楚地了解了应用程序结构和代码细节。开发团队是否在遵循您定义的体系结构模型呢？该模型是否足够清楚，或者是否存在应该如何构造事物的多种解释？
规程
这在很大程度上涉及到规程。当然，如果我们作为技术负责人都没有我们自己的规程，您就不能期望开发团队拥有规程。我在前面略微谈到了这一点，但我实际上是想要强调这一点。如果您没有在组织中适当地定义标准和约定，就不能期望开发团队遵循它们。规程从团队负责人确保在项目之初定义规则和标准开始。准备好所有工程师都必须遵循的标准和规范以后，检查可以确保项目仅在遵循了标准时才继续进行。这种一致性和规程可以促进交流，并同时给业务及其用户带来成功。
使任何事情顺利进行的关键是以某种方式对您的分析采取行动，以确保所有开发人员了解团队要共同达到的目的。静态分析检查的明显后续行动是执行手动代码检查，每个人都要在此过程中作为团队实际地查看代码，以发表意见，提出建议，或者甚至是了解有关应该如何构造良好代码的信息。
Dorota Huizinga 和 Adam Kolawa（Parasoft 的 CEO 兼共同创办人）编著的一本名为 Automated Defect Prevention 的新书精辟地阐述了帮助组织在软件开发过程中注入规程的正确方法。重申一下，静态分析不是修复即时问题（尽管它有时可以做到这一点），而是在组织和开发团队中内置一个流程和持续的改进。
经验
使用静态分析工具的团队经常做的事情之一就是启用所有的规则然后运行分析。这可能非常棘手，因为工具可能潜在地生成数百或数千个潜在错误，您不希望费劲地逐一查看这些错误。当前框架中需要一名有经验的开发人员帮助团队了解哪些规则是重要的。这并不是说某些规则（如格式设置规则）不重要，而是应该将它们与其他问题进行比较权衡，例如空指针或处理不当的异常。
就理解和维护代码库而言，格式设置和文档一致性是极其重要的，但是还务必要了解的是，如果一次启用的规则太多，对您的团队来说就越麻烦，因此在团队中简化新规则的整合和新标准的开发是正确的方法。对于后续的代码检查，您不需要重要的行家去领导该工作，尽管您的团队中可能有这样一位行家。手动检查是团队工作，其中使用讨论而不是个人的批评作为工具，并且不允许有经理的角色存在。这是每个人作为团队学习和成长的机会。而且始终要记住，要玩得开心！
总结
开始静态分析不只是购买一个工具并将其添加到环境中。或者是这样吗？如果您能够承诺执行该简单步骤，就会对在流程中注入适当数量的规程大有裨益。关键是您如何处理任何此类分析的结果，以及在该过程中运行的分析的一致性如何。在投入使用前的单次正确运行也许不足以提供帮助，但是每周的运行后面跟着团队讨论可以帮助将项目推进到下一个级别，并提供相对于检查工作所花的时间来说物超所值的价值。我们没有时间检查代码 是老生常谈了，但是事实和经验向我们表明，花时间在流程中注入某些规程将会在项目后期节省更多的时间，并提高所有开发人员的才干和项目的质量。
我建议马上花时间考虑正确的产品组合并在项目中内置一些静态分析。分小步走是让静态分析在环境中正常工作起来和用于开发流程的方法。回报可能不会立即体现出来，但是长期而言，您将在组织中看到超过您想象的更强大可交付内容集和更多的规程。
参考资料
关于作者 | 
| | Anthony (Joey) Bernal 是 IBM Software Services for Lotus 的一名执行 IT 专家，并且是 WebSphere Portal Practice 的成员。他在门户和 Web 应用程序设计和开发方面拥有广泛的背景。他是多部图书的作者和合著者，包括 Application Architecture for WebSphere、Programming Portlets 2nd Edition、Programming Portlets、IBM Portal Solutions Guide for Practitioners，以及早先的 Professional Site Server 3.0。他还为他非常受欢迎的 Blog Portal in Action 撰写文章。 |
对本文的评价
| 
