外包是什么
现在有很多人（和公司）在做外包，但我对外包是什么一直都不太清楚，于是百度一下，很多人在问这个问题。据百度百科的解释：
外包是一个战略管理模型,所谓外包（Outsourcing），在讲究专业分工的二十世纪末，企业为维持组织竞争核心能力，且因组织人力不足的困境，可将组织的非核心业务委托给外部的专业公司，以降低营运成本，提高品质，集中人力资源，提高顾客满意度。
外包的范围按工作性质可分为"蓝领外包"和"白领外包"。"蓝领外包"指产品制造过程外包。"白领外包"亦称"服务外包"，指技术开发与支持其他服务活动的外包。其中技术开发与支持的外包一般采用一次性项目合同的方式寻求第三方专业公司的服务，称为"合同外包"；其他服务活动的外包多通过签定长期合同的方式交由专业外包提供商进行，称为"职能外包"。
相应而言，软件项目中的外包——"软件外包"：
所谓软件外包就是一些发达国家的软件公司将他们的一些非核心的软件项目通过外包的形式交给人力资源成本相对较低的国家的公司开发，以达到降低软件开发成本的目的。众所周知，软件开发的成本中70%是人力资源成本，所以，降低人力资源成本将有效地降低软件开发的成本。
然而"外包"这个名词有时容易和"离岸外包"相混淆：
外包和离岸外包经常被混用，但是外包主要是与组织的重组相关，而离岸外包更强调的是国家。当然，在当今全球化的前提下，这两个概念并不是互斥的。从根本和历史上讲，外包是一个有关在团体内和团体间对劳动力进行组织的术语。
这种解释很功利却很现实。
构件的争议
"构件"、"组件"这两个词一直很令人费解。
在《构件化软件——超越面向对象编程》（Component Software: Beyond Object-Oriented Programming）一书中构件是指Component, 其定义为：
软件构件是一种组装单位，它具有规范的接口规约和显式的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。
在《.Net 组件开发》（.NET Component-Oriented Programmlng）一书中组件就是指.Net中的Component。
由此可见"组件"和"构件"仅仅只是译法不同而已。
另外， "构件"（Component）不能和"控件"（Control）搞混淆了。控件一般是指可视化的可操作的GUI单元。控件是一个构件，就如同Control派生自Component一样。
黑盒测试与黑盒抽象
黑盒测试时软件工程中一种测试方法。
黑盒测试是用来检测每个功能是否能正常使用，因此又称功能测试。之所以叫黑盒测试，是因为在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。
从黑盒测试的模式来做设计有黑盒抽象和黑盒重用。
黑盒抽象的设计中，客户对接口和规约之外的实现细节一无所知。例如.Net 中的Thread类，我们不知道它是如何实现（虽然可能很好奇），但却可以直接创建它的实例来创建一个托管线程。相应的这个过程就叫黑盒重用，具体而言，要在重用时仅仅依赖接口和规约，不需要了解构件的实现细节。
与黑盒抽象相反的是白盒抽象，它来自白盒测试，要求客户了解实现细节。
相应的白盒重用就也是需要用户了解实现细节的。一个例子是MFC编程，在重用MFC类库来创建一个窗口时，一般要从CWnd或其子类来派生出一个新的子类，在新的子类中添加一些消息响应函数，重写父类的一些行为，这样达到自定义窗口的目的。一般而言白盒抽象中，在接口限制了用户行为并确保了封装性的情况下，客户仍然可以通过继承对构件的实现细节进行修改。当然为了修改实现细节，首先要对原构件的实现细节有一定的了解，这就是学MFC这样的类库学到深处总是需要研究其源代码的原因。
事实上，白盒重用中，被重用的构件不可以轻易被替换（升级），否则，有可能破坏正在重用的客户，因为这些客户端依赖于那些在未来可能发生改变的实现细节。
据了解，很多兼容性问题是由于白盒重用对实现细节的依赖引起的。
算是结语吧
"外包"、"构件"和"黑盒抽象"是这两天学习的一个内容。
软件构件的思想很早（上世纪六七十年代）就提出了，但直到了这个世纪，真正的软件构件的才成功形成市场。很多公司对构件进行了探索，如微软的VBX, COM, COM+, OLE/ActiveX到现在的.Net构件技术，OMG的CORMA, CCM, OMA和MDA， SUN公司的Java, JavaBean, EJB等。
顺便说一句：然而在学校中，令人郁闷的是，学到的还是很古老（当然很经典的）面向过程式的软件工程分析设计，然后面向对象的分析和设计居然还只是选学（老师只是提了提），至于构件式的开发，则是根本没讲过。
很传统的开发方式——从头开始，只借助开发工具和平台函数库——有人叫"定制软件"，定制软件可能具有一定的潜在的优势，但目前来看定制软件却又很多明显的内在不足，如开发代价和滞后性等。
构件式的开发（多以外包的形式）则相对而言具有很大的优势，构件式能迅速适应变化的需求，良好的设计能给用户更多自由定制的空间。
