软件的涅磐

软件的涅磐

作者：黄柳青

1999年，计算机科学家布鲁克斯（Frederick Phillips Brooks,Jr.）以近70岁的“高龄”获得了图灵奖——这位数十年来蜚声世界的软硬件专家、教育家曾在其《没有银弹》（1986）一文中提出了一个迄今为止尚未被打破的著名论断：“没有一种单纯的技术或管理上的进步，能够独立地承诺在10年内大幅度地提高软件的生产率、可靠性和简洁性”。布鲁克斯用形象的譬喻来论述软件工程中存在的“陷阱”——“在所有恐怖民间传说的妖怪中，最可怕的是人狼，因为它们可以完全出乎意料地从熟悉的面孔变成可怕的怪物”，而“大家熟悉的软件项目具有一些人狼的特性（至少在非技术经理看来），常常看似简单明了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物”。惊悚故事里，人们只有用银弹（银质子弹）才能消灭人狼，而布鲁克斯认为，在软件工程中，“没有银弹”，没有一种能够遏制软件向“怪物”变异、同时还可大幅提升开发效率和产品质量的武器。

某种意义上，布鲁克斯的观点（抑或预言）是正确的——如果不能对基于代码的软件体系进行彻底的革新，那么在今后10年（甚至更久）的时间里，我们仍会在繁复迂曲的代码迷宫中遭遇“怪物”。

  软件之死

一、大型企业级应用软件已经死亡

2003年8月底，一年一度的DCI CRM展会在纽约Javitz中心举行，参加展会的有21%是来自全球性企业（平均有6600多名员工）的CxO，60%是这些企业的中层管理人员。作为CRM市场的预言家和领头羊，Siebel总裁Tom Siebel每年的主题演讲都是大家翘首以待的。但是，这一年Tom Siebel的演讲标题却让与会的所有人震惊：“CRM之死”。

“CRM产品已经没有市场了。”根据Siebel的预计：IT部门将不再购买通用的CRM软件，然后再按照自己内部的业务流程对软件进行调整了。如果Siebel的预见是正确的，那么CRM市场的终结也意味着企业关系管理市场、供应链、人力资源管理市场，以及其他大型应用软件市场的终结。通过市场调查，我们发现，国际主流的几家企业管理软件厂商，包括SAP、PeopleSoft、Siebel等，近几年来的营收一直在容与徘徊，而利润更有下降之势。当前，几乎每一种大型的企业级应用软件都在遭遇着深重的危机，以至于出现濒危甚至垂死的症状。美国国家标准和技术研究院的一份研究报告显示：“占据世界软件销售额85%的是大型的专用软件，而其开发的失败率却高达70%！”

大型企业级应用软件正在走向死亡，它表现在各个方面。

首先，以传统方式开发的大型企业级应用软件难以突破布鲁克斯的“没有银弹论”，找不到软件工程或者项目管理的方法，能够大幅度提高应用软件的开发效率——开发周期长、开发费用高，实施费用超支和工期延长，已经司空见惯。更加可怕的是，随着企业的环境和需求的不断变化，“建成即成闲置”，形成软件工程的灾难。

其次，客户对大型企业级应用软件的诸多期望几乎无法得到完全满足。例如，客户期望实现业务集成和协作，在协作基础上构建出高效的企业应用体系；客户期望对供应链上的信息进行及时传递与处理，以实现更快捷的市场响应能力；客户期望能够快速实施和低成本部署满足个性化需求的软件系统，并适应未来商业环境的变迁……一句话，客户对软件功能和性能的要求越来越高。在这种市场需求下，要实现企业各个层次的集成，必然会导致软件在规模、复杂度、功能上的空前扩张。

