技术经验

在软件开发实践过程中，我们遇到各种各样的问题，有些是软件工程方面，有些是开发技术方面的，有些是人员组织方面的，问题各种各样，不一而足。所有从事开发或项目管理的软件公司都想找到一个软件开发的“银弹”，全面解决用户需求不断变化，开发时间一托再延的问题，要解决这些问题，各个公司都进行了尝试，形成了自己的开发模式及管理方法，在特定的领域内得到了应用与发展。

一般我们说拿出解决方案，首先应确认要解决的问题是什么，没有明确的目标容易在寻找解决方案的过程中迷失方向。

 

3.1 我们开发的软件是什么样的软件？

软件即以特定计算机语言编写，为解决特定问题而开发的计算机工具，软件分为系统软件（操作系统、数据库系统）与应用软件（某某财务软件、某某信息系统），在此我们讨论的软件系统基本为上为解决企业信息化而建立的应用软件；应用软件由于是运行于特定环境的，因此也受这些特定因素影响，一般情况下，为Windows 开发的软件，很难在类Linux、或MacOS上运行，反之亦然（有些读者可能要反驳到：好多用C++开发的软件，就可以同时在很多平台上运行，JAVA的应用就可以跨平台，这些并非是本人孤陋寡闻），“很难”并非不可能，只是为了实现这样的目的有这个必要嘛？实现的代价是什么？有没有更轻松的解决方案？

在国内像我们这样开发“信息管理系统”的公司占了主要比例（具体多少公司，没有统计过，只是我认识的公司都是开发这样的系统的），在此我们可以定位“软件”即为：信息管理系统软件，是企业为解决信息化管理、落实管理方式而建立的管理手段与工具。

       “信息管理系统”依据用户的数量、处理的数据量可以粗略分类为小型桌面软件（单机单用户）、中型网络应用软件（局域网多用户，比如：企业进销存软件）与大型分布式软件（局域网或Internet网内，用户数量大），像“记事本”之类的软件我是不愿意开发的，不开发的原因不是因为没有技术含量，而是这样的应用很难得到用户对它应用价值的认可，因此得不到应有的回报也就不奇怪了。用户委托我们开发或向我们购买的都是哪些具有一定用户数量，大家协同解决企业管理问题的哪些软件。

       另外，使用不同开发技术体系导制信息管理软件的分化，主要是对于开发人员的影响，开发人员比较熟悉什么技术，一般就愿意用什么技术解决问题，目前常见的开发人员技术群体为：JAVA,.Net,PHP等，对于什么技术好，在此不作解释，也没有资格评论，我们认为这些技术都能解决用户的问题，能解决问题的技术都是好技术，用户也不关心你是用什么样的技术解决问题，反倒是有些开发人员提到某某技术就做出索然起敬的样子，提到某某技术就不屑一顾的样子，让我感觉很狭隘。顺便提一下，在商务上我倒是觉得有些公司把某技术、某产品贵族化、神秘化，让用户在不明真相的过程中就多掏了腰包感到钦佩，实在是高啊！

        本架构由于是基于.Net开发的应用框架，当然读者群体也是.Net 领域的Coder，但无论是哪个技术体系的支持者、使用者都无所谓，在实际应用中遇到的问题都是一样的，最后得出的结论是：殊途同归，无论使用什么工具、技术，解决问题的思想都是一样的。因此，我们观察好多应用最广泛的应用服务器，它们的工作原理都是一样的。

 

3.2 用户的组织结构是什么，以及组织结构对软件结构的影响

       使用信息化管理软件的团体或组织都不是一个人在使用，一般都有很多岗位协调完成某一事务（即我们常说的业务流程或业务逻辑），因为过于简单的事务没有必要使用计算机来完成，一个人在工作能力范围内能完成的事务不可能成为软件开发的需求，只有在个人或团体靠单纯的体力劳动感觉乏味或力不从心才会想办法找替代工具，才能形成需求，促成软件开发或软件采购。

任何团体、组织都有其管理模式，管理模式定义了企业的组织结构，在此我们把企业的组织机构作一些粗略的分类与探讨。

