试述样本程序比赛的几个理由

在以从事“行业应用软件”开发为主的软件企业中，大部分的工程师做的是一种定制化“脚本”性的工作。虽然这种编程上手并不困难，因为它的本质是一种“集成”性的工作，但由于“集成”的对象和涉及的内容非常之多，决定了它不只是一个技术性的问题，而且涉及管理、工程化、行业知识、个人表达能力等一系列问题，所以“做好”并不容易，而一个设计良好的“样本程序”可起到事半功倍的效果，这就好比初学做古诗，古诗学的约束要素有很多。我们可以学习各种格律的约束规则，也可以直接学习古人的“经典作品”，以这个“经典作品”为“样本”，试着完成自己的诗作。当然，样本程序的学习与做古诗还是有区别的，后面我们还会介绍。那么在软件企业中进行样本程序的比赛究竟是为了什么呢？它的意义何在？我们试着给这样的比赛提出几个切合实际的理由。

1、 应用软件脚本的标杆作用

　 这里的“脚本”本身是集成和组装的含义。就像我们制造一个桌子，组装和组件我们是可以分得清的基本概念。从理解和学习角度上看，我们可以分类组件，也可以按流程划分组装的特性和特点，但是更直接的方式是选择其中一种经典的组装方法，从头到尾组装一遍，给学习者有更直观的印象，这种“从头到尾的组装”就是样本程序。结合样本我们可以介绍组装的约定和约束、组装的风格选择、组装中的注意事项、组装中的分情形变化……。以往我们太注重组件的构成原理，而忽视组装中的各种独特性，这实质上是“面向对象”和“面向过程”之争的延续。其实软件“重用”一直在两个大的层面发展，即“相似”和“共享”。“相似”以过程体的组装相仿特性为主，“共享”则是以组件或函数的方式存在。相比之下，“相似”反映概念层面的“重用”更多，它以一种概念结构、框架、模式……的相似、相仿为主要特征，它确实不是“相同”，这也是为什么这部分内容给知识产权的确定也带来一定的挑战的原因。

在我们的生活中，也有类似的直观实例。如：“宜家”的购物方式，买房子的“样本间”（奇怪的是买回家去，好像总是没有当时看到的效果好！）。相对于目前流行的“框架”和“模式”,我们以样本程序为基础讨论行业应用软件的“结构”，显得更为直观。因此，以“面向过程”思想为主体的“精心制作”的样本程序在行业应用软件开发中的标杆作用是显而易见的。本次比赛我们主要针对企业开发中常用的J2EE平台进行，我们只是通过样本程序讨论了“面向过程”的思路，而没有就脚本语言的使用展开更多的讨论，实际上这部分内容也在被人们逐渐的重视，将其与现有流行的开发工具相结合，又将是一个新的技术热点。一个好的样本程序经过分段分析可形成一定的标准化，进而通过工具完成自动生成能力，目前流行的“领域驱动”的软件开发实质上就是对这部分内容的一种尝试，而过程化支持的工具平台，也成就了另一个新的技术热点，即BPM（业务过程管理）工具平台。在实践中，对业务流程管理的样本程序和“抄”它的程序进行统一管理的方法，我们称为“全业务流程管理”，这使应用软件具有更好的可配置和可扩展性。总之，好的样本程序反映一种自然的规律，它既是“写”出来的，又好像是“发现”出来的。因此也构成了一个比赛的亮点，我们把它作为比赛的第一个理由。

2、 组织管理中的机制创新

以行业应用软件开发为主体的软件企业，面临着严重的技术组织困难。由于服务对象分散，它的管理有点像医生们看病/治疗，当病种快速变化，患者背景日趋复杂时，看病的流程和使用技术方法虽然类似但并不相同，其存在的最大问题是交流太少、各自为政。在软件企业内部，我们通常有一定的组织体系，典型组织结构是部门和项目组，样本程序的技术形成于这种组织之内。虽然很多企业也有CTO和研发中心之类的角色和机构，但是由于服务性质和专业分类的差异，很难统一控制这种分散的特征，无论从组织权力/义务划分上看，还是从业务决策角度来看，总裁、部门经理、项目经理都是权力的主轴。在技术决策方面，我们面临着权力/义务关系相互平衡的困难，这就造成CTO的执行力度是有限的。当部门经理和项目经理业务压力变大时，他们往往会降低对技术决策的重视程度，技术问题的决定权就分散落在了企业内部部门和项目组的技术“山大王”中了，这些“山大王”在组内是技术上的权威，基础的技术文档一般也是他们的杰作，其格式也是百花齐放。这样做的好处是可以统一局部的方案，坏处是没人与其讨论推敲，甚至组织内部有些工程师多一事不如少一事，懒的与他们讨论，这就使他们自己和各级单位的技术发展遇到了挑战。到底是以CTO们做的决策为主，还是以“山大王”们的决策为主，变成了这类软件企业的一个困境！

