关于软件重用的几点思考

重用对于软件开发和测试都具有普遍意义，每个软件人员自觉或不自觉地都在进行大量重用工作。不管是编码还是测试，不管是写文档还是写幻灯片，甚至起草短短的各类评审意见，不使用剪切-粘贴操作的几乎没有。

毫无疑问，重用给软件人员带来极大便利，不光是节省时间，更通过继承过去的经验而使新的工作产品质量得到保证。今天的软件人员不仅占有大量的各类模板，大量编码规则和标准条款，还会大量使用搜索工具，真正敲入的文字或代码比例正在越来越少，大部分代码或文档都已经在过去的项目中被多次使用、并经过反复验证。我们在实际软件测试项目工程中，经常听到人家说某段代码已经定型，没有修改过或只改过很少接口，不需要或只需要少量测试就可以了。即使是全新的代码，其中也有很大一部分来自其他类似软件项目，包括编码范例、文档描述、容错处理方法，甚至评审方法和技术。

然而给软引用由于不恰当的剪切件人员带来巨大便利的背后是悄悄的巨大风险。据统计，软件缺陷的-粘贴的竟占到70%。如果说给软件质量带来好处的因素总分是800，那么软件重用占到的比例会高达350；反过来，如果影响软件质量的因素总分是1200分，软件重用会占到650分，虽然都是权重第一，但是如果搞不好，给软件质量的消极影响往往会更大一些。阿丽亚娜5发射失败就是一个惨痛教训。欧空局实施的过程管理不可谓不严，完成的软件测试不可谓不充分，层层通过的软件评审和评估不可谓不系统，但就是一个对型号4的软件重用没有充分考虑硬件变化带来的影响最终酿成大祸。在系统总结教训时，有这样的一条：软件问题出现的部位，是所有领域专家都认为是最保险、最不可能出错的部位，处理方式的正确性已经在领域专家中形成定式，没有人提出任何质疑、反思。

结论是，重要评审仅仅依靠领域专家是不够的，恰恰非领域专家有可能提出更多在领域专家看来可能有些可笑、但却是通过转换思考角度才能发现的微妙问题。

在现实中，剪切-粘贴过来的东西往往还要做些替换，往往还与其他部分存在某种不协调、不一致而需要调整，往往还有一些可有可无或多余的部分需要删除。甚至是很重要的外部评审幻灯片，即使并不长，细细看来，发现剪切-粘贴带来的错误往往并不困难，尽管上会前这些幻灯片都经过反复审阅。

那么问题的关键就是如何控制软件重用的质量。控制的关键又在于识别软件重用引入问题的机理、途径，从而找到解决问题的有效方法。

我认为，软件重用引入问题的关键是由于重用的便利性使得软件人员忽略了必要的分析工作，多多少少有思维定式，加上一些盲目自信和乐观，从而不知不觉欠下技术债。这种债迟早是要偿还的，只不过是偿还形式不同而已。

具体来说，软件重用有两个只要步骤：重用和集成。重用指面向未来的使用而特意进行的专门部件开发。比如模板，就是针对以后的多次使用而进行的开发。集成是利用可重用部件合成完整工作产品的过程。而重用和集成都可能引入软件问题。

首先，可重用部件本身就可能存在问题，即使经过测试、经过实际使用，仍然不能保证验证的充分性，更何况新的使用场景并不一定与老场景完全一致。据统计，面向重用的可重用部件与非面向重用的部件开发成本相比要高出4倍，才能满足重用的质量要求，因为一旦重用部件存在缺陷检测起来更加困难、更难处理，因此要尽可能零缺陷。比如如果模板本身存在问题，重用后的影响就会放大很多。其次，很多时候被重用部件并没有考虑某些重用场景，某些特性并不适合无条件重用，有时又必须补充必要的特性。比如测试文档模板可能没有考虑部分工作外包的特殊性等。

至于集成，引入质量问题的可能性就更大了，涉及到可重用组件筛选、匹配，必要的修改，必要的验证等。其中组件筛选和匹配至关重要。组件功能静态描述和行为动态描述是实施筛选的前提条件。自然语言很难承担这个任务。基于模型的形式化描述看来是可行的选择。首先模型能够准确地描述组件最核心、最本质的内容，从而保证筛选的大方向不会有大的问题。既然模型是对组件的某种程度抽象，因此不可能表示出所有细节，特别是一些容错处理的细节，而这些细节对于组件重用又可能是至关重要的。

比如某电信交换机组件，可以比较方便地使用米莉有限状态机描述。但是有些容错处理方式却很难通过一个统一模型表述。比如交换机主叫用户，回铃音收到8次转入告知无人接听状态。但是如果收到3次回铃音后不再收到信号怎么办？可以转到超时等待状态再转无人接听状态。如果超时门限未到，第4个回铃音收到，那么是不是该继续回铃音计数状态？如果第5个回铃音又迟迟未到，超时是继续累积还是重新计算？极端情况是不是迫使主叫等待过长时间？

这样的细节建模会非常繁琐。测试用例包可能是一种替代方法，通过预期输入与预期与设计、需求约束的符合性，提供筛选依据。

我认为，即使采用了比较完备的形式化描述方法，必要的人工分析都是必不可少的，必须建立与技术手段和重用风险相匹配的管理过程和活动规范，比如必要的评审、分析、验证等。

另外要形成软件重用和集成的规范，强化面向重用的组件开发，强化集成的分析验证。开发好的可重用组件，更安全地集成新产品

关键科技