微型企业：个体户或企业人数较少，业务也较少，发生的业务单一，企业管理的内容限于记录销售额，点清现金，工作量个人完全可以胜任，工作人员要么是自己，要么是自己的家庭成员，岗位职责界限模糊，即使销售或现金记录有误也不必过多解释，都是自己或自家的钱，没有必要将简单的事情复杂化。这样的企业没有信息化的需求，连企业主自身也没有完全认识到信息化的价值，只感觉信息化很好，要在自己的企业内实现完全是很遥远的事。

小型企业：只有一个单独的团体或组织，人数不多（50人以下），在同一办公地点办公，信息化管理软件完成的功能是业务办理与流程监控、记录、归档与初步的分析，指导决策人决策，这样的组织一般以企业老总为中心带头实现，各部门经理为业务主办与负责，部门工作人员负责完成具体事务，这样的企业特点是老总较强势，没有老总的带头与推动，信息化的实现基本上是不可能的，但另一方面由于老总的强势，信息化的业务流程中总是体现出老总的个人意志，业务流程的建立不一定是最科学的，取决于老总的认识与实施人员与老总的沟通。这样的信息化实施由于首先得到了老总的认可与推动，在实施时也比较顺利。

中型企业：企业具备了一定的规模，在某地设有总公司办公点，下设区域级分支机构，也可能按业务化分为分支机构或分公司，但各个机构的人员配置与功能与上述小型企业的人数与功能完成一致，只是分支机构必须接受总部的监督与指挥，在总部的规则指导下，分支机构有自主权，单独核算，总部的管理指标不但有自己的指标，同时也是所有分支机构的管理指标的总和，决策管理层需要掌握分支机构的经营情况，也需掌握总体发展情况；另外，各分支机构有可能在同一办公地点分开办公，也有可能在不同的城市办公，地域分布有跨度。企业管理层熟悉企业管理与业务流程，对信息化管理有相当的认识，同时也抱有期望，希望建立一套为企业管理服务的核心系统，降低管理成本，提升生产力，与同行保持竞争力平等（可能同行都具备了管理信息化能力，此时企业信息化只是企业的必备能力，而不是差异化竞争力）。

大型企业：企业具备相当规模，设立分支机构，地理分布跨度大，人员众多，业务多样，各分支机构俱有中型企业的管理需求，同时总公司可能以行业的角度进行分析与决策，对数据挖掘与分析有较高需求。管理层对信息化的认识跨度较大，人员众多，有些人对信息化认识深刻，有些则停留在感性认识，认为可有可无，企业信息化管理维护部门有信息化管理的专业人员，这些专业人员有信息技术维护的能力，但对企业业务管理则缺乏认识。信息化的成败依赖信息化实施人员与甲方的协调和管理层的推动力。因此，在大型企业实施信息化的难度高，失败案例比比皆是，究其原因主要是领导层重视信息化，但不是信息化的使用者，信息化维护与实施人员不懂业务，业务基层人员没有信息化认识，没有全局观，协调配合意识差，只注重本岗位工作。

	微型企业	小型企业	中型企业	大型企业
人数与组成	10人以下	50人以下	500人以下	500人以上
人员组成	自己或家庭成员	自己 家庭成员 朋友 雇员	股东 家庭成员 朋友 雇员	股东 董事会 雇员
管理层对信息化的认识	无或限于感性	感性或初识其价值	初识其价值，也可能认识深刻	初识其价值，也可能认识深刻
管理层对信息化的推动欲望	无	相当强	强	一般
信息化对企业生产力的提升	无或可能是多余成本	明显提升	明显提升	局部有提升，总体提升要看IT规划是否科学
实施难度	低	难	较难	非常难
实施周期	短	短	长	很长
多系统整合	无	无	较少	复杂

 

3.3 用户对软件系统的性能要求如何，如何在需要的时候提升性能

       用户一般在应用软件使用前没有直接的性能要求，只在软件部署应用后，感觉长时间没有响应（2秒以上的等待时间）或经常掉线时才会突然对性能有要求，应用软件的性能对于用户来说只是个隐性的需求，用户在与软件开发商购买软件或签订开发合同时首先就已经假定软件的性能是没有问题，性能问题是没有必要单独提出来讨论的。造成性能响应的原因可能为：