举行样本程序比赛就是试图解决这样的问题，就是在更大的空间内制造一个平台，加强更大层面的沟通和交流，甚至是争辩，以提高“山大王”们的水平，这是一种组织结构形式的“放权”。我们也知道“开源”的放权更大，效果也很好，值得我们借鉴！以类似的形式让“山大王”们集体竞争决策。通过比赛交流，使某一分项的获胜者成为这一部分技术方案的决策者，避免了CTO由于脱离一线的实践，而引起的技术决策问题。从表面上看，CTO和各级技术领导从决策者变成了一个“平台”的维修工，但是协调和引导本身就是他们的主要工作，这其实并不简单！在保证约定一致的基础上，用竞争的方式形成技术决策是此类软件企业技术管理的重要创新，从而带动整体行业应用软件技术水平和管理水平的提高。技术交流和比赛，表面上是“山大王”们的竞争，而本质上是他们之间相互学习，共同促进，并稳定已有的技术成果，从而形成更大范围的技术规范。当条件成熟时，结合CTO们的工作，可形成全公司范围的相对稳定的技术标准和技术规定。随着企业内更多的不甘平庸的员工加入到各种分项的“山大王”行列，具有更强综合实力的“山大王”通过竞争成为了新的“山群之王”，企业的技术“复合”人才队伍就是这样被不断的壮大了。“山大王”们的动力不只是企业给予的奖励，而是一种成功的自我满足和在团体中获得的声望和荣誉。

3、 技术框架运用的交流

目前的B/S结构编程有其固有缺点。以J2EE基础开发为例，样本程序要使用各种各样的框架，如（Ajax, Struts, Spring，Hibernate等……）。每一个框架介绍起来都有厚厚的一本书，都需要使用者熟悉它们的每一个使用细节，而且新的框架还在不断的涌现和升级，搞得“山大王”们也颇具困惑。他们不禁要问：不用这些框架行不行？有了它们到底有什么好处和不足? 即使用了它们解决了目前工具的一些不足，但又会带来什么样的副作用?在缺少沟通的环境下，样本的制定者显得十分孤立。框架这部分内容有时看起来也是最具技术的一部分，很多新的术语和概念往往会使许多初学者似懂非懂，甚至感到十分神秘，部分“山大王”也因为似乎能说一些新的术语而自鸣得意。可实际上，这部分内容介绍的时候恰恰需要的就是通俗易懂，很多所谓的“深奥”，只能是自己没想明白，或者表达不好，因为最好的印证是同样的功能在过去C/S结构和4GL编程时都没有这么复杂。

框架的应用很多来源于分层概念的使用，典型的说法是MVC和三层结构。一段时间以来，分层的趋势越来越流行，分层的确带来了很多规划上的好处。如：结构清楚，发现局部问题或测试容易，“事务”加入规划点明确……特别是还有层间的协调。但分层也有它的不足，最主要的是数据传递量增大。因为层与层之间要不断的交换数据，特别是当这种数据是一个“数据块”时，矛盾就变得更加突出。实际上，这种“数据块”有两个变化方向。纵向是列，涉及领域内容，我们将在下节讨论如何应对它的变化；横向是行，涉及“数据块”的记录行集合。简单的说就是记录行集合类似“游标”的管理，或是类似动态数组的功能的管理，这就引出了所谓虚拟“数据块”操作问题，它的更复杂形式是涉及整体的领域概念所引出的主/从结构、或更复杂的“数据块”之间的关联，这就要求我们在基础技术层面先解决“数据块”的虚拟操作问题（当这类问题反映在表示层面的时候，也引出了我们称为Portal框架的一部分重要问题）。很多时候使用框架就是为了解决这类问题，因此我们要能在样本程序中看到它的实现机制。而在现实中，我们很多样本程序对框架的使用，只用了其中的最简单的部分。就像拿菜刀当锤子用，一样能钉钉子，但没有充分发挥出菜刀的优势。由于“数据块”问题涉及领域对象和技术支撑的交汇，它应该引起我们足够的重视，特别是“数据块”的传递，全局性存取是样本程序中必须讨论的问题。另一个重要的使用框架的原因不是由于分层，而是在于编程的通用性。在我们的应用程序中要大量使用这种特性，即“配置文件”方法。这好比“开着车换轮胎”，也就是说，程序的修改只改配置文件，而不用修改源程序，也不用重新编译、连接和部署。实际上，Web服务从环境上主要解决这类问题。但是如果在应用软件中大量使用这种方法，也会引起一系列问题，如：配置文件编辑方法及它的有效性和完备性检查，数据类型检查和“反射机制”的支持以及运行效率等。总之，样本程序即使不使用框架，也要看它对以上各方面内容的处理。

