“现在的软件开发过程中40%至50%的时间都花在了可避免的返工上。”

          B.Boehm，V.R.Basili《软件缺陷预防Top10》 IEEE Computer，2001年1月

    自从软件诞生之日起，其开发工作就一直是一项创造性的工作。很多开发者将这项工作视为一种艺术，因此软件开发者就像艺术家一样自豪。尽管如此，创造性的工作的效率一般都是比较低的。当然软件开发工作也不例外，正如上面引用的B.Boehm和V.R.Basili的评论一样。

    软件业作为一种产业，很多团队管理者都希望将其过程变得更有效率并且更加可预测。但是他们同时也担心采取这样的措施后会降低开发团队的创造性，这对软件项目而言是至关重要的。

    幸运的是，效率与创造性在软件开发过程中是可以和平共存的。自动化工具完成了软件开发过程中的大量繁琐且无需人力协助的工作，开发者可以更加注重于他们中意的创造性的工作。并且在更短的时间里开发出质量更好的软件。本文介绍了五个业界标准的最佳实践以及它们是如何帮助团队减少开发过程中可避免的资源浪费以及如何让开发者在不向效率妥协的前提下满足各种商业需求。

软件质量与开发效率的博弈

    使人感到惊奇的是，最快的开发流程事实上也是缺陷消除率非常的高开发流程。下面的图表来源于Capers Jones的《软件评估：效率以质量并重》第二版（McGraw-Hill，1996）一书，仔细观察这一图表：

    上述图表是在对业界软件开发过程进行大量统计后绘制出的，给出了软件总的开发时间和软件发布前缺陷修复百分比之间的关系。从图表中可以明显地看出从0到95%的缺陷修复率这个区间内，软件的开发时间是单调递减的，当缺陷修复率朝着100%逼近时，其需要的开发时间急剧上升。

    这一发现与主流认识截然相反，开发质量更高的软件并不比质量低（缺陷更多）的耗费更多的时间。反而，当软件的发布前缺陷修复率在95%左右时，其开发周期是最优化的，而这样的软件质量也已经是相当好的了。这一观点表明开发效率与软件性能是可以兼顾的。

    当然，使软件缺陷更少其表现出的质量也就更高，但是，其相应的开发时间会急剧地增加。

上述发现的两个要点是：

l  软件缺陷不会“自动”消除。这需要开发团队主动地引入正确的编码实践以及一些工具。

l  大多数开发团队都没有处于图表中的最佳位置。这意味着他们不但可以进一步提升其代码的质量，同时还能降低其开发成本。

一个典型的资源浪费的例子

    向图表中的最佳位置逼近的第一步就是查找出开发团队能够并且应该避免的资源浪费。显然，软件开发过程中的某些资源耗费是无法避免的。例如，一些基础研究工作、为了开发软件而开发的一些副产物、创建软件模型等。

    而可避免的资源浪费也是非常明显的。可以概括为：

l  由于某些团队成员在修改了代码后并没有对其进行编译，因此需要花费大量的时间来查找原因并且对其进行修复。浪费在这上面的时间比绝大多数项目经理想象中的要多得多。

l  耗费在人工追踪内存缺陷上的大量时间。这对C/C++代码而言尤为频繁。

l  由于开发成员的粗心，可能在代码中某处忘记了加上反括号“）”，将耗费数周的时间来调试并查找原因。这看上去是不可思议的，但是当由这个原因而影响了软件的功能的时候，开发者不得不反向来查找这些错误，这是极有可能发生的。

l  由于变量的命名规则表意性不好，往往导致开发者不得不花费大量的时间来弄清楚某个变量到底代表着什么。

l  开发过程中疏忽了边界条件（corner case conditions），导致团队的开发和需求的不符。

    上面的这些情况都有一个共同的原因：很多资源浪费都来源于缺陷的延后发现或者有时甚至没有发现缺陷。这适用于一切缺陷，包括需求缺失、缺少对未预见用户误操作的错误检测机制或者编码结构上的问题。