n        软件开发本身有缺陷，很多软件开发人员对性能都没有概念，什么样的代码会对性能造成什么影响，都是按自己的感觉，只有软件部署后才发现10个用户同时访问都发生响应超时，这样的软件开发在设计时就存在缺限。

n        软件开发首先是按用户的当前用户数设计的，没有考虑将来的发展，当规模增大时对软件、硬件的运行性能提出新要求，如果单纯靠提升硬件性能无法解决的问题，只能靠优化软件性能来解决。当然优化软件性能有成本与代价的问题，设计良好的软件框架，在扩展应用服务器的数量时是透明的，能够有效的利用不同硬件配置的服务器，有些应用的设计本身就不支持这样的扩展，要提高运行性能只能更换性能更好的服务器。

 

顺便解释一下，性能优化包含两个方面，硬件优化与软件优化，硬件速度的优化受技术条件的限制，成几百倍上万倍的性能提升很困难，有时是不可能的，但通过软件算法优化将性能提升上万倍却很普通，即相同的硬件配置，使用不同的算法，表现出的性能则不同。

我们举个例子，如果用户希望将现有应用的性能提升100倍，硬件提升的办法可能是：购买一台性能是当前硬件服务器100倍的服务器（应用不支持集群与负载均衡），或者增加购买99台与当前性能相当的服务器（应用支持集群与负载均衡），第一种方案在很多情况下是不可行的，原因为可能这样的服务器不存在，也可能成本太高而无力购买，购买一台普通4路服务器与购买一台小型机的成本并不是按性能的提升倍数来核算的；第二种可选方案比较可行，因为购买相同配置的服务器是用户能接受的成本增加。

如果上述提升当前应用100倍的性能通过软件优化能解决，则节省了购买硬件服务器的开支，相当经济，成为用户与软件开发人员的首选。

有些软件性能提升到极致后，还要结合增加服务器数量的方式来进行负载均衡，用多台服务器来增加应用性能，因此也是当前在软件优化不可行时的普遍做法。

性能优化是一个复杂的问题，需要结合实际的硬件条件、软件架构具体问题具体分析，我们在此讨论的只是一些原则，通过软件优化提升性能一方面是可行性高，另外成本投资小，应优先考虑。

 

避免软件性能的方法：

       与用户接触时把性能问题的表象与可能产生的成本与用户做深入的交流，在用户并不需要高性能时努力提高负载能力可能并不值得，而在用户需要高负载能力与可配置能力时软件框架却不支持，需要重新设计整个软件时更是得不偿失。

       需求调研时按最大负载估算，提前规划。

       应用设计良好的架构，在需要时能够动态调整满足要求（能做到这一步当然是一切OK了）。

       优化应用的运行时性能：数据库优化、网络传输优化、算法优化、硬件性能增强。

 

3.4 软件发开人员本身对软件开发的影响，如何克服这些影响

在谈软件开发与需求分析时，首先我们看一则漫画,英文原文地址链接：http://www.aqee.net/wordpress/wp-content/uploads/2010/06/WhatTheCustomerWanted.jpg

 

 

 

应用软件开发之所以困难在于整个软件开发过程不是简单的代码堆砌，而是人与人的沟通交流。我们曾经做过一个测试，参加测试的一共有10人，让其中9人在房间外等候，实验者对第一人叙述了一句话，让这位测试者按原意告诉下一位测试者，第二位测试者把自己听到的告诉第三位，以此类推。最终结果让观众啼笑皆非，每位测试者都把所听到的话按照自己的理解添加了个性化的修饰叙述给下一位测试者，结果传话到最后一位测试者时，已经与原来的意思完全背离了。这个实验只是再一次证明了沟通与转述的困难，而我们的应用软件开发首先是需求分析人员与用户沟通，将沟通的结果整理成文字描述，交给软件设计师，软件设计师设计出开发用例，测试人员与程序员根据开发用例进行实际的功能开发与测试，其中已经经过4次转述，其中的偏差可以想象。因此，开发一个用户最终认可的应用软件系统，要经过无数次沟通与误差纠正，任何环节出现的偏差都直接导致结果相去甚远。