凡此种种，直接导致的问题是新的开发者编程学习门槛变高，相应的培训变得更加困难。很多“山大王”由于接近开发一线，工作非常忙，学习和理解如此多的框架也毕竟时间有限、理解有限，所以对很多从书上或网上抄的术语也会一知半解，对很多术语也未认真考虑过它真实的含义和为什么这样命名，所以在我们的样本程序中，经常看到通用的命名，如：Application ,Delegating , Facade……，在具体应用中它们应该有更针对领域的命名。加之，目前的现状是很多框架各成体系，把它们“串起来”的讨论反而不多。这就形成了我们样本程序的需求，而比赛可以使这项工作有一个稳定细致的推进。

4、 理解行业应用软件领域知识的重要性

应用软件很大一部分是行业应用软件，而行业应用软件涉及不同的行业，具有很强的领域特点。领域模型是行业应用软件的重要基础，这类应用软件在编写上是以领域模型为“龙骨”的，也就是说当技术平台升级或革命了，以领域模型为基础的行业应用软件应当变化最小，这样才能最大限度的保护我们行业应用软件的核心价值。我们认为领域模型是更高层面，更持久的行业应用软件模型，也是我们更要引起重视的部分。虽然我们会另文讨论领域模型的构成，但是在这里我们要简单说明领域模型影响样本程序的要点，简单的看领域模型影响样本程序的结构（命名）和行为（逻辑）。在行业应用软件中，我们要为操作对象和函数命名，为了便于在概念变化时更好的把握它们，我们以领域模型中定义和通行术语为基础，形成概念体，去命名相应的对象。从对象的特点上看，“领域”的对象和系统软件中的对象有不同特性。领域中的对象有经常变化的倾向：如：存货、存款……它们有可能随时间的变化而在内容和结构上变化，而系统软件中的对象，如：内存、进程、文件……则相对是稳定的。如果我们同样的做样本程序，在行业应用软件中，我们就要考虑样本程序中如何表达这些领域对象，如何控制它们的变化，如何在相似的情况替换上另一个相似的概念对象……。

由于领域对象的易变性，我们在样本程序中应可以看到这种变化的应对策略。从结构上看，如果领域对象的结构变化了，我们如何使用一种可变的Schema（它也对应表示层的结构及界面结构）来解决,应用程序是基于Schema编制的，当结构变化时，我们修改Schema，使整个程序变化最小。同样针对领域概念形成领域行为范围来对应不同分类的组件体，当行为变化时，只控制修改相应的部分。这部分内容实质上是行业应用软件的热点技术“业务产品化”的重要基础。我们期待看到样本程序对这部分内容的讨论。

现阶段的很多样本程序大多抄袭了框架书中的范例，对这部分内容的考虑是比较欠缺的。同样道理在我们以领域模型为基础的样本程序中，也很少讨论程序的行为逻辑与领域的“业务逻辑”的相符度，提出一整套对这种逻辑的标识（命名）分类，变化控制，替换原则……，一个好的样本程序应当可以看到这种涉及领域背景的“龙骨”。

5、 组件及组件化规划

样本程序由于它的“集成”特征，除了具体使用的开发工具外，就是人们已经编好的、准备被今后大量重复使用的相对通用的程序，这就是所谓的组件。前面我们也介绍了软件“重用”在两个大的层面发展，即：

