中国软件的致命缺陷是什么！

http://www.armsun.net/jack/article/show.php?id=58

引用

黄柳青专注于面向构件的互联网应用基础平台研究和开发工作，特别是在可视化构件技术方面获得了一定的成就。除此之外，在软件技术、数据库系统设计、计算机网略和通信技术、视频、图像处理和人工职能等领域，黄柳青拥有多项突出贡献，并在各级专业论坛和刊物上发表过数十万学术专著。

 

黄柳青博士曾是中国最早的互联网应用开发商亚信的CTO，早期他在开发电信互联网应用的时候，就发现了原来的代码开发模式存在很大的不足，很多精力经常浪费在底层WEB技术的代码开发上，而无法集中精力将应用做的更为顺畅和快速。于是，他和原亚信CEO刘亚东认准了这个方向，投资了5000万人民币，四年前促成了普元软件的诞生，埋头开发了三年推出了这个平台，现在已经得到了极大认可。

产业之变

黄柳青现在还是CTO，还是从事产品研发，只不过现在他是上海普元软件公司CTO，同时他也是《软件的涅磐》一书的作者。他在其力作中有这么一句令人震惊的言论：大型企业级应用软件已经死亡！代码式的软件最终将成为历史。

黄柳青认为，现在的软件生产方式属于手工作坊，基本靠定制、靠出卖劳动力，因此，软件生产方式、组织方式有必要向传统行业学习。

黄柳青断言，如果在未来三五年内不改变软件的生产方式、运作方式，国内软件产业必将举步为艰，甚至有全军覆没的可能。谈及该观点的依据，黄柳青在接受记者专访时表示，软件之死意味着企业关系管理市场、供应链、人力资源管理市场以及其他大型应用软件市场的终结，而这一观点并非耸人听闻。为此，构件专家黄柳青正不遗余力地宣传着这种面向构件的软件生产方式。

不仅热衷于布道，黄柳青现在还是新软件生产力的实践者。和三年前不同的是，黄柳青现在不是孤身奋战，在他所服务的普元软件的身前身后，已经出现了IBM、微软、BEA、金蝶等国内外厂商的影子。

黄柳青谈到，目前，国内传统大型企业应用软件有两种方式居多：编码式开发方式和一次开发方式。值得注意的是，两种方式都有致命的缺陷---编码式开发方式使得企业级应用软件的快速开发和实施难以实现；一次性开发持续运行的方式，则导致软件的严重僵化和应用的不适应。尽管有时两种方式的操作者会彼此攻击，但在用户看来，它们之间并无显著不同。黄柳青说。

显然，软件机构和生产方式需要变法，而应用对用户需要个性化而灵活的软件，从传统的软件体系中根本找不到解决问题的办法。

过程之美

两年前，IBM在行业内率先提出随需应变这个概念。在随需应变的背后，阐述的是用户内心的真实需要以及为满足这种需求而必须的商业概念。随后，构件商、面向构件技术应用商，业务平台商都纷纷想着打出一个属于自己的响亮口号，但最终却发现，再也没有比随需应变这个口号更能概括自身之于用户的价值。

而黄柳青在其著作《软件的涅磐》中提出，平台化、构件化以及面向构件的技术应用也是一条出路。我们的平台化、构件化与IBM的随需应变区别就在于平台化更面向用户业务逻辑，更关心用户管理结构。黄柳青解释。业内专家则认为，必须承认量身定制、随需应变是不断变革中的国内企业的本能需要，所以，也应该成为一种内在服务。也就是说，IT供应商首先应该是服务商，其次才是产品和解决方案提供商。

目前，黄柳青所主导的普元软件研发体系的做法是，在保障自身利益的前提下体现服务能力，一是构件化、标准化的产品；二是开展面向构件技术的应用。作为软件代码的集合体，构件可以完成一个或多功能的铁钉服务，也为用户提供多个接口，通过安装，不断在变化中随需应变。

没有人不对构件技术的应用前景心动，也很少有人愿意冒着成为垫脚石的风险开拓构件新天地。所有致力于面向构件技术应用的企业都知道，如果没有足够的号召力，在一个极度散漫的领域里一呼百应是不可能。

