软件之美
软件建筑之美
新春伊始，北京的气温略有回升。周末，颐和园里到处熙熙攘攘，游人如织。昆明湖畔，万寿山边，有气势宏伟、层叠绵延的重廊复殿，有自然绮丽、神韵似水乡江南的园林；饱览湖光山色之余，不禁大为慨叹中国古建筑之美。实际上，颐和园的众多建筑，大都是由标准化的构件组合搭建而成。
古建筑之美在《营造法式》中大抵可以寻根溯源。该书成于北宋时期（约公元1103年），凡三十六卷，乃中国古代建筑学集大成之宝典。书中提出了一整套木构架建筑的设计方法，概括了当时的各种构件详图、规格、尺寸，以及生产各种材料构件的标准，和砖、瓦、琉璃的烧制方法等等——此书可说是颐和园建筑风格与建筑方法的渊源——通过建筑构件的分解和标准化，《营造法式》为中国古建筑的结构设计、工程管理奠定了基础。中国建筑之美，肇始于此。
感叹建筑之美的同时，我也在思考：能否找到属于软件体系的《营造法式》？
研究现在的软件体系，不难发现：现在的软件专家们仍需要与大量的需求、设计、代码的细节打交道。出于项目实施时间、投入资源等方面的限制，大型软件往往以实现若干个具体的用户功能需求为目标。专家们没有时间，也没有精力去追求软件的美学目标。日复一日，随着用户功能要求的变化，大型软件项目成为大量代码的随机而无序的堆积，奇丑无比。许多工程师一旦完成项目，就恐避之不及，不愿再去碰自己几个月来夜以继日的劳动成果。
而在面向构件的软件思想中，软件专家们则要幸运得多。他们不再需要不断重复具体的软件实现的技术细节；他们的工作更像一个软件建筑师；他们的思绪又重新集中到用户的切身业务需求上，围绕用户，如何用简洁的结构，搭建出一个个有个性、有美感的软件。
正如看风景。设想在昆明湖边，忽然下起雨来，你仍可沿着长廊绕湖徜徉，品味雨带来的几丝清韵；抑或寻一个八角亭，邀三五好友喝茶对弈。但说回到现今的软件，美感顿失；似有刀耕火种时期为一栖身之所而知足之嫌。也许终有一日，软件也会如昆明湖畔的风景，无论何时何地，都能让用户随心所欲体验互联网时代的万般精彩。
软件结构之美
从心理学角度说，人类对事物的认知大致经历了感觉、知觉，再到思维的渐进过程，这也是一个从具体到抽象的过程。一开始我们会根据物质的外延特性（如软硬、冷热、黑白）来“表达”物质，其后根据它的功能来“表达”，最终我们明白了所有物质的结构。
早在公元前五世纪，德谟克里特就提出了物质永远存在。他认为世界是由一个巨大的虚空和无数的原子组成。
1803年英国化学家道尔顿创立的原子学说，则从物理学的层面向世人揭示：“一切元素都是由不能再分割和不能毁灭的微粒所组成，这种微粒称为原子”；从此我们对事物的认识从原子、分子逐渐过渡到宏观层面。
这种对事物本质认识的进化，奠定了整个科学进步的基础。不管从哲学领域的原子论，还是物理学领域的原子论，我们都能清晰发现，西方表达事物的方式是个进化的过程，贯穿始终的仍是从本质出发，用分析的眼光关注物质的基本结构——那么，假如我们不再像以往那样功能化地审视软件，而是去关注其本质，关注其结构，是否会找到一条提升软件生产效率的新途径呢？答案是肯定的。
在不断变化、日新月异的业务知识范畴，面向构件的软件体系找到了一个可以固化软件知识的结构，即通过构件为人类建立有效积累和复用知识资源的途径——实质上，构件就是各种通用知识和业务知识的封装和复用。面向构件才能改善软件知识的生产和管理的质量，实现软件财富的有效积累，实现知识的管理与创新。
以构件形式“装配”而成的软件更契合软件企业及其客户的需求，同时也更具“美”的特征。评审软件的美丑妍媸，关键要考量软件的结构简洁与否，软件设计与实现可否快速应对业务需求的变化。基于这个标准，可以得出：代码式软件受制于开发方式和软件结构，因而不大可能呈现出“美”的特征；而面向构件的软件体系是依靠变化来获取活力，能尽可能保持干净、简洁的设计——这当然更接近我们对“美”的定义。
美的软件结构需要具备很好的复用性、可维护性以及可移植性。复用性好，能保证为开发者节省大量的资源；并摆脱基于代码的传统软件结构的晦涩难懂，建立方便维护的基础。较之传统代码式软件维护难、修改难的缺陷，面向构件的软件则清晰明朗，容易理解，还具有很强的可维护性。可移植性，在传统的软件体系中根本无从提及，软件体系自身与系统应用环境之间存在千丝万缕的关联，软件企业也无力解开繁复的关联纠结，剪不断理还乱；而采用面向构件的软件结构，构件已摆脱了对底层应用环境和技术的依赖，使得构件在异构环境中也能实现复用，得以实现良好的可移植性。
随需应变的体验之美
在《敏捷软件开发》一书的序言中，罗伯特·马丁（Robert C Martin）曾这样形容美的软件：“（软件之美）在于它的功能，在于它的内部结构，在于团队创建它的过程。”然而美的价值最终在于体验，正像博尔赫斯所说的那样：风景在旁人看不到它的时候，便不能算是“风景”——因此我们有必要对罗伯特·马丁的看法作适度的修正：软件之美体现在结构与功能的协调之美，开发者与应用者的体验之美，团队协力创建的过程之美。
美的软件是软件企业和软件开发者的终极目标。
先来看看传统代码式软件。传统代码式软件，难以适应未来IT技术和商业环境的变化；基于代码的定制开发与客户需求的经常变动中间常常存在难以逾越的鸿沟，客户的抱怨、软件厂商的无奈往往宣告了大型软件项目的彻底失败。只能以“破而后立”的方式进行软件的升级——客户在支付了昂贵的信息化成本后，得到的却是一个有时空限制的、缺乏灵活性的软件：不用多久，客户便会发现，当业务需求激烈变化时，原有的软件系统是那样孱弱无力。客户固然不愿意两次踏入同一条河流（在同一个软件项目上重复投资），软件企业也未必喜欢推倒重来的“二次开发”。
在看面向构件的软件，它将具有足够的能力、足够的灵活性来管理变化、满足市场和客户的要求。“变化”不会给面向构件的软件带来挑战和危机，恰恰相反，“变化”能够充分展示面向构件软件的优势。通过“变化”，客户可以充分展示面向构件的IT系统的核心竞争能力。
谁说大象不能跳舞？谁说企业信息化只能千人一面？无论企业规模如何，面向构件的软件都能够支持敏捷的功能延展和丰富的“个性选择”。目前，传统的通用型企业级软件之所以频频出现僵化、狭仄和无法响应客户需求等许多问题，正是因为基于代码的应用软件在扩展性和个性化方面“能力有限”。面向构件的软件必然会令软件企业与客户双方获取到更其丰富美妙的开发及应用体验。
软件过程之美
软件过程之美，对于软件开发人员以及客户的意义是多重的：对软件设计者来说，能直观地分割、并具有最小内部耦合的软件结构是“简约之美”。对开发人员和管理者来说，生产无缺陷代码、并取得每周重大进展是“精致之美”。对用户来说，通过直观、简单的界面、准确呈现所选程序是“清晰之美”。
只有通过面向构件的软件开发方式，软件企业才能从产品开发过程中捕捉到美感——明确的分工将把一个巨大的软件项目分解成为若干个可控制、可管理的子项目；在大大降低项目风险的同时，提高了项目管理的可见度和可控度。
具体说软件的过程之美，主要体现在从时间到空间、从内涵到外延的不同侧面：
从时间控制看，传统流程由于分工不清楚，或者不同的分工间存在琐碎而复杂的关联，导致需求变化时，项目的时间进度和工程质量很容易像脱缰野马般失控。而面向构件的工程管理却不会如此，因为有大量的复用软件存在，分工也相对明确，项目的时间和质量自然就比较容易控制。
对软件的空间部署而言，传统软件项目部署管理往往只能在一些参数设置和有限的二次开发接口上完成，变化较大的业务需求无法得以满足；而面向构件的软件体系中，复杂的业务需求还可以在基础构件和行业构件上可视化组装完成，有较好的服务工程管理能力。
从产品内涵来看，在面向构件的软件体系中，产品由很多构件组成；只需要重组小部分构件，或添加小部分构件就能实现产品创新。
由内及外，个性化就是面向构件的软件产品的外在表现：在面向构件的软件工程管理中，由构件实现通用功能，由构件的选择、组装和配置实现个性化，轻而易举实现了软件的个性化需求的工程管理；传统软件产品则相反，连对单一个性化的用户需求变化进行有效表达，都无法实现，个性化功能和通用功能经常混杂在一起。
面向构件的软件是美的。通过面向构件的互联网应用基础平台，业务专家可以更专注去设想软件的功能，结构专家可以分离出通用的构件搭建美的软件，而面向构件的软件开发过程也更为和谐，更趋高效。 在今天，面向构件的软件体系和这个新体系中的基础平台带给我们的不仅仅是个性化的企业级互联网应用软件开发的效率，更重要的是其内涵，是其表现出来的软件美学。
“横看成岭侧成峰”，如果我们站在一个更高的角度审视软件，就会发现软件在面向构件之后，与知识存在许多相似之处：知识无限，组成软件的基本元素——构件同样无穷无尽。但只要掌握一定的知识，就可以进行无穷的探索；软件亦然，只要有一定数量的基础构件，就可以产生出不同的应用。比尔·盖茨有句话说得很对：软件的发展不存在所谓“极限”，其发展速度只会受到人的智力、想象力和创造力的制约。但我想，如果是基于过去那样一种成功率低、动辄令项目堕入焦油坑的软件研发思路，那么软件（尤其是大型行业应用软件）的发展其实早已遭遇到了“极限”——好在今天，面向构件的软件可以让我们轻松地超越极限，充分释放自己的智力、想象力和创造力。
应该庆幸传统软件体系的“基因”缺陷已被及时发现。应该欣喜面向构件的思想体系，能够将软件开发知识、行业业务知识整合到构件中进行管理。应该相信通过面向构件的软件的思想的实践，我们能够构建新的企业——知识企业，我们能够构建新的社会——知识社会。
当软件革命吹响涅磐的号角，让我们期待变革的风暴来得更加猛烈，让我们期待软件为信息化列车高速飞驰提供无尽动力，也让我们期待软件之美能够沁人心脾吧！