组件：（共享），典型的有：组件/函数/SDK/API/平台……

组装：（相似）,典型的有：脚本/剧本/程序/宏代码/外挂代码……

样本程序是组装，组件与它的关系是显而易见的，而且当前的组装结果可能成为新的组件，以便下一步的组装使用。这就好像你中有我，我中有你。但是这也产生了所谓的组件规划问题。在样本程序中，我们反映的是具体行业应用软件的编制，我们首先关心“大粒度”的通用组件甚至是通用系统。它们有代表性的是：代码管理、显示和打印组件、权限管理、工作流引擎、计算引擎、异常处理组件、接口平台组件……。样本程序是以“调用”或使用这些基本功能为基础的，在我们的样本程序中应该对这部分内容有良好的描述。样本程序在集成这些组件的过程中，可以更多的关注集成中的“全局”特性和组件使用的范例说明。进一步说，组件的规划是以“面向对象”的思想进行指导的，在“小粒度”的时候我们更注重对象的封装，接口的说明，它一般是非过程性的。但是到了“大粒度”，我们除了继承“小粒度”的要求外，还要加入组件使用时的步骤和环境的说明，它一般是以过程性为主的。这就好比学法律，你既要知道法律的条文（组件约定），又要学习按法理学分类的案例（样本程序），这也叫做判例法。由于这种方法生动具体，便于学习，克服了死背条文的困难，它也成为了英美法系的重要基础之一。追根寻源，我们的先人明太祖朱元璋皇帝也在600多年前发明了类似的“犯罪案例及处理集”—《大诰》。

虽然，从目前看，“面向对象”为主技术较之“面向过程”为主的技术，更受推崇。这是因为一直以来美国的软件技术和软件企业是世界软件发展的主流，而他们又以系统软件产品为主要发展对象，应用级软件还是处于次要性的地位，所以与样本程序相对应的术语也好像不是很统一。在有一定约束条件下，我们看到了很简单的说明，如：Reference application，Sample application。可以简单的预见，随着软件产品更多的向服务转移和应用软件的地位不断加强，类似样本程序的“范例流程”一定成为软件服务的主要工具。到时候，新的名词和术语会突然蹿出。我们拭目以待!

6、 平台和工具的运用技巧

写任何程序离不开平台和环境，样本程序应该对“通用”开发和运行环境有所描述。对开发程序所使用的“语言平台”归纳具体“使用手册”和“参考手册”。“参考手册”是该语言的语法结构及使用说明，它是以“面向对象”为主的方式表达的。“使用手册”是如何使用该语言的说明，它是以“面向过程”为主的方式表达的。从学习的技巧角度来看，我们一般是先看“使用手册”，发现细节不清楚时，再查看“参考手册”。在做样本程序的时候，为了使关键的文档量下降，往往直接说明引用的参考文献和网站，这样相当于我们用引文的方式介绍了“参考手册”，以此减少我们的文档量。

样本程序实质上是以“参考手册”为基础，把单纯面向编程语言的“使用手册”中所举的“范例”，变成我们开发组结合具体应用背景的范例，即样本。由于我们使用的编程语言更多的考虑的是“通用”特征，所以我们应该针对我们的具体情况编出一些新的样本程序的“语句”，即基本组件。在一些局部条件已知或缺省的条件下，也可能使用一定的生成代码工具，去生成组件或组装脚本。对这些整体环境的讨论我们又可以结合一个IDE（集成开发环境工具）工具进行，在样本程序的介绍中，我们应该可以感到Eclipse, Jbuilder之类工具的使用并说明引用它们的具体版本及文档出处。总之，在做样本程序时我们应当看到对IDE工具、开发语言、基础通用函数……的介绍，从而使大家感到这样的样本程序是可以实际运行的。

7、 个人团队能力的培养

样本程序本身也是程序文档的一部分，这就考验我们行业应用软件的文档能力。它包括文体的构成，框架思路，文字的准确。由于工程师们对文档的困惑，样本程序可以给文档工作提供一个“范本”，促进整体文档的质量水平。