不仅如此，企业级应用的危机还表现为系统部署运行和维护的“危机”。应用环境从单机应用，过渡到客户机/服务器的环境，再过渡到浏览器/服务器的环境，并进一步向多层式（N-tier）分布式系统的网络环境迁徙。今天，基于互联网的企业级应用要求软件实现跨空间、跨时间、跨设备、跨用户的协同，软件处于极度复杂的异构环境中，这种情形下，以传统的软件开发思路应对当前的危机就只能是刻舟求剑、缘木求鱼。

类似的危机，在中国表现得尤为突出。中国是一个迅速发展和不断转型的国家，中国企业的形态因此而更复杂，中国企业的改革变化空间因此而更大。正因如此，中国企业级应用开发和运营的危机也就更为严重，企业信息化的风险更多，失败率更高。

我认为，正是传统的软件体系酝酿和加重了企业级应用的危机。

软件体系主要包括软件结构和生产方式。传统的大型企业级应用软件的主要特点是：编码式的开发方式和一次开发持续运行的应用软件——编码式的开发方式，使得快速开发企业级应用软件的愿望难以实现；一次开发持续运行的方式，则导致了软件的僵化和濒危——很明显，这种软件不但难以适应客户需求的变化，而且每次修改都必须在代码层上推倒重来，因此造成了效率的降低和资源的糜费。

传统的软件体系正在内外交困的重重危机之下走向死亡！

二、探究软件死亡之因

互联网时代给企业带来了无限的想象空间。企业的营销模型由传统的4P（产品、定价、地点、促销），引领出基于互联网的ABC模型（任何时间任何地点、基于网络、沟通营销）。企业系统已经从部门级、企业级，发展到社会级的实时在线的应用，应用的范围在深度、广度上都发生了质的变化。

世易时移，变“法”宜矣——当应用需求已从部门、企业上升到社会的层次，我们必须重新考察企业级应用的需求。

一方面，用户需要个性的软件。市场经济条件下，成功的企业，一定是个性化的，有独特的管理方式和企业文化，以此区别于竞争对手，以赢得市场空间。企业的价值一定是个性化的，企业信息化必须从个性出发：企业级应用软件的实施应该充分体现和放大企业的与核心竞争力相关联的个性价值，从而使企业的价值得以提升，这才应该是信息化对企业的核心贡献。如果一个信息化项目不仅不能凸显出企业的个性——反而加剧了企业与同行的“价值同质化”，那就可以判定，这个信息化项目未能获得成功。

另一方面，企业需要灵活的软件。企业的生命周期是一个动态变化的过程。在每个成长阶段，企业都需要有所区别的政策和管理；随着环境的变化，企业的业务和管理方式要相应地发生变化；再加上随着企业概念的外延扩展，如今已变成了一个涵盖供应商、客户以及各种合作伙伴的虚拟组织。因此，企业对灵活性或者弹性的需求变得十分重要，相应的，企业级应用软件也需要更高的弹性。

目前，传统的企业级应用软件产品往往采用两种典型的交付模式。

其一，以套装软件加上二次开发交付客户。此种方式主体上固化了软件的功能结构，只留一小部分参数配置。这样的软件在具体应过过程中还需要大量的二次开发，即使这样，仍然时常不能满足企业的需求。应用软件厂商通常会大肆宣扬自己的产品包含“行业最佳业务实践”，并以“管理专家”的身份对客户的管理模式强行变革，以适应这种标准化的“行业最佳业务实践”。然而每个企业所处的竞争环境千差万别，企业的战略、核心竞争力亦有所不同，企业只有保持自己鲜明的个性，并对环境的变化保持高度的柔性，随时准备调整管理策略，才是生存和发展的关键。试问哪里有这种“放之四海而皆准”的管理真理能解决所有企业的问题？由此可见，所谓的“行业最佳实践”必然是以抹煞企业特征和不适应未来发展需要为代价而实现的。“开盒即用”的方式往往具有良好的系统架构和稳定的系统性能，能够适应一定领域的市场需求，但很难满足不同用户的个性化需求。

