当软件企业快速地从几百人发展到几千人时，技术和组织的管理问题必然成为一个新的课题。样本程序的开发和交流也引发了软件企业深层的管理问题，即如何研发或开发众多的行业应用软件。

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

组装软件

就像我们制造一个桌子，组装和组件我们是可以分得清的。从理解和学习角度上看，我们可以分类组件，也可以按流程划分组装的特性和特点，但是更直接的方式是选择其中一种经典的组装方法，从头到尾组装一遍，给学习者有更直观的印象，这种“从头到尾的组装”就是样本程序。

结合样本我们可以介绍组装的约定和约束、组装的风格选择、组装中的注意事项、组装中的分情形变化……以往我们太注重组件的构成原理，而忽视组装中的各种独特性，这实质上是“面向对象”和“面向过程”之争的延续。其实软件“重用”一直在两个大的层面发展，即“相似”和“共享”。“相似”以过程体的组装相仿特性为主，“共享”则是以组件或函数的方式存在。相比之下，“相似”反映概念层面的“重用”更多，它以一种概念结构、框架、模式等的相似、相仿为主要特征，它确实不是“相同”，这也是为什么这部分内容给知识产权的确定也带来一定挑战的原因。

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

让“山大王”做技术决策

把样本程序拿出来进行讨论就是在更大的空间内制造一个平台，加强更大层面的沟通和交流，甚至是争辩，以提高“山大王”们的水平，这是一种组织结构形式的“放权”，避免了CTO由于脱离一线的实践，而引起的技术决策问题。

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

从表面上看，CTO和各级技术领导从决策者变成了一个“平台”的维修工，但是协调和引导本身就是他们的主要工作，这其实并不简单！在保证约定一致的基础上，用竞争的方式形成技术决策是此类软件企业技术管理的重要创新，从而带动整体行业应用软件技术水平和管理水平的提高。

更好地利用框架

目前的BS结构编程有其固有缺点。以J2EE基础开发为例，样本程序要使用各种各样的框架，如Ajax、Struts、Spring、Hibernate等。每一个框架介绍起来都有厚厚的一本书，都需要使用者熟悉它们的每一个使用细节，而且新的框架还在不断涌现和升级，搞得“山大王”们也颇具困惑。他们不禁要问:不用这些框架行不行？有了它们到底有什么好处和不足?即使用了它们解决了目前工具的一些不足，但又会带来什么样的副作用?

在缺少沟通的环境下，样本的制定者显得十分孤立。框架这部分内容有时看起来也是最具技术的一部分，很多新的术语和概念往往会使许多初学者似懂非懂，甚至感到十分神秘，部分“山大王”也因为似乎能说一些新的术语而自鸣得意。可实际上，这部分内容介绍的时候恰恰需要的就是通俗易懂，很多所谓的“深奥”，只能是自己没想明白，或者表达不好，因为最好的印证是同样的功能在过去CS结构和4GL编程时都没有这么复杂。

抄样本程序是我们做样本程序的真正目的。统一的编码与做古诗不同，我们要最大限度地减少编程人（作者）的差异，只反映业务内容本身的差异。抄样本程序也是对传统软件开发方法的一种改良。

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

沉淀、传递行业知识

应用软件很大一部分是行业应用软件，而行业应用软件涉及不同的行业，具有很强的领域特点。领域模型是行业应用软件的重要基础，这类应用软件在编写上是以领域模型为“龙骨”的，也就是说当技术平台升级或革命了，以领域模型为基础的行业应用软件应当变化最小，这样才能最大限度地保护我们行业应用软件的核心价值。

我们认为领域模型是更高层面、更持久的行业应用软件模型，也是我们更要引起重视的部分。在这里笔者简单说明一下领域模型影响样本程序的要点，简单地看，领域模型影响样本程序的结构（命名）和行为（逻辑）。在行业应用软件中，我们要为操作对象和函数命名，为了便于在概念变化时更好地把握它们，我们以领域模型中的定义和通行术语为基础，形成概念体，去命名相应的对象。从对象的特点上看，“领域”的对象和系统软件中的对象有不同特性。领域中的对象有经常变化的倾向，如:存货、存款等，它们有可能随时间的变化而在内容和结构上变化，而系统软件中的对象，如内存、进程、文件等，则相对是稳定的。如果我们同样地做样本程序，在行业应用软件中，我们就要考虑样本程序中如何表达这些领域对象，如何控制它们的变化，如何在相似的情况下替换另一个相似的概念对象。

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

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

组件要有良好规划