软件开发人员是软件产品的生产者，其个人能力与思维方式不可避免的对软件产品形成影响，现代化的软件开发尽量消除这种个性化的影响，努力提升软件生产的成品率与流水作业的自动化水平，软件开发是个将思维过程转化为可重现的工作流程，软件开发管理水平的高低取决于这种可再现流水作业的自动化水平。基于这样的管理诉求，开发团队规定自己的编码规范，界面规范，统一需求的表达方式（文字与图示：UML），到开发企业自己的基础性软件设施等，都是在尽量消除个人的主观性影响。

因此，消除软件开发人员对软件产品的个性影响的措施可能为：

制定编码规范——统一代码的编写习惯与命名习惯（在参考文档中提供范本）。

统一需求表达方式（UML）——学习并应用UML，用文字与图表来表达需求与设计，让所有开发人员有统一认识，特别要理解团队的习惯性概念与假定。

制定界面规范——统一界面表现的字体，排列习惯，操作习惯等（在参考文档中提供范本）。

软件常用工具积累（Utility）——归类整理常用软件工具程序，提升开发速度与质量。

开发并应用通用软件基础设施——发展应用框架通用基础设施，不断复用前人的开发成果，降低应用难度，降低维护成本。

提供开发示例——新人入职时使用开发示例培训，统一开发习惯与思维模式。

 

3.5 为解决以上问题我们的构架应具备的能力与配置

3.5.1 通信能力的可配置

应用服务器的应用可以通过各种现有的通信协议传输对象与对象调用，而不用修改现有对象或代码结构，目前在 .Net 环境下首选当然是WCF通信基础，可通过配置应用不同的通信协议与绑定。经常见到好多同行为不同的服务定义不同的接口，每个接口有一个或多个不同的服务实现，服务端通过配置来创建合适的服务对象（IoC创建服务对象或使用对象工厂方法来创建服务对象），客户端代理调用代理方法后将调用传输到服务调用，将最终结果返回给客户端。

 

图中所指网络指广义的通信网络：进程内通信、进程间通信。

这种通信的配置需要注意的是需要为所有的服务创建一个统一的配置方式，而不是为每一个服务接口都单独定义一个配置，随着时间与接口数量的增长，配置文件又臭又长，难于维护与阅读。

 

3.5.2 应用宿主程序的适应

应用宿主程序可能是命令行程序，可能是Windows应用程序，也可能是Windows系统服务程序，也可能驻留在Web服务器内（如：IIS应用服务器）。因此，关于服务的配置应是统一的，不应有差别。

 

3.5.3 1-N层应用的可配置（纵向）

       常见应用都是分层次的，根据分层形成清晰的定义，每一层各自扮演各自应有的功能与角色，使架构变得更加清晰和可维护。常见逻辑分层模型如下：

 

逻辑的分层并不会对逻辑架构与物理的分离造成伤害。

可能的应用场景： 

 

1.五个逻辑层运行在同一台电脑上 

 

 2.使用独立数据库服务器的五个逻辑层

 

3.使用独立应用服务器和数据库服务器 

 

4.最优化性能的WEB客户端 

 

 5.部署在负载平衡的Web集群上的五个逻辑层

 

 6.部署在安全Web设置中的五个逻辑层

 

     关于物理层与逻辑分层组合与部署的优缺点可以参考《Expect C# 2005 Business Objects》中文版一书中第一章1.1.2，总得来说，架构中的物理层数是一种在性能、可扩展性、安全性和容错能力之间平衡的结果。而且，对于一个Web应用程序和一个使用桌面应用的内部网应用程序的最优化设置是不一样的。如果应用程序框架有多方面的要求，哪么它就在物理架构中需要灵活性，来有效地支持Web和桌面应用，并且同时提供最优化的性能和可扩展性。除此之外，它还需要能在面向服务的环境中创建客户端和服务器端应用程序，通过消息通信来实现互操作。 

 

 3.5.4 应用层负载能力的可配置（横向）

