翻译自“Lessons Learned Developing and Deploying ACE” from 《An Architectural Overview of the ACE Framework》 by Douglas C. Schmidt
这一部分总结了过去七年我为ACE框架开发可复用的面向对象组件，以及在航空电子、电信、医疗等领域的商业应用中部署ACE框架学到的经验。
软件不可复用大多由于非技术原因：理论上，公司等组织都已经认识到软件复用对于减少开发周期和提高软件质量的重要性。但是在实际中，有许多原因都会导致无法做到系统性的软件复用。其中大部分来自政治、经济、组织架构和心理上的障碍，而不是技术上的。举个例子，开发可复用中间件的平台团队经常会被开发应用的团队抱怨，因为后者失去了对架构中的关键部分做决定的话语权。
一个大规模的成功的软件复用需要的前提条件：根据我的经验，大规模软件复用需要以下条件： • 所处市场高度竞争化：在市场竞争环境下，产品推向市场的时机非常关键。所以利用现有软件以减少开发工作量和时间就很重要。反之，如果市场不是那么竞争化，那么通常会倾向重新发明而不是复用。 • 所处应用领域具有挑战性：相对简单的组件可以从头写，比如通用的链表、栈或者队列。但是对于比较复杂的组件，开发者们就更愿意复用，比如动态调度框架或者实时ORB。因为复杂的方案如果从头写会比较困难且花费时间。 • 公司的合作文化很重要：开发高质量的可复用组件和框架非常困难，特别是难以立即从复用中得到好处。开发有效的、弹性的，而且文档良好的可复用软件需要花费巨大的精力。这样，公司必须提供有效的方法来让促进复用。例如，需要鼓励而不是惩罚开发者花费时间构建健壮的可复用组件。并且，复用的过程中必须能提高应用软件的开发效率，而不是无止境地抽象模型和高层设计文档。
根据我的经验，这些前提条件在当代的公司中通常不存在。我发现公司通常会说“这儿没有现成的可复用软件”，然后从头重新开发大部分软件组件。不幸的是，随着放松管制和全球化竞争，这种从头造轮子的开发方式越来越难成功。
迭代、增量式开发是关键：组织必须明确认识到，一个好的组件、框架和软件结构需要花费大量时间来制作、打磨和应用。通常要是成熟的组织才能开发、使用和复用软件，因为他们有能力区分应用领域中容易变化的部分和通用的部分。而识别和分离这些需要许多次的迭代。 管理层必须有眼力和决心，支持增量式的改进可复用软件。Fred Brook发现“如果心里做好准备把第一个版本丢弃，那么你将不断进步（Plan to throw the first one away, you will anyway）”。这条规则在20年后的今天依然适用。并且，根据我的经验，在推广可复用软件框架和组件时，“追求完美是完成任务的敌人 （the best is often the enemy of the good）”。通常，部署一个完成度80%的解决方案并不断增量式地迭代会比一直等待一个100%的解决方案要好，因为通常100%的解决方案永远不会出现。
亲自动手得到的经验是无可替代的：开发高质量的通信软件很困难，开发高质量的可复用通信软件难上加难。开发可复用软件的原则、方法、经不能简单地通过泛泛而谈学会。相反，开发者必须通过亲身经历学会如何设计、实现、优化、验证、维护和增强可复用软件组件和框架。开发者只有参与这些活动，才能真正内化优秀的开发实践和模式。
基础框架开发者要和应用开发者协同工作：大多数有用的组件和框架起源于在某个应用领域解决实际问题，比如信息、医学图像、航空电子、网络编程。因此，一个经过时间检验、行之有效的方法是从工作系统和应用中归纳出有效的可复用组件。ACE框架就是这样产生的。 我发现，成立一个专门的独立于开发应用的团队来开发可复用框架，这样的效果通常很差。由于缺乏来自应用开发团队的直接反馈，这样开发的产品不仅不能解决实际问题而且不能被系统性地复用。
根据架构设计，而不是根据某种中间件技术标准开发：不要期望新兴产业的中间件标准，比如CORBA、DCOM，或者Java RMI，会自动消除通信软件开发中的复杂性。没有一种解决方案是万能的，标准不是必须无处不在的，而且在实施上也缺乏一致性。 因此，对于复杂的通信软件系统，关键是设计和使用超越任何一种特定中间件技术标准的架构。我发现设计一种可以在多个中间件平台上实例化的通用软件结构比直接根据某一种中间件API编程更有效，而后者会很快地过时。
操作系统的API之争是可以避免的：ACE的操作系统抽象层使得原生操作系统API的选择只是实现的细节，比如POSIX、Win32或者实时操作系统。使用ACE可以简单地开发可移植性很强的通信软件，广泛地应用于各种操作系统和C++编译器。并且，ACE的可移植性不会以牺牲运行性能为代价，因为它不是运行在解释性的虚拟机上。这样，ACE提供的可移植性让开发者可以根据特性、价格、性能、开发工具、集成难度来选择操作系统平台。
小心别用太简单的方式解决复杂的问题：尝试用过于简单的方案解决复杂的问题通常会导致挫折和失败。例如，尝试完全从高层SDL特性或者分析规则翻译成复杂通信系统的软件实现就极少能成功。类似地，使用流行的面向对象设计方法，对名词建模，然后编程通常也不会成功。根据我的经验，拥有高超软件技能的开发者无可替代。这也就引出了以下最后一个经验。
尊重、奖励高水平的开发者和架构师：根本上说，可复用组件和框架是开发者水平的体现。开发健壮的、有效地、可复用的中间件需要团队具有多方面的技能。我们需要掌握设计模式、软件架构和通信协议的分析和设计专家以减少通信软件固有的和意料之外的复杂性。并且，我们需要编程专家在可复用框架和组件中实现这些模式、架构和协议。
根据我的经验，高质量的软件开发者是非常非常难得的。讽刺的是，许多公司把他们的开发者当做可替代的无技能劳动力。随着时间流逝，尊重和奖励高水平软件开发者的公司会逐渐胜过那些不尊重开发人员的公司。