软件工程中软件重用的效益_生活广记

可重用的软部件有的可以不加修改直接使用，有的需要修改后再用。可重用软部件应具有清晰的结构和注解，应具有正确的编码和较低的时/空开销。各种可重用软部件还可以按照某种规则存放在软部件库中，供软件工程师选用。可重用性有助于提高软件产品的质量和开发效率、有助于降低软件的开发和维护费用。从更广泛的意义上理解，软件工程的可重用性还应该包括：应用项目的重用，规格说明（也称为规约）的重用，设计的重用，概念和方法的重用，等等。一般来说，重用的层次越高，带来的效益也就越大。
可重用软件的技术软件的可重用性一直是软件工程所追求的目标之一，软件工程界希望有一天能和其它工业领域一样，利用标准化的软件模块快速构建特定的应用系统。事实上，这种努力也取得了相当大的进展，但是与人们所期望的目标还是有不少差距，软件模块还远没有象汽车上的轮胎那样拆卸、维修、更换方便和简单。
大多数情况下所讨论的软件可重用性指软件本身的可重用性，即软件代码实现的可重用性。而实际上，软件的可重用性远不止这些，软件开发的全生命周期都有可重用的价值，包括项目的组织、软件需求、设计、文档、实现、测试方法和测试用例都是可以被重复利用或借鉴的有效资源。可以说，一个成功的软件项目的全过程都是宝，就看你会不会利用。
当然，软件代码的可重用性是最直观、最容易想到的部分，也是程序员们最乐意追求和有成就感的部分。但怎样才能开发可重用的代码呢？
也许有些程序员会说：这很容易啊，我用C++封装了很多类，我用Visual Studio开发了很多COM组件，不都是可以重用的吗？事实是如此吗？就我所了解和经历过的很多软件开发项目，很多类和组件都是昙花一现，项目一过就再也没人提起。很多程序员认为利用C++开发的类或COM组件天然就是应该可重用的，这是错误的想法，开发工具只是促进代码可重用性的工具而不是决定性的因素，决定代码是否可重用的关键还是对于软件系统所面向的问题域的分解方式，即将一个复杂问题分解成简单问题或独立个体的方法和策略。我一直确信，如果一个程序员使用C的时候，不能很好的使用模块化的结构构造一个软件系统，你就不能期望他能使用C++写出可重用性很高的类结构。不是开发工具决定了软件的可重用性，而是如何分解一个复杂问题。无论是分层的软件思想(TCP/IP协议栈)、模块化的软件思想(C / Fortran)、还是可重用组件的软件思想（C++/COM），它们之间并非是矛盾和排斥，而是一个问题的三个方面，是对同一个问题域的不同视角。
还有些程序员可能会说：我们开发的软件都是针对特定的用户需求，要求都不一样，没有办法实现软件的可重用。听起来似乎也有道理，其实不然，软件的可重用性也是有应用范围的，当然不能期望很多程序员能开发放之四海而皆准的通用软件模块，也许有些程序员永远也不会去开发这样的软件，是不是软件的可重用性就跟他没关系了呢？当然不是，可重用性体现在软件的各个层次，通用的、可复用性高的软件模块往往已经由操作系统或开发工具提供，如通用库、标准组件、标准模板库等，并不需要程序员重新开发。那么一般的程序员如何开发可重用的软件呢？而正常情况下，一个软件企业或软件小组往往专注于解决某一领域的问题，针对这一领域的软件项目虽不完全相同，但也有很多共同之处，比如财务或ERP领域的软件大多需要各种各样定制的表格和图表。所以开发软件时，开发针对某一特定领域或问题域的可重用软件是大多数程序员需要重点考虑的问题和方向。
那么在实际开发过程中，程序员们如何提高自己开发可重用软件的能力呢，我有几个小小的建议也许会对大家有所帮助。
建立开发可重用软件的意识：
首先建立开发可重用软件的意识，不管你所开发的软件有多么特殊，其中必定含有一些公共的逻辑和功能，将公共的逻辑或模块同真正特定的逻辑分开，学会从一个特定的问题集中抽象出几个逻辑层次，分开实现。可重用软件模块将作为一个特定软件产品的副产品而重放光芒。
保持类或模块的简单和纯粹:
保持类或模块的简单和纯粹，越是简单、功能纯粹的软件越可能被重用。越是简单，越是复杂，就象搭积木，提供的积木越简单，就越有可能搭建复杂的形状和物品。
也许有一天，你的一位同事对你说：嘿，哥们，我刚刚用了你在上一个项目开发的那个模块，挺不错。你已经实现了软件的可重用
最理想的重用技术是它的重用产品能够和用户的需求完全一致，不需要用户做任何自定义，并且能够无需用户学习就能够被使用。然而，一种重用技术能够适合今天，可能不适合明天。一个重用产品越是能够被自定义，它越是可能在一个特定的环境下被使用，但是这也需要用户进行更多的学习，研究和实践。
自从软件重用思想产生以来，计算机科学家和软件工程师就致力与软件重用的技术的研究和实践。在30多年的时间内，出现多种软件重用技术，如:库函数，模板，面向对象、设计模式、组件、框架、构架。
下面是应用程序框架和其它三种软件流行的重用技术的比较。普通意义上的构件应从以下几个方面来理解：
1) 构件应是抽象的系统特征单元，具有封装性和信息隐蔽，其功能由它的接口定义。
2) 构件可以是原子的，也可以是复合的。因此它可以是函数，过程或对象类，也可以是更大规模的单元。一个子系统是包含其它构件的构件。
3) 构件是可配置和共享的,这是基于构件开发的基石，且构件之间能相互提供服务。普通意义上的构架应从以下几个方面来理解：
1) 构架是与设计的同义理解，是系统原型或早期的实现。
2) 构架是高层次的系统整体组织。
3) 构架是关于特定技术如何合作组成一个特定系统的解释。如果把软件的构建过程看成是传统的建筑过程；框架的作用相当于为我们的房屋搭建的“架子” 。框架从重用意义上说，是一个介于构件和构架之间的一个概念。构件，框架和构架三者的主要区别在于：对重用的支持程度的不同：
1) 构件是基础，也是基于构件开发的最小单元。构件重用包括可重用构件的制作和利用可重用构件构造新构件或系统，
2) 一个框架和构架包含多个构件。这些构件使用统一的框架（构架）接口，使得构造一个应用系统更为容易。
3) 框架重用包括代码重用和分析设计重用，一个应用系统可能需要若干个框架的支撑，从这个意义上来说，框架也是一个“构件”的同时，框架又是一类特定领域的构架。
4) 构架重用不仅包括代码重用和分析设计重用，更重要的是抽象层次更高的系统级重用。
【软件工程中软件重用的效益】
5) 框架和构架的重用层次更高，比构件更为抽象灵活，但也更难学习和使用。