样本程序的“比赛”也强调一种对峙条件下的技术表达，考验我们选手的思路、态度、语言等一系列情商能力。一段时间以来，技术经理们在争辩时往往显得比较“单纯”，不太经得起不同意见或批评，在急于争辩的时候容易走极端，这在技术交流中显然是要克服的。通过比赛的评判可使他们明白：理解他人思路和说服他人方式的重要性，把心里明白和表达清楚结合起来，把让别人听的明白与自己的观点结合起来，把动机和效果结合起来。由于一个应用程序的内容庞大复杂，各种角色的沟通能力和说服能力显得尤为重要，比赛就是为了提高这种综合表达能力。

无论是个人/团队在企业中都有一个潜在的竞争，这种比赛形式还培养他们的集体荣誉感和个人成就感，培养他们勇争第一的素质，在目前激烈的市场竞争环境下这种素质是取得成功的关键因素。同时比赛也是一个团体项目，它也考验我们团队的共同准备能力，论辩时的相互策应、相互补充等的战术意识。

8、 应用软件开发的过程管理要求

应用软件开发除了组织管理创新外，也要考虑过程管理要求。样本程序是过程管理的重要工具，其核心目标是保证整个行业应用软件的质量和效率。也就是说我们要在样本程序出来后，用管理的手段保证我们的程序员所编的其它程序与样本程序的符合度，俗称“抄”。抄样本程序是我们做样本程序的真正的目的。统一的编码与做古诗不同，我们要最大限度的减少编程人（作者）的差异，只反映业务内容本身的差异。抄样本程序也是对传统软件开发方法的一种改良。

传统的软件开发一般的过程是：

需求分析——概念设计——详细设计——编码——修改循环

使用抄样本程序的思路是：

需求分析——找相似样本程序——抄（加替换修改）——反生成设计文档

它的优点是抄在先，替换修改在后。并且是“以源程序为核心”形成文档。这是近年来相对占上风的一种观点的反映，源程序与文档的关系有时像明细表与汇总表族的关系一样，明细表是矛盾的主要一方。换一个角度说，样本程序反映设计＋“工艺”，工艺是编程的细节，样本程序恰好反映设计＋“工艺”的平衡。按传统观点期望UML工具可以直接产生程序，这就好比从设计的汇总表加上一些约束产生明细表一样，总是有点捉襟见肘。回想一下，UML的核心主要是类图，协同图和用例图，在程序级的工艺要求上显然是不够的，由此也可以说UML工具确实是侧重设计的。而“样本程序”是从设计过滤到工艺的重要工具，另一方面，从发展看我们的工艺本身也在不断发展，汇编语言的工艺和高级语言的工艺有了巨大的变化。在行业应用软件中，我们的基础语言是工艺细节最少的高级语言，外加大量的行业组件，它的程序经过规划后，在一般专业水平的人来看就是设计思想的最好表现。

样本程序方法的不足是你得有这么多的相似样本程序，还要人工的识别出来，这就是我们说要“抄”的难点，也是样本程序方法的根本局限性！由于“抄”的样本并不总是合适，所以“抄”的方法也同样有局限性。一旦没有可“抄”的样本，我们还是回到了传统的道路，从详细设计，结对编程到代码走查，无非是想成为新的“样本”，我们的样本也是想让更多的人参与讨论程序所涉及的问题，参与程序各阶段的纠错。所以项目管理者要严格掌控“走新路”的程序，尽量让熟手上马，形成新的样本程序雏形。再退一步说，即使不能直接的“抄”，也还存在间接“抄”的作用，因为各种编程约定、关键点的考虑，也构成“仿”的基础。所以我们今后的样本程序也像“模式”的运用一样，分成不同的类型分别讨论。

从工程管理上看，“抄”的必要性真是太大了。首先，我们要约束工程师开发应用软件的自由度，它也是很多地方生成代码的开端，其次,很多的应用软件（脚本），体现了一种已有成果的积淀，是重要的知识沉淀。应用软件开发时往往会动一处而涉及全局，而“抄”是最安全的选择。“抄”也是可以使我们的软件更快、更早的与用户见面的方法。我们不能去反复试验，这也是为什么近年来流行Migration（迁移）项目。关于“抄”的执行管理从责任上应从“山大王”们返回企业权力的主轴，即部门经理和项目经理是主要的责任人，只有这样才能平稳推进这项工作。在有力的完成了这项工作之后，各级主管会发现一个喜出望外的成果，那就是有了相同的样本程序，有了相同的“抄”的管理经验，这就使各级主管拥有了集中兵力打歼灭战的能力。进而可以创造以一个小组团队加上“内包”其它小组群的支持与一个竞争对手（大公司）相对抗的能力。对于一个涉及多个不同行业应用的软件开发企业，太需要这样的能力了！