减少资源浪费的动机

    减少团队资源浪费的最主要的一个好处就是这能使团队的开发流程处于最优化位置，花费更少的时间完成质量更高的代码。查看前些部分提供的那个“软件开发时间与发布前缺陷修复百分比关系”的图表，处于其中最佳位置的开发团队通过对缺陷的早期发现，大幅地降低了开发资源的浪费。所以，在降低开发成本的同时，他们也设计出了质量更高的软件。

    减少团队资源浪费的另一个明显好处就是它能延长团队成员的职业周期。减少开发者花在修复缺陷（非创造性的工作）上的时间往往能够提升他们从工作中获得的满足感，同时使他们能够更加注重于其更加乐于进行的创造性的工作。

抑制开发资源浪费的五种对策

    在Parasoft，我们经验很好的证明了Boehm和Basili在《软件缺陷预防Top10》中所列出的很多建议。事实上，Parasoft产品中引入的最佳实践基本上都出自于这10条建议。我们将该书中列出的建议做了进一步的简化，使用户在使用的时候变得更加简单且方便。我们给出的抑制开发资源浪费的五种对策是：

l  鲁棒的开发框架

l  团队编码的一致性

l  一致的同行代码走查

l  早期测试

l  自动化回归测试

    最终也是最重要的一点，如果想要系统化地抑制开发资源的浪费，开发团队还需要一个报告机制，这种报告机制应该能让开发团队定性地跟踪上述五种最佳编码建议的实现情况。

上述的对策将在下述章节中具体论述。

1. 鲁棒的开发框架

    一个鲁棒的开发框架能够自动地完成开发过程中重复且繁琐的工作，管理项目的进行并且为支持项目经理作出正确的决策自动无缝地收集项目的各种数据。最重要的是，这种框架能维护且促进用户定义的开发流程。

下图为鲁棒的开发框架的图解：

鲁棒的开发框架包括下列的一些组件：

l  源码控制系统：源码控制系统为团队成员存访团队的完整代码库提供一个集中管理机制。它为团队成员在其工作站上编写、修改以及重构其代码提供一个安全保证机制，并且同时给予开发者足够的自由度。源码库是日常自动构建的前提。因此，由于构建的所有代码都应该存放于源码控制系统中，包括构建文件、脚本等，而不仅仅是用以构建的代码。

l  夜间构建系统（Nightly Build System）：夜间构建系统定期地自动构建应用程序，对源码控制系统中的代码进行编译并链接，而这些都是不需要人为干涉定时地进行的。这种自动的构建系统被用来创建一个可重复且可持续的构建流程，从而避免错误的库引用以及使用版本过期的代码等方面的错误。如果没有夜间构建系统，开发过程很有可能会变得无法控制并且会对开发资源造成浪费。

l  需求管理系统（和／或缺陷追踪系统）：这是一个用来存放并跟踪代码中的缺陷和存在的问题以及开发者相应的修改意见的库。缺陷被存放起来以便于对其进行跟踪、分析以及防止其重复发生。该系统还能用来存放功能需求以及跟踪与需求的变更。概括地说，这是一个用来存放并管理与软件开发相关信息的库。

l  回归测试系统：回归测试系统是能够定期对完整代码库自动运行既有测试套件的任意工具或任意工具的组合。例如，回归测试系统可以是用以运行一个或多个测试套件的脚本，也可以是以批处理方式运行的一种缺陷预防技术。无论是哪一种，其目的都是当代码修改引起了未预见的错误时能够及时地将其发现，尤其是由于某个开发者在不清楚代码模块间相关性的前提下，修改或添加对原本功能正常的代码造成的错误。

l  其它的一些工具：这可能包括静态代码分析工具、自动代码走查工具、性能评估工具、内存分析工具以及覆盖率分析工具等一切在团队资源允许的情况下提升团队开发效率的工具。

l  报告系统：这个系统应该能从上述所有模块（源码控制系统、夜间构建系统以及回归测试工具等）中收集数据，并且提供一个可视化的报告供团队分析项目状态以及趋势。

 基本构建框架

    鲁棒的开发框架同时还需要一个高效的构建框架。在不牵扯到复杂情景的情况下（现在的构建系统以及分布开发的情况可能会非常的复杂），基本构建框架可由开发平台上的代码存放系统、开发者沙箱（sandbox）以及各开发者的独立构建系统中的沙箱组成。下列图表演示了一个基本构建框架的构成：

    沙箱是某台特定本地机器上的可用代码的一个快照。对沙箱的相应设置有以下两个关键