其二，为客户从代码级开发定制的软件系统。这种定制开发方式，基本上是从客户的个性化需求出发，进行软件定制。诚然，这种定制开发的软件系统能够满足特定用户的大部分需求，但开发者总是很难全面考虑软件的扩展性、稳定性等架构因素，产品因此而不能快速适应客户的需求变化，同时也很难提高开发的效率。许多软件公司，陷身于在软件定制开发的泥潭中无法自拔——软件知识得不到有效的积累，成本又居高不下，这构成软件公司或者是系统集成公司的发展瓶颈，同时也在一定程度上妨害了软件产业的发展。

显而易见的，上述两种软件开发方式，都不能解决软件随需应变的问题——软件开发方式效率低下，软件结构死板僵化。在这个企业形态不断变化、企业外延不断扩展、企业的环境不断变迁、企业的业务不断调整的时代，这种以一次开发持续使用为特征的软件已日显陈腐和落伍。

三、寻找银弹

“没有银弹！”布鲁克斯如是说——真的就没有任何一种技术或管理上的进步，能够独立承诺大幅度提高软件开发的生产率、可靠性和简洁性吗？

确实，直到上个世纪末，20多年以来，软件行业的生产效率依然没有数量级的提高，软件在帮助传统行业提高效率的同时，自身却成为最原始意义上的“手工行业”。虽然，许多大型的企业级应用软件采取了大规模的生产和协作，但是这种软件往往开发时间长，效率低，无法动态调整，无法由僵硬变得灵活和敏捷。软件业也需要脱离手工作坊时代和工业时代，而走进敏捷定制的后工业时代。

软件生产方式的落后，加之需求和环境的进一步复杂，使得传统软件的生产方式，不但不能缓解软件工程的危机，而是处于不断加深的危机之中。互联网应用时代，企业期望的是以更低的成本，更快的速度，获得高质量、高灵活性的随处可得的软件。显然，依靠传统软件业落后的生产方式和僵化的软件结构，无法面对互联网应用的挑战。矛盾在不断加剧，危机在不断加深。

我的看法是，传统的软件工程的方法无法解决“软件危机”的问题；换言之，不要期望从传统的软件体系中找到真正的“银弹”。

僵化的软件结构无法产生银弹——从代码级做起的软件，强调功能实现，天生具有庞大、僵化、无法适应变化的缺点。编码式的软件，无论是采取何种方式，都无法真正实现“敏捷定制”。代码级的编程、代码级的维护使得效率不可能真正地提高。

落后的生产方式无法产生银弹——从代码级做起的软件，经历了大量重复性的需求分析、设计、编码、测试、维护工作，生产周期长、软件复用性差。依靠这样的生产方式，生产效率如何提高？又如何能保证软件的高质量？

    既然传统的软件体系是导致软件危机的根本原因，固守这种软件体系，软件业将永远无法摆脱“软件危机”的噩梦，更无法实现软件大规模敏捷定制的梦想，那么，那颗用以制服“软件人狼”的银弹究竟在何方？

软件之变