既然是“抄”，那么人们不禁要问，最初的样本程序是什么？样本程序错了怎么办？实际上样本程序可以从一个相对简单的初态开始。即它可以是在特定领域中，经过“山大王”的认真讨论，完成某一个用户需求的、一个典型的（有代表性）、完整的应用程序。更重要的是，样本程序的初期质量也不一定太高，因为我们看重的不只是它的质量，而是它的“一致性”。如果不好或者错了，它们的不好点和错误点是一样的。

软件过程管理的核心，是先定规则再进行符合度检查和有效性评估。企业过程管理中核心的要求有两点：一是内控机制的建立；二是执行有效性评估。样本程序的有效性评估也恰恰反映说明样本程序不是一劳永逸的，而是要在实践中不断丰富和完善的。开始的时候样本程序可能是相对单一的，但随着应用的深入和管理的要求，它们变成样本程序“族”并附加了很多的使用说明。对所有参与“抄”的编程者，我们都要有“精益求精”的态度。当我们在“抄”的过程中，发现不方便、不合理的地方，应该大胆的提出来、修改完善样本程序，最终也减少“抄”的工作量。对监督“抄”的管理者，今后也要形成更多的管理规范，并使用一些自制工具去自动化的检查“抄”和“仿”的符合度。作为比赛我们要看到它的工程化实用的痕迹，换句话说，你的对手和评委会问你：你真的在使用吗？你使用的效果如何？……。这种比赛也可以使那些说的好的，做的弱的“两层皮”状况得到改进，我们的评委们可以从一个新的程序员角度去盘问样本程序的使用状况，如果它用得好，大家会很容易的感觉到。

总之，进行一次比赛不可能期望有很多收获。作为一个IT从业人员，通过比赛我们可以看到一个更加活跃的技术讨论方式，并以此去引发我们对日常技术工作中遇到的各种问题展开思考。

当我们的软件企业像印度软件公司一样，快速的从几百人发展到几千人时，技术和组织的管理问题必然成为我们面前的一个新的课题。样本程序的比赛也引发了软件企业深层的管理问题，即如何研发或开发我们众多的行业应用软件。归纳起来有主要三方面的问题：

1、谁有资格去研发或开发（样本）？

——自告奋勇者？自我感觉良好者？高学历者？项目经理？编程时间长者？……

2、以什么形式去研发或开发？

——研发中心？研发小组？技术高手？……

3、研发的风险如何控制？

——骨干人员流动，研发者无水平，低效率，不了解一线，没干劲，无成果。……

通过样本程序的比赛我们似乎受到了启发，并可以尝试如下的解决方案：

1、谁有资格去研发或开发（样本）？

——那些做事踏实、勤奋学习、善于沟通并在比赛中获胜的“山大王”们！

2、以什么形式去研发或开发？

——类似开源“集市”的组织管理方式（扁平化的）！

3、研发的风险如何控制？

——在统一技术标准下，多小组、多人的竞争协作机制！

而CTO们和各层管理者的工作重点转向了：设定实用的规则，确定正确的内容，组织交流和比赛，选拔培养相应的人才，整理统一的技术标准和参考范本，检查和考评样本（范本）执行的实效性。对此他们应该是强有力度的协调者。用当今时髦的说法，这叫“知识管理”。看来进行类似样本程序的沟通和比赛真是我们的当务之急。

本文所说的所谓“比赛”理由，也是从几个大的方面讨论行业应用软件开发所经常遇到的问题，其目的是使我们从纷乱的新名词、新术语中解放出来，看清它的本质，看清它通俗易懂的一面，并以此为思路，带你进入一个“华山论剑”式的讨论方式。在这里人们将会看到不同技术观点的碰撞，互动式的商榷。参与其中的活动，哪怕只是一个听众也会使你享受专业人士那独有的快乐。这种比赛初期是跨项目组，跨部门的。今后我们要发展成跨公司，跨国界。这样才能使我们的各方面的水平有更好的发展。

我们大家都知道，行业应用软件是国人立足于世界软件之林的最好机会，我们的努力是会有结果的。

　　　　　　　　　　　　　　　　　　　　　　　　　　　2006年　秋