步骤：

l  如果不能在本地主机上构建整个应用程序，开发者应至少保证在其本地主机上构建沙箱。这能避免在修改代码时的构建错误。

l  项目的整体构建应该在独立于所有开发者的机器上独立地运行。这能保证开发者的本地设置不会影响团队的项目整体构建属性，从而影响团队整体构建过程。

    这种构建过程最好在夜间执行。这样能确保出现的任何问题能够在第二天及时地被发现（而不是数周或更长的时间后）。尽管如此，确定其具体运行周期的关键还是应该根据开发团队的具体需求来定。除非让这种定期构建过程自动的运行，否则软件的开发周期将会被大幅地延长。

２.团队编码的一致性

    下述的一些最佳实践可能会随着团队的不同或具体的开发者的不同而不同，但是遵循这些最佳实践能够显著地提高开发效率。这些最佳实践是：

l  编码策略及标准：编码策略及标准一般是基于团队的开发经验，专家建议或者合同约定（如很多嵌入式项目需要符合MISRA标准）构成。这些策略不必非常精细，但是必须能够保证一致实施后能解决大多数编码问题。

l  最佳实践与低级失误：能确保不犯低级失误的软件开发者可以说是凤毛麟角。这些失误往往不是由于开发者知识储备、经验或训练不够造成的，而是由墨菲定理既疲劳分心等人为不能控制的因素造成的。因此，最好用自动化代码分析工具来进行检查，从而使代码检查过程更快且更深入。

l  自定义检查与查找到的缺陷：一个总体上的最佳实践就是保证同样的错误不会重复产生。错误虽然因人而异，但是很多错误都是可以被概括出来并且通过自定义准则或自定义检查模块发现的。

l  检查与数据以及数据流相关的错误：在特定的边界条件中，经常发生一些诡异的错误，比如边界条件决定于程序输入数据和执行状态并且往往人工测试不能发现这些问题。新一代的静态代码分析工具能非常深入地查找错误（如潜在资源泄漏、由指针使用不当造成的错误或者数组溢出相关的错误），并且不需要运行源代码。

    高效的策略增强的关键就是为团队制定出一个编码指南。而增强这些指南的最高效的方法就是使用诸如Parasoft. Jtest.（针对Java）、C++test.（针对C/C++）以及.Test.（针对Microsoft .NET语言）等代码分析工具来自动地检查代码的兼容性。自动化代码分析工具能为开发团队节省大量的时间，减少对以检查过的代码修改的必要并且为流程报告提供可靠的数据源。

解决方案：利用Parasoft C++test来促进团队的编码一致性

    为了理解这些最佳实践如何被自动地实施，我们用Parasoft C++test来做示范以演示这一过程。C++test可以作为Eclipse的独立工具或Eclipse、Wind River Workbench及Microsoft Visual Studio的插件来使用。在这个例子中，我们用Eclipse-based版本来做演示。

    为了将C++test进行正确的配置来增强编码标准策略以适应团队的特殊需要，用户可以通过内建的及自定义规则（通过一个图形化的规则编辑器）对团队编码规则进行定义。借助Parasoft Team Configuration Manager（TCM）工具，这些配置能够通过网络被方便地在团队范围内进行部署。

    当进行某一特定的代码分析时，C++test能查找出其编码结构性的错误，诸如类型转换错误导致的潜在溢出。这很有可能是由对变量赋值不兼容造成的。例如，下面的C++test截屏表现出了C++test是如何识别get_input_digit_function的函数返回值对无符号整数（unsigned int）进行赋值的。

    使用不同的分析，C++test还能查找出数据流及数据相关的错误，诸如潜在内存泄漏（用作错误处理的if分支语句）等。从而通过分析跨越多个函数的路径，C++test能查找出该内存泄漏错误是源于add_timer_record函数中的错误条件。

    在上述情况中，对错误的分析结果都显示在用户的IDE中以方便用户查看。每个有问题的代码处都被报告出来；双击这些错误元素能够打开一个显示相应代码的窗口供用户查看及编辑。