在上述“图7.Web集群安全环境中的五个逻辑层”中应用了Web集群就是一个在横向负载扩容的例子，一台服务器负荷过重时，自然想到增加一台或几台服务器来提高负载能力，但支持负载均衡或集群的软件开发与只能在单个程序域运行的软件开发难度有很大的不同，成熟框架应能屏蔽这些复杂性，使得开发人员不用关注这些区别，不管是运行在集群环境还是单机环境，代码的编写都是一致的，最终产品只要更改配置即可。

 

3.5.5 应用服务的动态调度

实际应用中即有与用户交互操作的应用，也存在一些定时定期执行的批量任务，这种类型的任务不需要用户的交互操作，任务按照应用的设置参数周期性的执行，在此我们称之为“自动任务”，应用服务器应具备调度“自动任务”的能力。

3.5.6 应用基础设施

一个可以应用于生产的框架不但需要具备上述能力，还应满足企业级应用所必需的基础组件才能够让开发应用人员用得得心应手、顺畅，在提高生产效率的同时提高生产率、成品率。这些基础设施可以归类总结为：

l        常用软件辅助（Helper）类的积累,比如：如何取本机MAC 地址？如何将金额转换成人民币的大写字符串？如何打印输出报表？等等。

l        通用的权限认证与授权组件，绝大部分企业应用都有流程管理，岗位职责，所以实现一套权限认证与授权系统是必要的，不必重复的建立这样的组件，让开发人员专注业务逻辑的处理。

l        工作流调度组件，绝大部分业务应用都是程序化、有规范的作业流程，实现工作流调度组件可以降低对开发人员的要求，让一般开发人员在不懂得工作流系统的前提下开发基于工作流的应用。

l        WinForm应用统一入口、Web应用统一入口，开发人员不用关注整个系统是如何组织的，只需专心开发与业务逻辑相关的界面即可。

 

3.6 IBeamMDAA最终可达成的目标

前面分别从5个方面概要性的总结了开发企业级应用面临的挑战，软件开发企业虽然顶着高科持的帽子，却没有因为高科技使得大多数中小企业在行业中取得丰厚的收益，有些甚至入不敷出，最终破产倒闭，原因虽然复杂多样，但也有共同点：

l        中小软件企业规模小，最初的资本是出资人的血汗钱，由于规模与可预见的发展前景对核心人才没有吸引力，自己辛辛苦苦培养的人才，一旦学成正果后马上离开企业，自己变成人才培训班，越是节省开支，越是经营困难。

l        项目开发周期长，时间越长，人力成本支出越大，客户满意度降低，代码可维护性差，人员更换后老板或项目经理痛苦不堪。

l        新人水平有限，因节省人员支出，招聘到的员工要么是水平差，要么是刚入门的初学者，人员的增加，并没有增加产出，新人只能做些简单、重复，不用动脑的工作，反而占用了管理者的时间用于新人培训、管理新人，有些管理者都恨不得不要新人，完全自己一个人做就行了，虽然结果也是一个人完成的，但管理者还是有侥幸心理，希望有几个人可以帮到自己。

l        好不容易接到的项目，被新人拖延，利润全用于支出人员工资与办公费用上，代码写得乱七八遭，项目虽然完成了，没有赚得利润，还要承担起项目维护，往后的客户服务与软件升级实在不敢想，多少个夜晚都有杀人与被杀的冲动。

l        几年下来，公司或个人都是筋疲力尽，对未来一片茫然。

因此，需要一种解决方案来解决以上问题，即：我需要一套框架，新人不需要懂得软件开发的方方面面，只需懂得语法，对SQL有点概念，参照前人的示例，一个星期即可投入到岗位工作，编写的代码与老程序员的代码已分不清谁好谁坏，虽然新人并不懂其中的技术与道理，最终成果交给资深人员组织使用即可，构成项目或产品的一部分，时间没有拖延，人员没有无用之才，资源没有浪费。

总结，对于程序员的要求：如果不懂写程序，还不能模仿嘛？

 

注：软件开发也存在分工，有：软件架构师、需求分析师、程序员（程序编写人员），测试人员与客服人员。软件架构师、需求分析师的工作最有价值，程序员的工作是乏味的，测试与客服人员是不被重视的，要成为什么人完成取决于个人的选择与努力，只是中小企业中一个人同时担当了数个角色或者是全部角色。