而眼下，除了布道、身体力行，以期唤起业界对构件美妙未来的认识外，黄柳青还希望更多厂商和客户能触电构件技术应用领域，以期顺利使得构件的概念深入人心。这也是他著书立说的目的之一。

标准不是你想建立就建立的，首先要把事情做起来。黄柳青不相信构件应用标准是随便就能解决的事情，他认为，现在更需要去扎实地实践，用诸多成功的案例来说服用户，所谓星星之火，可以燎原，在一个趋利性的环境中，判断一个事物成功与否的准则不在于由谁来推动，而在于其本身的价值。

黄柳青分析，面向构件软件产业地生命周期大致可以分为五个阶段：创新期、接受期、成熟早期、成熟晚期和衰退期。黄柳青认为，面向构件的软件生产已经过了接受期，明显标志是面向构件的软件研发思想开始商业化，单个厂商开始采用面向构件的软件生产方式。黄柳青同时承认，接受期和成熟期早期之间的鸿沟依然存在，构件理念由接受期向成熟期早期进化，还尚未形成生态链。

出路之门

普元软件公司是近几年面向构件技术应用的主导者和积极推动者。黄柳青承认，普元软件有不小的想法：既然面向构件的技术应用不失为软件的优选方案，既然代码式软件最终会成为历史，那么，普元就有大把地做大做强的机会。

在未来的十年里，我们将有幸目睹软件在面向构件的思想指导下不断发展、日臻成熟。代码式会成为历史，软件将以更优美的形式被表达、更优美的方式被生产，并在使用中获得更加完美的体验。黄柳青憧憬。

2003年是普元跨越飞跃的一年。在市场上，普元面向构件的技术应用引起了不小的震动，北方电信、河南移动、上海宝钢、招商银行等在同年相继成为普元的用户。

黄柳青在上海和一家政府用户沟通时，他们对普元的品牌印象并不很深，却对普元的EOS表现出兴趣。而经常听黄柳青演讲的用户记住了黄博士的构件，黄柳青对此也更坚定了信心。现在普元每年的销售额是100％的增长。

横看成岭侧成峰，如果我们站在一个更高的角度审视软件，就会发现构件与知识有许多相似之处：知识无限，组成软件的基本元素---构件同样无穷无尽。但只要掌握一定的知识，就可以进行无穷的探索：软件亦然，只要有一定的数量的基础构件，就可以产生出不同的应用。但我想，如果是基于过去那样一种成功率低，动辄令项目堕入焦油坑的软件研发思路，那么软件的发展其实早已遇到了极限---好在今天，面向构件的软件开发可以让我们轻松地超越极限，充分释放自己的智力想象力和创造力。黄柳青说。

 

=================================================================================== 

软件开发工具，可分为3个层次。

1. 语言级别。
即语法的威力。这个级别是最强大的。

2. 库、框架级别。
这个级别，用的最广泛。

3. IDE, Code Generation级别。

Visual Studio.net， Eclipse Plugin都是这一类。

--------------------

普元EOS使用了代码生成，脚本执行等，同时具有语言级别和IDE code generation级别的特点。
不过，通过一些用过普元EOS的朋友的印象，代码生成是主要方面。

我衷心希望普元EOS能够发展的好。
听说普元EOS获得了政府投资和扶持。听到这个消息，反而有些担忧。

普元面对的挑战至少有两个：

1. IDE
开发人员有个特点，不愿意花钱买IDE。
Jbuilder, Delphi这么好的IDE，结局都不是很好。

普元可以从 通用模块IDE 向 业务定制模块IDE的方向发展，来增加更多的附加价值。

2. Code Generation.

这个是最致命的缺陷。很容易被人诟病为概念炒作。

Interpreter is over Code Generator。

meta programming的最高层次是 语言级别直接解决，比如，smalltalk, ruby, python, 还有其他reflection 支持的非常好的语言。
甚至 STL 等 template 技术，也可以算作语言级别。

Code Generation 是最低级别的meta programming解决方案。技术含量也最低。

这个级别必须超越，才能够真正达到质变，完全跳出概念炒作的层次。

 

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1531060