３.一致的同行代码走查

    代码走查是查找缺陷及预防次优（suboptimal）软件的最有效的技术。代码走查需要用到人工智能这一强有力的分析工具。研究表明最高90%的代码错误能够被人工检查消除，其平均值也在60%左右。作为一个规则，代码走查有必要对所有的新建代码及关键代码进行检查以确保这些代码中的问题不会跳过检查。

    经验表明，对很多开发团度而言，影响代码走查的因素可以归纳如下：

l  缺乏一致的编码策略以及显式定义的编码指南

l  代码走查的大多数时间都花在了验证代码和其编码策略的一致性上，而不是算法、结构以及重用这些问题上

l  发现的问题未被记录

l  代码走查发现的问题的解决方案未被记录

l  调整/修改代码以实现逻辑功能（对分布式开发团队而言，这一点尤为突出）

l  成本的提升以及开发者不适应

    在某些特定解决方案中，这些效率低下的问题体现得尤为明显。注重代码走查的方案则优于其它的方案，所以，代码走查检测表（更胜于编码策略）更能提升开发团队在工具上的投资回报率（ROI）并且帮助诊断结构性问题、代码重用以及组件使用上的问题。更进一步，自动化代码走查过程能够将开发者从繁重的检查编码策略一致性的过程中解放出来。此外，为了确保新建的代码总是能被检查到，将其准备过程，代码走查的提示以及状态跟踪等过程自动化进行能够进一步改善结果。

解决方案：利用Parasoft C++test来实现自动化同行代码走查

    Parasoft针对各种语言的产品都包括代码走查组件，并且都将上述的大部分工作自动化进行，包括提示以及跟踪过程。例如，下图演示了C++test代码走查组件的界面：

    使用C++test，开发者能够自动获知需要进行人工走查的代码、进行相应走查、记录注释、查询开发者在走查过程中对其代码作出的相应注释并解决这些问题。代码走查中的显著问题将会被跟踪并通过一个报告系统报告给开发者以使开发者能够把握项目状态。

    上面给出的界面证实了这一观点。在左侧，所有未被处理的代码都被标注出来。在代码异同（code diff）面板中，代码中的相应修改都被高亮显示出来以供开发者进行走查。代码走查问题面板则允许开发者对相应的代码添加注释以供具体走查过程访问。

４．早期测试

    软件缺陷中平均只有不到50%是结构性问题，其它则是由于需求缺失或需求实现不正确造成的。查找这些问题就必须依靠测试：既根据软件预期能（或不能）实现的功能执行软件的某一部分。

    “早期测试”通常在先于应用程序级的单元及组件进行的。其主要目的有两个：总的而言就是对相应代码进行功能验证以及检查对边界条件的处理。好的测试工具能通过不同层级的桩函数对尚未完成的系统进行测试，这对其测试效率而言是相当关键的。正因为如此，对未完成的系统进行测试就比人工进行简单得多。这又一次证明了自动化提升开发效率这一事实。

    早期测试后的最重要的一步就是在回归测试套件中重用早期测试的测试套件。这些早期测试套件很可能只能针对其开发者的特殊应用（所以在某些情况下只能在该开发者的机器上运行），所以要重用这些测试套件是很困难的。事实上，在早期测试中创建不可重用的测试套件会造成更多的资源浪费。在理想情况下，团队成员应该能按需调用任何其它成员创建的单元和组件测试套件。这就要求开发者创建结构化的测试套件并且随着开发过程的推进被同步维护，并且支持回归测试时的自动运行。Parasoft的各种产品都支持开发团队各成员的任意调用并且能在回归测试中被自动运行。

５.自动化回归测试

    很多人对“回归测试”这一术语的第一反应是这是在QA阶段或在软件发布前由测试小组进行的。但是这样比从开发到测试持续地进行回归测试更加浪费资源并且效率更低。

    使用持续性回归测试套件，通过自动生成或用户定义的测试套件捕捉到的软件行为与定期地被重新运行验证后捕捉到的行为进行比较。这为开发者变更代码加上了一把安全锁：开发者可以确保如果无意间破坏了既有功能性，他们会被立即告知，而不会将这些问题遗留下去。

    这种回归测试的价值主要体现在自动化上。让开发团队不停的重复测试同样的东西日复一日、周复一周是不太实际的，并且大多数团队会在一个月左右放弃这种测试。此外，测试需要频繁地进行，以保证错误发生后能被立即检测到并被立即修复。因此，为了满足频繁运行这个要求，这些测试必须是自动化进行的。

    开发者应该能无障碍地添加以及运行这些测试套件。显然，如果将这些测试工作全部留给QA小组，这一要求是不能实现的。这种公用访问机制的优点是开发团队中的任何成员都能对其代码运行部分的测试套件（以深入地检查新建代码做出的修改）以及添加测试新建代码的测试套件。另外，如果某个测试失败，其相应的开发者需要能访问这些测试套件并能分析测试失败的原因和立即解决这些问题。一个可持续性的失败检查和分析过程是按时高效维护测试套件的必需。

