通过静态分析与持续集成 保证代码的质量(PRQA).pdfVIP

通过静态分析和持续集成 保证代码的质量 Jason Masters October 2013 持续集成技术可确保在每次有增量变化的时候，开发团队中每个成员的代码都会被整合、构 建到源代码中，并且保证这些代码都经过了测试。进行持续交付的目的是保证代码一直处于 经过充分测试的状态，进而保证代码的质量，让产品随时可以发布。静态分析就是要保证代 码符合编码规范，并且没有程序错误，从而自动提高代码的质量。将这些方法和技术同时使 用，就能够提高代码的质量，降低开发成本，并增强项目的可预测性。 前言 现代软件开发团队面临着很多挑战，这些挑战包括：产品交付期限越来越紧，团队的分布越 来越广，软件的复杂度越来越高，而且对软件的质量要求越来越高。 本文分为两个章节。第一章讨论持续集成的原理，持续集成如何简化软件开发生命周期，以 及静态分析如何配合持续集成。第二章研究特定的工具套件，以及在实际使用中如何获得该 套件。主要研究Jenkins 持续集成和PRQA 的静态分析工具（QA•C, QA•C++ 和 QA•Verify ）， 并说明他们是怎样结合在一起使用，以及他们所生成的信息。 第一章 第一部分：持续集成和持续交付 持续集成（CI）和持续交付（CD）这两个术语常常一起使用。持续交付的最终目标是保证 版本控制系统存储库中的代码始终是经过检测和验证的。代码要通过所有必要的测试（编码 规范合规检查，单元测试，系统测试，代码覆盖率测试，验收测试，部署测试等）及所有的 验证环节。这样，产品的发布时间就不是由该项目的开发方或工程方决定了，而是由产品经 理决定。 在嵌入式领域，软件只是制成品的一个组件，所以保持软件始终处于可发布的状态好像并不 是十分紧要，但是通过本文可以看出，这样做的确会带来很大帮助。另外，现在的消费品中 常常带有需要用户购买之后自行更新的软件（笔者最近为了解决电视机的声音问题，对自己 购买的LCD 电视进行了更新），在这种情况下，保持软件始终处于可发布的状态就显得更加 紧要了。对于很多产品而言，软件是设备的附加价值的体现，而且为产品增加新功能也是一 种销售策略：可以经常性地为用户增加一些新功能，而不一定非要在传统的发布周期中才发 布新功能。 开发过程中的集成阶段往往比较困难/麻烦/伤脑筋，持续集成技术可使这一过程实现自动化， 从而帮助实现持续交付。 问题 传统的开发模式（比如：瀑布式开发、V 模式开发、较小程度的敏捷开发）由不同阶段组成。 最先对持续集成感兴趣的阶段是编码阶段，在该阶段，开发人员根据分派给自己的任务来编 写代码。随着开发的不断进行，开发人员很可能要对存储库进行修改，但是他们只是更新自 己开发的代码，不会同时更新其它开发人员的修改。所以，在所有的代码都开发完成之后， 会有一个特别的集成阶段，将所有开发人员对代码所作的修改进行整合，以形成一个可测试 的软件构建。 我们可以估算出该阶段的开始时间（根据对每项任务的判断进行估算），但是很难预测出截 止日期，也就是说很难知道完成集成工作需要花费多长时间。开发人员编写的代码可能会相 互冲突：每个开发人员编写的代码在独立运行时，也许能够运行得非常好，但是当该代码和 其他开发人员的代码结合在一起时，可能就会发现它不能与其它开发人员对代码所作的修改 相兼容。这种冲突必须要解决——通常情况下，这都需要手动解决（虽然也有工具可以帮忙）， 然后还必须重构代码。但是，代码重构过程中也可能会引进更多的矛盾，这样集成工作就会 陷入不断重复的状态。 集成是一项非常重要的工作，在极端情况下，解决冲突所耗的精力要远远超乎一开始编写代 码时所花费的精力。 这些可能出现的冲突和由此产生的工作量是开发人员不愿意更新存储库中的局部代码的原 因之一：更新可能会破坏现在可以正常运行的代码构建。有些问题可能是其他开发人员的代 码引起的，所以开发人员就不想花时间去解决这些由其他人的代码引进的问题。 有好多种解决代码冲突的方法。其中一种方法就是改善开发步骤：每次只允许一个开发人员 对存储库进行修改。对存储库中的代码进行更新之后，要立刻解决所有的新问题，这样开发 人员要做的就不仅仅只是提交代码那么简单了。这种方法可以避免冲突——但是代价很高。 开发人员在提交代码的时候，必须保证只有他一个人可以访问这个存储库：在该开发人员解 决好所有冲突之前，不能够有任何其它代码提交进来。（否则，所有的提交工作都要