软件之变 “史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚。它们最后都沉到了坑底……过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中……” 布鲁克斯《人月神话》 结构之变 我们来解剖一个死亡的大型应用软件系统。在一个有几千员工的企业，在投入了千万级的资金和两年时间之后，一个企业级的业务支撑系统刚刚上线运行。可是企业的组织结构、流程、人员在软件开发的过程中已经发生变化，而且还在变化！软件开发商必须修改软件。软件有一千多页的设计文档，上百万行的代码。“有经验”的程序员跳过了设计思路而直接编写程序源代码。久而久之，软件的设计文档还“刻舟求剑”的停在原地，源代码已经与当初的图示思路大相径庭。实际上，任何事物有了“百万级”的因子之后，都是没有办法直接管理的。上百万行软件源代码几乎无人能懂，并且极难改动和维护，软件因此变成了挣扎于焦油坑中的巨大怪兽。 要解决大型应用软件的难题，必须首先解决软件的结构问题。汇编语言的出现，使软件告别了“0”与“1”组成的“天书”。其后软件的车轮走过高级语言、面向对象、面向服务等不同阶段。直至面向构件的软件技术出现，软件技术人员将挣脱面对大段冗长代码的泥潭。在面向构件的软件中，一个应用系统不是由上百万行的代码组成的，而是由几千个构件经过可视化组装而成的。系统的复杂度有了数量级的下降，而图形化的组装使软件跟应用设计合二为一。 作为对代码式软件体系的颠覆和革新，面向构件的软件体系首先从表达层面填平了代码表达与图形化知识表达两者间的鸿沟，彻底消除了软件源代码与软件设计思路之间的断层。主要优势在于：用户的需求改变可以直接通过构件装配式的图形化设计思路得以体现；永久的屏蔽软件代码层，可以让软件架构师和程序员跳出传统开发模式的局限，只需和图形化的构件打交道，在彻底进化软件表达的同时，也使其改动与维护易如反掌。 在面向构件的软件思路下，简洁表达带来了简洁的软件更新——“随需应变”不再只是一句口号。面向构件的软件体系，松散耦合的构件组装方式，系统不同部件之间的低关联度。重复使用经过考验的构件，可视化的知识表达，系统复杂指数的数量级下降，也使得企业应用更为成熟更为稳定。 面向构件的趋势正为软件行业的预言家所看好。在《软件成功的奥秘》一书中，麦肯锡四位资深专家Detlev Hoch、Cyriac Roeding、Gert Purkert、Sandro Lindner经过对全球一百家最成功的软件公司、450位顶尖领导人物的访谈之后，认为面向构件技术是软件行业未来前景中的核心部分，软件行业提高生产率的主要来源。引用软件专家Brad Cox的话说，面向构件的技术是软件行业的银弹！ 追溯历史，面向构件的技术理念渊源已久。Mcllroy在1968年提交NATO软件工程会议的论文《大量生产的软件构件》中，首次提出了“软件组装生产线”的思想。早在20世纪九十年代初，中国科学院的杨芙清院士就提出了构件化软件体系的设想。那以后，采用构件技术实现软件复用，采用“搭积木”方式生产软件，就成为软件开发人员长期以来未能实现的梦想。海内外学者不谋而合对面向构件技术展开的大量探索，归根结底是为了解决软件开发过程中“重复发明轮子”的问题，如何能让同一个轮子也可以用于不同的车。这恰恰印证了中国的一句老话：殊途同归。 生产方式之变 中国正在制造一切。在美国人、欧洲人、日本人看来，的确如此。从打火机、儿童玩具、服装鞋帽到钢琴、计算机主板、飞机配件，我们的政府从不讳言制造业已成为中国经济发展的支柱产业。试想一下，如果能充分借鉴并汲取制造业的发展经验，软件产业会不会在不久的将来成为驱动中国经济增长的又一“强力引擎”？ 其实，就如同制造汽车，软件的开发完全可以构筑在“构件组装”的模式之上；这样，软件技术人员可以摆脱“一行行写代码”的低效环节，直接进入“一块块搭配构件”的更高阶段。不仅如此，面向构件的技术彻底打破了原有软件基于代码层开发的固有模式。“构件”取代了“代码”成为了软件的“信息原子”（基本结构单元）。随着构件库的不断充实和完善，灵活的构件、集成式的软件结构将把搭积木式的“组装软件”从梦想变为现实。 面向构件的产品不仅在客户需求吻合度、上线时间、软件质量上领先于同类产品，大大提高了项目的成功率。而且，软件的开发和维护变得空前简单，客户可以随时随地获取应对商业环境变化和IT技术变化的最新信息化方案，真正实现“敏捷定制”。 再从软件应用的角度看——互联网时代的企业应用定义，正在发生革命性的变化。软件在传统的企业应用模式中，是为某一个部门服务的，也是以其所完成的功能表述的，从主观上可以把企业应用分割为人事、财务、行政、ERP、CRM、SCM、BI等等；而在互联网的应用中，横向的部门互动、实时的企业间互动、多样的交互渠道、灵活的业务规则，使得原先意义上的“独立应用”不复存在。客户应用模式的变化，从根本上对软件企业及其产品提出了更高的要求。 综前所述，面向构件不失为软件企业的优选方案——作为软件代码的集合，构件可以完成一个或多个功能的特定服务，也为用户提供了多个接口。通过构件组装，实现契合互联网时代应用需求的全部软件功能，这种解决思路必将为当前的大型企业应用产品画上一个历史性的圆满句号。不久我们看到的企业解决方案　会面目一新，不再单一固化；它是一组或多组面向构件的模块，按照企业自身需要灵活组装，并随着企业的变化不断重组重构、动态匹配。 面向构件的思想，第一次给了软件腾飞的翅膀，可以]快速实现像硬件那样的任意装配定制。过去，有人将软件定义为“编码的知识”，而今，新体系下的软件成为了“构件的知识”——即使说成“构件技术改写软件定义”也丝毫不为过。 产业之变 开发效率是企业生产力。全球范围内的软件从业者都在探寻着“提高软件开发效率”的可行途径。概括说，提高软件开发效率的关键在于提高软件的复用能力和复用程度。 研究报告显示：“一个软件的60％－70％的功能是可以被复用的。”然而现实情况则是，不同的企业总是不断在为其客户开发着几近相同的“轮子”——某种意义上，“不断地重复发明轮子”正是对当前软件生产模式的最恰当的描述。毫无疑问，只有面向构件才能让企业这驾战车（包括软件公司和客户在内）在“软件复用之路”奔驰得更加迅疾、更加平稳。 在长期笼罩着阴霾的软件天空里，面向构件的思想仿佛一道曙光，撕裂了陈腐的旧软件体系——相信进化论吧，最终，旧的一切会被抛弃，取而代之的将会是崭新的面向构件的软件结构。这是一个灵活的软件取代僵化的软件的过程，也是一个新的体系开始产业化的过程。据不完全统计，目前国内外已经有相当一部分前瞻性厂商，开始尝试新的软件体系。 图表：面向构件的软件体系下的软件产业结构 那么，新的软件体系、软件结构将会给软件产业以及应用模式带来哪些变化呢？主要有以下两方面： 一方面，面向构件的互联网应用基础平台将备受瞩目——该平台将成为应用软件构件化的“金字塔基”，为应用软件向面向构件的技术迁徙，提供开发运行的环境和基础设施。 另一方面，分层级的应用构件将取代应用软件编码——复杂、僵化的应用软件的编码时代将会结束，取而代之的是“敏捷的构件集成时代”的到来。 此外，面向构件的技术还将会极大地促进应用市场的发展。未来以面向构件技术为基础的软件产业必将催生出众多的应用构件厂商，从而形成社会化的分工和交换。这种分工协作带来的明显好处是，面向构件的应用软件在成本、质量、交货期等方面的竞争力将远远超越传统的软件体系结构下的应用软件。 分析面向构件的软件产业的生命周期，大致可划分为五个阶段：创新期、接受期、成熟期早期、成熟期晚期和衰退期。如今，面向构件的软件生产已经跨过了接受期，其标志是面向构件的软件生产思想开始商业化，单个厂商开始采用面向构件的软件生产方式。然而，接受期和成熟期早期之间的产业鸿沟依旧存在。构件理念由接受期向成熟期早期进化，单点突破很多，但尚未形成生态链。可以预见，一旦跨越产业鸿沟，整体产业发展将经历巨变，我们将面临一个雪崩式的发展阶段——根据Gartner Group的预测：“到2005年至少70%的新应用将主要建立在如软件构件和应用框架这类‘构造块’之上。”——我国在构件化软件的探索方面也已悄然前行，国务院信息化工作办公室在《振兴软件产业行动纲要（2002年至2005年）》中，多次提到推广应用软件构件和复用技术，加快构件技术发展的目标要求。国内已经有一些厂商开始通过联盟的方式推动面向构件的软件体系的发展。毋庸置疑，新体系将为中国软件产业提供“后发先至”的宝贵机遇！ 软件业变革的帷幕已然拉开，面向构件的软件技术被越来越多的国内外业界专家推崇为软件产业的The One。可以深信，在未来的十年里，我们将有幸目睹软件在面向构件的思想指导下不断发展、日臻成熟。代码式的软件最终会成为历史，软件将以更优美的形式被表达、更优美的方式在生产，并在使用过程中获得更加完美的体验。   软件之美 软件建筑之美 新春伊始，北京的气温略有回升。周末，颐和园里到处熙熙攘攘，游人如织。昆明湖畔，万寿山边，有气势宏伟、层叠绵延的重廊复殿，有自然绮丽、神韵似水乡江南的园林；饱览湖光山色之余，不禁大为慨叹中国古建筑之美。实际上，颐和园的众多建筑，大都是由标准化的构件组合搭建而成。 古建筑之美在《营造法式》中大抵可以寻根溯源。该书成于北宋时期（约公元1103年），凡三十六卷，乃中国古代建筑学集大成之宝典。书中提出了一整套木构架建筑的设计方法，概括了当时的各种构件详图、规格、尺寸，以及生产各种材料构件的标准，和砖、瓦、琉璃的烧制方法等等——此书可说是颐和园建筑风格与建筑方法的渊源——通过建筑构件的分解和标准化，《营造法式》为中国古建筑的结构设计、工程管理奠定了基础。中国建筑之美，肇始于此。 感叹建筑之美的同时，我也在思考：能否找到属于软件体系的《营造法式》？ 研究现在的软件体系，不难发现：现在的软件专家们仍需要与大量的需求、设计、代码的细节打交道。出于项目实施时间、投入资源等方面的限制，大型软件往往以实现若干个具体的用户功能需求为目标。专家们没有时间，也没有精力去追求软件的美学目标。日复一日，随着用户功能要求的变化，大型软件项目成为大量代码的随机而无序的堆积，奇丑无比。许多工程师一旦完成项目，就恐避之不及，不愿再去碰自己几个月来夜以继日的劳动成果。 而在面向构件的软件思想中，软件专家们则要幸运得多。他们不再需要不断重复具体的软件实现的技术细节；他们的工作更像一个软件建筑师；他们的思绪又重新集中到用户的切身业务需求上，围绕用户，如何用简洁的结构，搭建出一个个有个性、有美感的软件。 正如看风景。设想在昆明湖边，忽然下起雨来，你仍可沿着长廊绕湖徜徉，品味雨带来的几丝清韵；抑或寻一个八角亭，邀三五好友喝茶对弈。但说回到现今的软件，美感顿失；似有刀耕火种时期为一栖身之所而知足之嫌。也许终有一日，软件也会如昆明湖畔的风景，无论何时何地，都能让用户随心所欲体验互联网时代的万般精彩。 软件结构之美 从心理学角度说，人类对事物的认知大致经历了感觉、知觉，再到思维的渐进过程，这也是一个从具体到抽象的过程。一开始我们会根据物质的外延特性（如软硬、冷热、黑白）来“表达”物质，其后根据它的功能来“表达”，最终我们明白了所有物质的结构。 早在公元前五世纪，德谟克里特就提出了物质永远存在。他认为世界是由一个巨大的虚空和无数的原子组成。 1803年英国化学家道尔顿创立的原子学说，则从物理学的层面向世人揭示：“一切元素都是由不能再分割和不能毁灭的微粒所组成，这种微粒称为原子”；从此我们对事物的认识从原子、分子逐渐过渡到宏观层面。 这种对事物本质认识的进化，奠定了整个科学进步的基础。不管从哲学领域的原子论，还是物理学领域的原子论，我们都能清晰发现，西方表达事物的方式是个进化的过程，贯穿始终的仍是从本质出发，用分析的眼光关注物质的基本结构——那么，假如我们不再像以往那样功能化地审视软件，而是去关注其本质，关注其结构，是否会找到一条提升软件生产效率的新途径呢？答案是肯定的。 在不断变化、日新月异的业务知识范畴，面向构件的软件体系找到了一个可以固化软件知识的结构，即通过构件为人类建立有效积累和复用知识资源的途径——实质上，构件就是各种通用知识和业务知识的封装和复用。面向构件才能改善软件知识的生产和管理的质量，实现软件财富的有效积累，实现知识的管理与创新。 以构件形式“装配”而成的软件更契合软件企业及其客户的需求，同时也更具“美”的特征。评审软件的美丑妍媸，关键要考量软件的结构简洁与否，软件设计与实现可否快速应对业务需求的变化。基于这个标准，可以得出：代码式软件受制于开发方式和软件结构，因而不大可能呈现出“美”的特征；而面向构件的软件体系是依靠变化来获取活力，能尽可能保持干净、简洁的设计——这当然更接近我们对“美”的定义。 美的软件结构需要具备很好的复用性、可维护性以及可移植性。复用性好，能保证为开发者节省大量的资源；并摆脱基于代码的传统软件结构的晦涩难懂，建立方便维护的基础。较之传统代码式软件维护难、修改难的缺陷，面向构件的软件则清晰明朗，容易理解，还具有很强的可维护性。可移植性，在传统的软件体系中根本无从提及，软件体系自身与系统应用环境之间存在千丝万缕的关联，软件企业也无力解开繁复的关联纠结，剪不断理还乱；而采用面向构件的软件结构，构件已摆脱了对底层应用环境和技术的依赖，使得构件在异构环境中也能实现复用，得以实现良好的可移植性。 随需应变的体验之美 在《敏捷软件开发》一书的序言中，罗伯特·马丁（Robert C Martin）曾这样形容美的软件：“（软件之美）在于它的功能，在于它的内部结构，在于团队创建它的过程。”然而美的价值最终在于体验，正像博尔赫斯所说的那样：风景在旁人看不到它的时候，便不能算是“风景”——因此我们有必要对罗伯特·马丁的看法作适度的修正：软件之美体现在结构与功能的协调之美，开发者与应用者的体验之美，团队协力创建的过程之美。 美的软件是软件企业和软件开发者的终极目标。 先来看看传统代码式软件。传统代码式软件，难以适应未来IT技术和商业环境的变化；基于代码的定制开发与客户需求的经常变动中间常常存在难以逾越的鸿沟，客户的抱怨、软件厂商的无奈往往宣告了大型软件项目的彻底失败。只能以“破而后立”的方式进行软件的升级——客户在支付了昂贵的信息化成本后，得到的却是一个有时空限制的、缺乏灵活性的软件：不用多久，客户便会发现，当业务需求激烈变化时，原有的软件系统是那样孱弱无力。客户固然不愿意两次踏入同一条河流（在同一个软件项目上重复投资），软件企业也未必喜欢推倒重来的“二次开发”。 在看面向构件的软件，它将具有足够的能力、足够的灵活性来管理变化、满足市场和客户的要求。“变化”不会给面向构件的软件带来挑战和危机，恰恰相反，“变化”能够充分展示面向构件软件的优势。通过“变化”，客户可以充分展示面向构件的IT系统的核心竞争能力。 谁说大象不能跳舞？谁说企业信息化只能千人一面？无论企业规模如何，面向构件的软件都能够支持敏捷的功能延展和丰富的“个性选择”。目前，传统的通用型企业级软件之所以频频出现僵化、狭仄和无法响应客户需求等许多问题，正是因为基于代码的应用软件在扩展性和个性化方面“能力有限”。面向构件的软件必然会令软件企业与客户双方获取到更其丰富美妙的开发及应用体验。 软件过程之美 软件过程之美，对于软件开发人员以及客户的意义是多重的：对软件设计者来说，能直观地分割、并具有最小内部耦合的软件结构是“简约之美”。对开发人员和管理者来说，生产无缺陷代码、并取得每周重大进展是“精致之美”。对用户来说，通过直观、简单的界面、准确呈现所选程序是“清晰之美”。 只有通过面向构件的软件开发方式，软件企业才能从产品开发过程中捕捉到美感——明确的分工将把一个巨大的软件项目分解成为若干个可控制、可管理的子项目；在大大降低项目风险的同时，提高了项目管理的可见度和可控度。 具体说软件的过程之美，主要体现在从时间到空间、从内涵到外延的不同侧面： 从时间控制看，传统流程由于分工不清楚，或者不同的分工间存在琐碎而复杂的关联，导致需求变化时，项目的时间进度和工程质量很容易像脱缰野马般失控。而面向构件的工程管理却不会如此，因为有大量的复用软件存在，分工也相对明确，项目的时间和质量自然就比较容易控制。 对软件的空间部署而言，传统软件项目部署管理往往只能在一些参数设置和有限的二次开发接口上完成，变化较大的业务需求无法得以满足；而面向构件的软件体系中，复杂的业务需求还可以在基础构件和行业构件上可视化组装完成，有较好的服务工程管理能力。 从产品内涵来看，在面向构件的软件体系中，产品由很多构件组成；只需要重组小部分构件，或添加小部分构件就能实现产品创新。 由内及外，个性化就是面向构件的软件产品的外在表现：在面向构件的软件工程管理中，由构件实现通用功能，由构件的选择、组装和配置实现个性化，轻而易举实现了软件的个性化需求的工程管理；传统软件产品则相反，连对单一个性化的用户需求变化进行有效表达，都无法实现，个性化功能和通用功能经常混杂在一起。 面向构件的软件是美的。通过面向构件的互联网应用基础平台，业务专家可以更专注去设想软件的功能，结构专家可以分离出通用的构件搭建美的软件，而面向构件的软件开发过程也更为和谐，更趋高效。 在今天，面向构件的软件体系和这个新体系中的基础平台带给我们的不仅仅是个性化的企业级互联网应用软件开发的效率，更重要的是其内涵，是其表现出来的软件美学。 “横看成岭侧成峰”，如果我们站在一个更高的角度审视软件，就会发现软件在面向构件之后，与知识存在许多相似之处：知识无限，组成软件的基本元素——构件同样无穷无尽。但只要掌握一定的知识，就可以进行无穷的探索；软件亦然，只要有一定数量的基础构件，就可以产生出不同的应用。比尔·盖茨有句话说得很对：软件的发展不存在所谓“极限”，其发展速度只会受到人的智力、想象力和创造力的制约。但我想，如果是基于过去那样一种成功率低、动辄令项目堕入焦油坑的软件研发思路，那么软件（尤其是大型行业应用软件）的发展其实早已遭遇到了“极限”——好在今天，面向构件的软件可以让我们轻松地超越极限，充分释放自己的智力、想象力和创造力。 应该庆幸传统软件体系的“基因”缺陷已被及时发现。应该欣喜面向构件的思想体系，能够将软件开发知识、行业业务知识整合到构件中进行管理。应该相信通过面向构件的软件的思想的实践，我们能够构建新的企业——知识企业，我们能够构建新的社会——知识社会。 当软件革命吹响涅磐的号角，让我们期待变革的风暴来得更加猛烈，让我们期待软件为信息化列车高速飞驰提供无尽动力，也让我们期待软件之美能够沁人心脾吧！