报告并跟踪结果

    无法评估的东西是无法修改的。所以，对软件开发过程中新引入的任何技术为团队带来的影响进行评估都是非常重要的。正因为如此，报告系统是一个关键组件：它能帮助开发团队检查开发过程中的任何一些细节的趋势并且分析所有由这种改善为代码造成的影响。

    任何实用的系统都应该自动收集开发过程中的相应数据，对其进行分析，然后为团队成员公开这些数据并让开发团队能轻松地管理这些数据，一般提供通过网络访问的能力及带挖掘能力的基于角色的报表。

    由于这样的系统一般是用来做决策支持的，因此持续使用这样的报告系统在开发过程中是很关键的。项目所涉及到的每个成员，无论是项目经理还是一般开发者，都需要经常检查项目的状态及趋势并且帮助保证项目进行不会偏离轨道。

解决方案：Parasoft GRS系统为开发过程提供可视化的报告

    Parasoft GRS是专门被设计来监视团队开发过程的。GRS从源码控制、自动构建、需求管理、缺陷追踪、静态代码分析以及回归测试等系统中收集各种数据并对这些数据建立某种相互的联系以构建一个完整及全面开发过程的状态报告。

    这种带有挖掘能力的基于网络的报表能帮助团队查找代码和流程中存在普遍问题的区域，获得定位其诱因所必须的具体细节信息并且监视对这些问题的相应的改进措施。下图是GRS为软件架构师提供的一个典型的报表。

    通过这些报表，用户可以轻松地查看构建状态（包括错误和警告）、测试状态的当前和历史数据，修复的缺陷和功能、相应的测试层级以及其它一些宝贵的度量指标。Parasoft GRS是对软件开发过程状态提供可视化报告的一个关键组件。

结论

    归纳起来，在任何开发过程中综合使用上述经实践验证的技术是有明显的好处的，如果通过自动化工具来进行实施这些技术将会获得更好的效果。使用这些技术的最终结果是减少开发资源浪费、提升开发效率以及提升软件质量。

    以下是对上面我们论述的这几种技术的总结以及一些使用技巧：

l  鲁棒的开发框架：每个开发团队通常有其特定的开发框架，这些框架往往也只适用于该团队。如果需要，根据Parasoft团队内以及客户支持的经验，我们可以帮助开发团队分析其需求并给出更好的建议。此外，Parasoft GRS能收集各种数据（从源码控制系统、缺陷追踪、构建系统以及需求管理系统等）并对其进行某种关联以使团队能够监视开发框架的使用并通过这些数据更加详细的了解过程、开发效率以及产品状态等方面的问题。

l  团队的编码一致性：Parasoft所有语言的产品（C++test，Jtest，.TEST）都包含静态代码分析组件以帮助团队建立并实施这些最佳编码实践。

l  一致的同行代码走查：Parasoft的代码走查组件能是繁琐的代码走查过程自动化进行，并且支持分布式开发团队的代码走查。这就使开发者和团队的代码走查效率都得到了提升。

l  早期测试和自动化回归测试：Parasoft所有语言的产品都支持在单元和组件级的早期测试中自动生成API测试（从XUnit中提取类似单元测试框架的格式）以及在常用IDE中人工添加测试套件以测试产品功能性。内建的覆盖率分析组件能告诉开发团队有多少代码经过了测试。回归测试可以通过命令行方式自动进行，这就使Parasoft的产品能适应各种构建框架。

l  报告并追踪结果：代码分析和测试产生的所有数据都被自动发送到Parasoft GRS中，并被以图形化的方式报告给各团队成员。