哪么，您真得需要一个框架！

             IBeamMDAA就是这么一个框架！

IBeamMDAA并不是一个全新的框架与系统，它建立在Csla.net的基础上，所有的概念都遵守Csla.net的约定，Csla.net就好像是内核，IBeamMDAA围绕其创建了系统的外围。整个框架中业务对象（移动对象DTO）在逻辑的各层中移动，协调运转，数据对象是数据库实体对象，只在数据访问层存在。下面是IBeamMDAA的三种基本结构，反映了IBeamMDAA从逻辑结构到物理结构的三种部署，但然，还有很多种变体结构，但都是从这三种基本配置变化而来。

 

  以上图中“应用服务器”中运行着数据访问层与业务逻辑层，客户端里运行着业务逻辑层，这是典型的物理三层。业务对象在各层中传递。

 

以上图中，“数据服务器”里运行着数据访问层与业务逻辑层，应用服务器只运行着业务逻辑层，客户端运行着业务逻辑层。业务对象在各层中传递。 

 

以上图中，没有所谓的“应用服务器”与“数据服务器”，客户端里运行着数据访问层与业务逻辑层，客户端直接连接数据库服务器。业务对象在客户端进程中执行。

      如何选择配置取决于应用的需求，参见3.5.3节关于 1-N层应用的配置，框架本身应提供这种伸缩能力，在应用部署结构变化时不用重新设计与修改原有代码。

4.1应用开发必备组件

序号	类库名称	版本	厂家	说明备注
1	IBeamMDAACore.dll	1.0.*	昆明光标科技有限公司	功能权限、界面定义注册属性，自动任务属性及工具类
2	IBeamMDAACommon.dll	1.0.*	昆明光标科技有限公司	当事人管理，界面、功能权限、系统设置，所有信息管理系统的基础
3	Castle.ActiveRecord.dll	3.0	Castle	依赖组件，ORM映射工具
4	Castle.Core		Castle	依赖组件
5	NHibernate	3.1		依赖组件
6	Iesi.Collections	1.0.1.0		依赖组件
7	Common.Logging	1.2.0.0		日志输出，依赖组件
8	log4net	1.2.10.0		日志输出，依赖组件
9	XCrypt	1.0.0.0	昆明光标科技有限公司	通用加密组件
10	Csla.dll	3.8.4.0	Marimer LLC	依赖组件
11	Csla.XmlSerializers	3.8.4.0	Marimer LLC	依赖组件

 

4.2 Winform开发必备组件（包含应用开发必备组件）

序号	类库名称	版本	厂家	说明备注
1	IBeamMDAAWinUI.dll	1.0.*	昆明光标科技有限公司	功能权限、界面定义注册属性，自动任务属性及工具类
2	ComponentFactory.Krypton.Toolkit	4.3.1.0	ComponentFactory	UI基础组件
3	WeifenLuo.WinFormsUI.Docking	2.3.1.24483	WeifenLuo	界面依靠与布局
4	IBeamReportExporters	1.0.0.0	昆明光标科技有限公司	报表导出
5	HtmlHelp	0.4.1943.15286	Microsoft	从chm文件中读取Html文件
6	Microsoft.ReportViewer.Common	10.0.0.0	Microsoft	报表
7	Microsoft.ReportViewer.WinForms	10.0.0.0	Microsoft	报表

 

4.3 Web开发必备组件（包含应用开发必备组件）

序号	类库名称	版本	厂家	说明备注
1	.Net MVC	最新	Microsoft
2	DWZ		杜权(UI设计) duq@dwzjs.com 吴平(Ajax开发) rogerwu@dwzjs.com 张慧华(Ajax开发) zhanghuihua@dwzjs.com	http://code.google.com/p/dwz/
3

 

4.4 应用服务器Windows系统任务必备组件（包含应用开发必备组件）

序号	类库名称	版本	厂家	说明备注
1	IBeamMDAAAutoTask.dll	1.0.*	昆明光标科技有限公司	自动任务管理
2	Quartz.dll	1.0.3.2		自动任务调度
3	IBeamMDAAHostServer.exe	1.0.*	昆明光标科技有限公司	服务器宿主