样本程序由于它的“集成”特征，除了具体使用的开发工具外，就是人们已经编好的、准备被今后大量重复使用的相对通用的程序，这就是所谓的组件。样本程序是组装，组件与它的关系是显而易见的，而且当前的组装结果可能成为新的组件，以便下一步的组装使用。这就好像你中有我，我中有你。但是这也产生了所谓的组件规划问题。

左春

中科院软件研究所研究员，中科软科技股份有限公司总裁。长期从事计算机和计算机辅助软件工程的研究和开发。主持开发了《保险业务综合管理信息系统》系列软件产品，这些软件目前已经推广到全国一半以上的保险公司，并成功进入香港市场。

在样本程序中，我们反映的是具体行业应用软件的编制，我们首先关心“大粒度”的通用组件甚至是通用系统。它们当中有代表性的是:代码管理、显示和打印组件、权限管理、工作流引擎、计算引擎、异常处理组件、接口平台组件等。样本程序是以“调用”或使用这些基本功能为基础的，在我们的样本程序中应该对这部分内容有良好的描述。样本程序在集成这些组件的过程中，可以更多地关注集成中的“全局”特性和组件使用的范例说明。进一步说，组件的规划是以“面向对象”的思想进行指导的，在“小粒度”的时候我们更注重对象的封装，接口的说明，它一般是非过程性的。但是到了“大粒度”，我们除了继承“小粒度”的要求外，还要加入组件使用时的步骤和环境的说明，它一般是以过程性为主的。

用“手册”规范开发

写任何程序离不开平台和环境，样本程序应该对“通用”开发和运行环境有所描述。对开发程序所使用的“语言平台”归纳成具体的“使用手册”和“参考手册”。

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

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

文档也要“抄”

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

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

“抄”出质量和效率

应用软件开发除了组织管理创新外，也要考虑过程管理要求。样本程序是过程管理的重要工具，其核心目标是保证整个行业应用软件的质量和效率。也就是说，我们要在样本程序出来后，用管理的手段保证我们的程序员所编的其他程序与样本程序的符合度，俗称“抄”。

抄样本程序是我们做样本程序的真正的目的。统一的编码与做古诗不同，我们要最大限度地减少编程人（作者）的差异，只反映业务内容本身的差异。抄样本程序也是对传统软件开发方法的一种改良。

传统的软件开发一般的过程是:需求分析→概念设计→详细设计→编码→修改循环。使用抄样本程序的思路是:需求分析→找相似样本程序→抄（加替换修改）→反生成设计文档。

它的优点是抄在先，替换修改在后。并且是“以源程序为核心”形成文档。这是近年来相对占上风的一种观点的反映，源程序与文档的关系有时像明细表与汇总表族的关系一样，明细表是矛盾的主要一方。这种方法的不足是，得有这么多的相似样本程序，还要人工地识别出来，这就是我们说要“抄”的重点。由于“抄”的样本并不总是合适，所以“抄”的方法也同样有局限性。一旦没有可“抄”的样本，我们还是回到了传统的道路，从详细设计、编程到代码走查，无非是想成为新的“样本”，我们的样本也是想让更多的人参与讨论程序所涉及的问题，参与程序各阶段的纠错。所以项目管理者要严格掌控“走新路”的程序，尽量让熟手上马，形成新的样本程序雏形。再退一步说，即使不能直接的“抄”，也还存在间接“抄”的作用，因为各种编程约定、关键点的考虑，也构成“仿”的基础。所以我们今后的样本程序也像“模式”的运用一样，分成不同的类型分别讨论。从工程管理上看，“抄”的必要性真是太大了，很多的应用软件（脚本），体现了一种已有成果的积淀，是重要的知识沉淀。应用软件开发时往往会动一处而涉及全局，而“抄”是最安全的选择。“抄”也是可以使我们的软件更快、更早地与用户见面的方法。我们不能去反复试验，这也是为什么近年来流行Migration（迁移）项目。关于“抄”的执行管理从责任上应从“山大王”们返回企业权力的主轴，即部门经理和项目经理是主要的责任人，只有这样才能平稳推进这项工作。在有力地完成了这项工作之后，各级主管会发现一个喜出望外的成果，那就是有了相同的样本程序，有了相同的“抄”的管理经验，这就使各级主管拥有了集中兵力打歼灭战的能力，进而可以创造出以一个小组团队加上其他小组群的支持与一个竞争对手（大公司）相对抗的能力。对于一个涉及多个不同行业应用的软件开发企业，太需要这样的能力了！

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