基本层次

软件的逻辑结构可以划分为下面四个基本层次：

从下往上依次是：

1：基础设施层——这个层次是纯技术层次，解决的是系统的物理问题，比如database gateway、网络通信、对象容器……这个部分与业务需求关系不大，是系统的物理条件。

2：business对象——在这个层次上，业务要素出现了，业务领域中的概念在这里实现。比如一个航运公司的系统，这里就应该有航线、航班、座位、乘客、登机牌……这些对象应该拥有与实际业务领域相符的属性、方法。

3：business流程——这个流程不是指程序解决问题的流程，而是用户的商业活动的流程。他体现的是端到端的业务流程。比如：检票员为旅客办理登机牌。business流程的输入参数是business对象，输出参数是business对象，产生的异常也是business对象。business对象在这里组合、串接，实现业务流程的自动化。这个层次是在直接实现用户的需求。

4：UI和接口——这个层面调用business流程，将执行的结果交给软件的用户，或者别的系统。

这种逻辑层次划分是最基本的情况，各种复杂的层次都是这种方式的一种扩充。比如下面这样的形式：

在基础设施层和business对象之间，加入了一个DAO层。DAO层一方面负责数据的存储，体现了数据的存储方式，另一方面体现了业务对象的属性。这样就使business对象只需要负责纯粹的业务逻辑，不用关心物理问题。简单的说，业务对象里面不需要写SQL语句了。

business对象和business过程之间，加入了Service层。business对象也是具有行为的，但是这样的行为是比较细微的，需要调用者在多次调用之间保持必要的状态，需要用Service层来做一个封装，更明确的表达业务含义。

单元测试

单元测试需要关心一个问题：层次之间的依赖关系。如果要测试某一个层次上的对象，必须同时建立他所依赖的每一个对象。层次之间的依赖越简单，测试越容易。

逻辑层次之间原则上是由上至下的依赖关系，同一层次内部的对象可以互相依赖。跨越层次的调用也是允许的，比如在UI Process中调用Business对象。UI层和UI Process层之间存在着互相的依赖。开发中我们最希望测试的是这三个层次：business过程、service、business对象。我们只要对下层对象建立stub对象，就可以对这三个层次上的对象进行测试。

对这三个层次的测试结果不仅保证了程序的运行时正确性，也是对程序的业务流程进行测试。在开发过程中和维护过程中，某个业务流程发生了变化，可以用单元测试保证其他流程不会受到危害。这样的构架可以保证迭代开发过程。

和物理层次的结合

上面说的都是系统的逻辑层次。在系统中还存在着另一个层次——物理层次。逻辑层次的目的是简化程序的逻辑复杂度，便于开发和维护；物理层次的实现需要考虑实际的物理分布情况，合理的安排每个物理节点的任务，最大限度提高系统的性能。逻辑层次和物理层次的划分依据和划分目的都是不一样的，他们之间存在着联系，但也不是绝对的。

逻辑层次和物理层次的结合有两种方式：

1、在基础设施层解决掉物理分布的问题，建立一个分布式的对象容器，把business对象和service放到容器中。这样，business对象和service就不必处理复杂的物理分布问题，business过程也不必关心他所调用的对象是在什么位置建立的。这样的方式最大限度的减少了物理结构对程序逻辑结构的影响，增加了物理分布的灵活性。但是在大部分情况下，对系统的效率都是有危害的。

2、在business对象内部处理物理分布的问题，或者制定一个技术无关的接口来体现business对象，在各物理节点编写各自的实现。这样物理层次和逻辑层次是搅在一起的，使系统的逻辑结构显得混乱，但是可以达到较高的运行效率。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

看了一篇讨论：
http://www.cnblogs.com/yimlin/archive/2006/11/30/578333.html
有些感想：并不是所有的行为都必须属于某个对象，有的行为似乎放在任何一个对象中都不合适，那就单独放在那里好了，没必要非要造出一个对象来，更不能把它硬安在某个对象上。

按照oop的方法，软件的逻辑架构可以分成下面几个层次：

1：基础设施层——这个层次解决的是物理问题，比如database gateway、网络通信、对象容器……这个部分与业务需求关系不大，是系统的物理条件。有很多技术框架帮助我们尽快的把这个层搭起来，比如web server、中间件、ACE。搞软件的公司会在这方面形成自己的技术积累。开始搞一个项目的时候，经常把以前的东西拿来复用，尽快进入后面的工作。

2：business对象——在这个层次上，业务要素出现了，业务领域中的概念在这里实现。比如一个航运公司的系统，这里就应该有航线、航班、座位、乘客、登机牌……这些对象应该拥有与实际业务领域相符的属性、方法。长期在某个业务领域开发的公司，在这方面也应该形成自己的技术积累，形成可以直接复用的对象模型。这个层次上也是有一些现成的产品可以用的，比如SAP、工作流引擎，可以在这些东西的基础上做定制开发。

3：business流程——这个流程不是指程序解决问题的流程，而是用户的商业活动的流程。他体现的是端到端的业务流程。比如：检票员为旅客办理登机牌。business流程的输入参数是business对象，输出参数也是business对象。business对象在这里组合、串接，实现业务流程的自动化。这个层次是在直接实现用户的需求。

4：UI和接口——这个层面调用business流程，将执行的结果交给软件的用户，或者别的系统。

在“3：business流程”这个层次上，并不是每个行为都可以在系统中找到一个归属的对象，这是正常的。没有必要为了oo而oo，一定要给某个行为找到一个对象。尤其是不能把这些行为硬安在某个不相关的business对象上，那样反而会使系统变得混乱，难以理解。business流程的独立存在不会误导任何人。

从一个大的范围上说，这些business流程的所属对象，应该是系统的使用人。不应该花太大的精力，过多的考虑这些行为应该属于哪个实体。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

先说一个小笑话。有一个生产队队长，他对专家说：“现在我们生产队的地越来越多，牛越来越忙不过来了。我想要这么一种牛，他吃的草和普通牛一样多，但是干的活是普通牛的十倍。”专家说：“这种牛是可以造出来的，现在有基因工程。”队长说：“好吧，你给这造几头这样的牛。”于是专家找到了生物实验室，让生物实验室的人搞一个基因工程，把牛造出来。于是工程浩大，投资无法保证，合作多半是不愉快的收场。

现实世界里很多人分析需求的过程就类似于这位专家，他们把注意力放在用户提出的功能点上，而对用户的实际需求没有兴趣。有不少软件公司和程序员，其实都在做类似的基因工程。如果这个专家把注意力放在生产队长的业务需求上，而不是太在乎他提出的功能点，他会说：“我认识一个卖拖拉机的，可以带你去看看。”

软件的维护为什么这么痛苦，一个很重要的原因在于：需求已经被遗忘了。

需求是对用户具有直接商业价值的活动，而不应该牵涉到任何的功能实现方式。实现同一个需求可以使用多个方案，每个方案有自己的功能方式，在某个方案中至关重要的功能点，也许在另一个方案中根本无关紧要。

瀑布式的开发过程，首先是由一批懂得用户业务的专家去调查用户的需求，分析出这个系统应该具有哪些功能，形成一个非常重要的文件——《xxx系统需求规格说明书》。客户认可了这个《说明书》，在上面签字盖章，加入合同附件，到时候项目验收就以此为准。这时候，需求就已经分解成了一个个功能点，从这时候开始，需求本身就渐渐被人们遗忘。设计人员围绕着这些功能点进行工作，考虑用什么样的技术手段把功能点制造出来。功能点的制作细节形成了另外一份重要的文件——《xxx项目设计规格说明书》。这个《设计规格说明书》交给程序员去进行编码。

这样的做法在开发中已经形成了很大的问题。

首先，面对这样的《需求规格说明书》，设计人员已经无法知道最初的需求是什么。假如这个《需求规格说明书》中的功能点没有出现互相矛盾的情况，而他们串起来却和用户的需求不同，设计人员没办法发现这样的情况，编码人员也无法发现。假如测试也是根据这个《需求规格说明书》来做的，测试人员也发现不了。直到最后客户看见这个程序展现在他们面前。需求的分析需要在随后的过程中不断得到反馈，传统的过程不是没有反馈，而是反馈的时间太长了。

其次，由于设计人员已经无法知道基本的需求是什么，也就无法对业务进行建模。这样的需求分析是以开发人员的需要为核心的，可是结果恰恰妨碍了开发人员对需求的理解。如果开发人员对用户的业务过程不甚了解，他们只有一种选择：不要试图去了解需求了，直接按照这些功能点做吧。于是，他们建立的对象模型就不是以需求为核心的，而是以功能、界面为核心的。我见到过很多这样的系统，开发者确实有很高的抽象思维水平，程序中设计了非常巧妙的控制器和界面，可以很方便的进行开发和变更。唯独业务层的对象非常简陋，一旦发生实际业务的变更，仍然十分辛苦。

更大的困难发生在维护程序的时候。

假设有一个移动通信公司需要制造一个系统，用来解决手机用户入网的问题。这个需求有下面几个要素：

1：用户付钱，得到一个SIM卡和一个号码，把这个SIM卡装到手机里就可以通话。
2：营业员收的钱要记录下来，提供给稽核人员，现金和帐目必须是平的。
3：用户付的话费要划入他自己的帐户，可以打印票据。
4：用户要在入网合同上签字，然后营业员把合同归档。

这几个要素都是和通信公司的商业利益直接相关的，没有牵涉到任何系统实现方式。如果不考虑通信公司内部的业务规范，实现方案可以有几十种，下面列举两种：

1：SIM卡发给营业员，用户入网的时候，选择一个号码，然后付钱。营业员把SIM卡号码和电话号码输入系统，在交换网络上进行注册，这个SIM卡就可以通话了。然后各种费用记入各人帐户，合同归档。

2：SIM卡在下发给营业员之前，先在交换网络上和注册，并且已经预先设置了一定的话费。用户选择了这个号码，付钱之后直接SIM卡拿走就可以打电话了。营业员事后再输入用户的合同资料，费用计入各人帐户，合同归档。

这两种方案在实现过程上是不同的，因此具有不同的功能点。比如第二种方案中的SIM卡在出售之前是可以进行通话的，所以必须对这样的号码的通话费用进行监控，这个功能在第一种方案中是根本不需要的。并且两种方案在帐目的核对方式上区别也是比较大的。这两种方案是不同的功能点的集合，他们完成的是同一个业务需求。

系统在开发阶段如果没有保留用户的业务需求情况，而是只留下一个功能点的列表，会给维护人员带来成很大的困难。维护人员无法从这样一堆功能点中发现最初的需求是什么样子。各位可以试试，假设我们忘记上面的四个需求要素，只看下面的某个实现方案，从这个复杂的实现过程中，我们很难知道用户现在的需求到底是什么。一旦需求发生了变化，这些功能点就会出错，或者是功能点的时序发生意料不到的错误，也许帐目核对不上了，也许是用户拿走的SIM卡不能打电话了。

看不见需求在哪里，不知道手里这段代码会触动需求的哪根神经。维护人员的痛苦大部分来源于此。

“不要紧，客户记得自己的需求。”但是客户通常不懂技术，即使他们懂技术，他们也不知道系统是如何实现的。如果开发人员依靠客户提出新需求的解决方案，结果就是让软件工程变成“生物工程”。到最后是钱基本花光，人基本累死，甲乙双方感情基本破裂。

软件开发必须划分成几个过程，但是各个步骤应该有一个统一的核心——业务需求。

在需求调查阶段要搞清楚用户的业务需求，为了达到这个目的，可以提问回答，可以对用户进行跟踪采访，或者做一个demo给用户看看，最终的目的是为了搞清楚用户在做什么事，遇到了什么问题，程序应该去解决什么问题，这就是这一阶段的工作。

然后开始进行设计，设计系统的逻辑结构和物理结构，逻辑结构要符合需求的概念，各个对象互相调用要能够实现需求中的业务过程，同时物理结构划分合理，符合实际的分布状况，可以达到要求的的性能，业务过程的物理运行方式合理高效。这一阶段仍然是以业务需求为核心。

接下来是编码。首先是编写一些基础设施，比如网络通信、数据库、文件的读写、分布式计算，这些基础设施和业务需求没有什么关系，有很多现成的框架，借助这些框架我们可以尽快度过这个黑暗的阶段。然后编写业务对象，这时候业务需求中的一些概念逐步出现在代码中，比如上面说的那个例子，“用户”、“号码”、“合同”、“入网”、“SIM卡资源”这样的业务要素逐渐出现，这些对象所拥有的属性、可以运行的行为也和现实的需求一样。接着这些业务对象串接起来，实现业务过程，现在业务需求又回到了人们的视野当中。业务需求是什么，如何实现，在这里一目了然。最后将这些过程在UI或者接口中调用，将功能提供给用户或者别的系统。

测试更是要围绕着业务需求来进行，正常的业务流程应该产生正常的结果，如果缺少某个资源，或者输入了不合适的数据，应该出现业务含义明确的异常。并且系统的业务对象是处在一个独立的层次上，与UI和基础设施没有很大的关联，这样可以方便的采用自动化的测试方法。

这样的系统维护起来一定少很多痛苦。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

程序维护的时候经常遇到两个困难：

1、不知道这段代码是实现什么功能的（code —— function）；
2、不知道这个功能是实现什么需求的（function —— business）。

解决第一个问题是比较容易的，大家都是搞技术的，一头扎进代码里去，看上几十分钟，通常就能明白：原来这段代码是从数据库里面找到前三个月一直处于停机状态的号码，然后把这些号码放到一个叫做QUIT_USER的数据表里面去。

第二个问题就难了，经常从代码中是看不出来的，于是项目开发的过程中就制造出来了大量的文档，来帮助开发者交流这个问题，也让将来维护这段代码的人知道这个知识。

我们可以查找与这段代码相关的文档，文档上说：这段代码把停机三个月的号码放到一个叫做QUIT_USER的表里面，一个月以后，这些号码由另外一段代码拿去筛一下，把最近刚交了费用的号码删掉，剩下的用户做退网，号码回收，冻结半年以后可以重新使用。

令人难过的是，维护程序的人很难有幸看到如此贴心的文档。他们查了半天经常看到的是：这段代码按照xxx的规则，从xxx表中查询数据，然后再把结果的数据经过xxx的处理，放到QUIT_USER表里面，over。你仍然不知道他到底是在做什么。

并且，文档与代码的同步也是一个难题。不仅是文档，即使是代码中的注释，谁又能保证他真实的描述了系统的运行方式呢？时间紧张、错误的理解都可能造成文档与实际情况不同。我们假定写文档和写注释的人是认真的、不犯错误的，他们也必须忽略一些细节，他们不能什么都写上去。而他们忽略的细节很有可能为以后的维护带来麻烦。

很多项目都有这个问题：business和function是脱节的。熟悉客户业务的人设计出一系列的功能点，这些功能点按照最初的设计是可以完成客户的业务的。然后这些功能点就拿到开发人员那里去造出来。而开发人员对用户的business其实是不了解的，他们的眼中只有function。到了维护的时候，business发生了变化，function重新设计。经常是经过一番修改，程序按照开发人员的思路运行良好，但是用户却一个劲的摇头：“不不，不是这样的，我们要的是这个……”程序到底解决了哪些business，已经成了一个迷。

什么东西可以最准确的描述程序的运行过程呢？只有代码本身。并且，经过精心设计的代码也能很好的对business进行描述。比如刚才说的那件事情，一段代码把号码放到QUIT_USER里面，另一段代码从这里面筛除一些号码做退网。这两个function其实在business方面都属于一个点，那么就应该让这两段代码写在一起，封装起来——这就是高内聚。并且这一段代码内部的操作应该与其他的功能没有任何关系，除非那个功能与这两个功能具有business上的共同点，别的代码应该不知道QUIT_USER是个什么东西——这就是低耦合。

一个项目的代码，总是由大尺度的构思开始的，然后越来越贴近细节，牵涉越来越多的技术。但是写到最后，代码应该回到对business本身的描述。代码越贴近business，对维护的帮助就越大。

我现在要维护一个公司的财务管理程序，我想知道职员的工资里面是不是已经计入了他们的个人所得税。我找到Account（会计），他应该有一个方法，每个月运行一次，把Salery发给Emplyee，我找到这个Salery，看到里面已经包含了Tax。我发现Account计算这个Tax的时候使用了一个Stratagy（策略）。他调用的是一个名叫Stratagy1998的策略，以800元作为基数计算个人所得税。现在这个基数已经发生了变化，于是我修改这个Stratagy1998、或者替换掉一个新的Stratagy2005。这样就完成了一次变更。并且我知道这样修改不可能影响到business不相关的东西。

文档永远只能表示“某时某刻我们曾经这样想过”，让文档时刻保持与代码的同步是不实际的。要想知道“现在程序是怎样运行的”，只有代码能够告诉我们。文档应该配合代码，做代码不能做的事情，配合把business说清楚。而不应该与代码发生冲突。

文档应该去描述代码无法说清楚的事情上，比如用户的工作场景、某个需求是由谁提出来的、大尺度的程序设计、重要对象的运行时序、系统安装手册。比如下面这个图，他清楚的说明了“销户”这个行为在整体的需求中处于什么地位。这样的东西用代码说清楚是比较费力的。当然用代码也能说清楚，比如可以使用State - Action模式，但是总归不如一张图表示的这么清楚。



XP和Agile方法所提倡的“尽量少写文档”，就是基于这样一种设计理念：尽量的用代码和测试代码来描述business，以达到知识的交流和维护的便利。代码是最重要的沟通语言。在代码说不清楚的情况下，文档也是必须的。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

NGOSS（Next Generation Operational Support Systems）是由TMF（Tele Management Forum）提出的，他用于电信领域，是构建下一代OSS/BSS系统的框架。

TMF提供了技术中立构架（TNA）作为NGOSS解决方案的技术构架，这样就把NGOSS建立成了一种标准，这个标准与实现他的技术相互独立。TMF还提供了一组测试方法，用于验证解决方案是否符合NGOSS的标准。

完整的NGOSS框架有多个组成部分，这些部分也可以独立的实施，用于解决某个领域的业务问题。下面对这几个部分做个基本的解释：

eTOM（Enhanced Telecom Operations Map），他体现了电信领域的业务过程，这些过程是开发一个系统所必须的。eTOM描述了业务过程在电信运营领域中是如何运作、如何互相交互的，各个过程涉及到哪些参与者。eTOM的定义尽量符合一般情况，尽量减少对技术的依赖性。

SID（Shared Information/Data Model），他提供了一个数据的标准，或者是实体的定义，这样就保证了在不同的数据提供者之间建立的系统可以平滑的集成起来。SID为系统之间的交流提供了一个“协议”，他定义了实体的接口，以及实体间的关系，这个接口是独立与技术实现的。SID降低了一个系统与外界系统互联互通的难度。

TNA（Technology Neutral Architecture），这是NGOSS的一个重要组成部分，他定义了eTOM里面的过程和SID模型是如何结合起来，构建成一个完整的系统的。TNA不是定义一个实际的技术构架，而是定义了这个技术构架必须遵从的原则，从而保证OSS系统的所有部分的整体性，即使在分布式的环境下，也可以完整有序的结合在一起工作。

除此以外，NGOSS还提供了一组测试方法，用来验证解决方案是否符合NGOSS的标准。

NGOSS的目标就是：让符合其标准的解决方案能够更快的响应市场的变化，更加的易于维护。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

IT系统是根据需求建设的，而需求是从哪里来的呢？

为什么这个世界需要一个这样的系统，为什么系统需要做成这样，不多做一些事情，也不少做一些事情，恰好就要做这么多事情？

这些问题难道不是问题吗，难道需求是理所应当的吗，需求是从哪里来的呢，用户为什么有需求，需求为什么是这样？

下面我做了这么一件事，把一个家庭的活动整理了一下，有下面一些内容：



一个家庭的活动有这几个内容：工作、娱乐、购物、文化教育、医疗保健、人际交往。

这个东西是不是可以看作中国城市家庭的一个生活模型。

还需要加上一个活动：财务管理。这个活动不应该是与前面几个活动并列的，他应该是一种横向的交叉活动，就像下面这样：



假如我们现在要规划一个家庭的IT系统，就可以先根据这个模型，规划这个IT系统需要划分成哪几个子系统，各个子系统需要具有哪些功能。然后就是确定如何结合现有的条件分步骤的实现这个IT系统。

如果从一开始就没有一个整体的规划，每个系统都是分别规划，根据自己的需要去独立建设。当最后这些系统结合在一起的时候，肯定会发生这样的现象：各个系统的边界有所重叠，也存在空隙，有的事情没有人做，有的人没有事做。当一个人需要了解这个家庭的整体情况的时候，他观察每个系统，会发现每个系统的标准都有差别，对同一个概念的理解不一样。要得到一个整体的情况，必须在各个系统之间搞很多人工的翻译工作。

这个模型的存在不是为了开发某个系统，而是为了搞清楚人的活动。分析这个模型可以知道，在这样的活动中有什么样的需求，需要开发哪些系统来满足这些需求，这些系统需要有什么样的功能。

一个家庭还要有这样一个活动：信息的管理。比如：家用电器的使用手册，上次给汽车加机油是什么时间，家人朋友的生日……现在的家庭正在越来越多的做这样的管理活动。加上信息管理，形成了下面这样的家庭模型：



设计一个系统的时候，不能把眼睛放到一个个的功能点上，不去研究系统的业务需求。要避免被功能点洗脑，功能点是可能被代替掉的。同样，一个独立的系统，也只有放到人的活动中才有价值。在这个范围上，任何一个独立的系统也是可能被代替掉的。

这个家庭模型可能有问题，比如：人际交往这个活动可能不应该是和其他活动并列的，他应该也是一种横向的交叉活动，人际关系在其他活动中是可以发挥作用的。应该是这样：



从人的活动，到一个系统的开发部署，假设这其间的路程是100公里。很多情况下我们关注的是最后的10公里，前面的90公里，因为已经有人把结论告诉我们，所以经常被我们忽视，我们都认为那是理所应当的。

如果开发者和客户之间签开发合同，客户提出需求，开发者只管照做，然后客户就要买单。需求是什么——这个问题是客户的事情。但是如果是开发一个产品呢，把一个造好的东西拿给客户，希望客户买单，开发者就必须自己研究这个问题。

或者，读这篇文章的人自己就是那个客户，他怎样知道自己需要什么呢？

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

灵活的软件，可以更好的适应用户的需求。什么样的软件才是灵活的？

一旦用户提出灵活性方面的需求，设计者经常想到的一个对策是：增加配置。在不同的业务环节上增加功能配置，哪里需要灵活性，就把配置写到哪里。配置为软件系统提供了无数个可能——这就是灵活性。但是配置经常复杂无比，失去控制。很多配置项目已经失去了业务意义，完全成为一种数学意义上的排列组合。按照一些配置的路线，业务无法形成闭环流程，走进死胡同。

这样的系统，维护配置和维护程序本身一样复杂。配置，就是不需要编译的代码。

实际上，软件最大的灵活性，来自于完整的业务模型。一个完整的业务模型，不需要华丽的技术——设计模式、先进的平台、巧妙的构思——这些都不重要。重要的是，业务模型需要真实的反映真正的世界。

真实的世界上有“顾客”，那么软件世界里就要有“Customer”，真实的世界上有“帐单”，那么软件世界里就要有“Bill”，真实的世界里顾客可以买东西，那么软件世界里的Customer就有“Buy”方法，参数是Order……

把这些基础的业务模型构思出来，就能够发现，具体的业务需求实现起来会十分的方便。就像用积木搭起一栋房子一样，只需要写一些胶水代码，把业务对象拿来组装一下。

业务模型会有变化吗？当然有。但是业务决不会无中生有的变，也不会没有道理的变。业务模型的变化一定是在原有的基础上添一点东西、改一点东西。一个业务模型能很好的控制变化影响的范围。为了减少这样的变化对模型的影响，各种技术就可以登台了——设计模式、重构……

有一个业务模型，即使是很朴实无华的业务模型，也可以为程序带来极大的灵活性。可以在胶水代码里面增加配置，这样的配置比较容易与用户的业务需要紧密结合，真正的起到作用。也可以把业务对象暴露给脚本引擎，用脚本程序实现一些功能需求。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

我的第一个工作是在一家软件公司写程序，主要的客户是一家省级电力公司。工作主要是以项目的形式，项目签下来了，忙几个月，从需求调研到设计，编码，测试，然后现场调试，现场维护。做完了以后通常有一个空闲时间，然后进入下一个项目。每个项目的需求都有一定的差异，但是都是在同一家电力公司里，尽管具体的客户不同，解决的问题也不同，但是都属于同一个大的商业范围。

现在已经离开这家公司近一年了。有时候思考以前的经历，更能摆脱那种身在此山中的迷惑，也能够在技术方面有一些回忆和反思。虽然已经是马后炮，毕竟工作还在继续，总结以前的经验对以后也是一种财富。对于其他人来说，也许能够有一些借鉴作用。也希望一代一代的程序员能够积累自己的经验，减少新人在黑夜中摸索的时间。

以前的工作经常是项目性质的，一个项目做完，再做另一个。每个项目都有不同之处，解决的是特定的需求。每个项目都是新的，很难形成技术上的积累。因此，造成开发人员也是比较痛苦的，在dead line之前苦苦挣扎，加班熬夜是普遍现象。

现在想起来，虽然以前做的每一个东西的具体情况是有差异的，但是总的来说，客户范围都是在电力公司里面，具有很大的共性。如果细细规划，还是能够形成一些有延续性的构架的。

首先我们抛开具体的项目，更要抛开具体的技术，来考虑电力公司的基本业务需求：

电力公司的业务需求最主要是围绕着电网展开的，每一个系统都是围绕着电网开发的，只是关注的侧面有所不同。因此要做一个有延续性的框架，电网的模型是必不可少的，可以说是处于核心的地位。这个模型应该包括：电网的拓扑结构、各种网元设备（比如：输电线路、变压器、开关、发电机、用电负荷、等等）。

这个模型中还应该包括：电力公司的内部组织关系。比如：电力公司内的各部门、组之间的关系，以及他们与电网相关的一些重要的职能。

还应该包括：省级电力公司和合作组织之间的关系模型，比如：和各地市电力公司之间的关系模型、和发电站之间的关系模型、和变电站之间的关系模型、和用电单位之间的关系模型。

就像下面这样：



构建这些模型，完全是和具体的技术无关的，可以采用合适的任何技术。可以选用java，也可以用c++，也可以用.net，或者其他合适的东西，要考虑技术的成熟性和未来的发展趋势。

这些模型在电力公司的业务中是相对比较稳定的。有了这个东西，开发工作就不会每次都是从零开始，可以建立在一个稳固的基础上面。

比如，我们现在需要建立一个系统，对电网设备的实时运行数据进行监控。那么我们可以把系统建立在电网模型上面，主要关注设备的实时数据、控制命令。对于监控的工作还有一些职权流程方面的控制，那么内部的组织模型也能发挥作用。对于一些监控工作，需要各地的电力公司、电厂、变电站、用电单位采取配合措施，那么可以使用合作组织模型。

于是，这个系统的开发可以是下面这样的情况：



再比如，我们现在需要开发一个设备检修工作的控制系统。这个系统需要了解网元设备的拓扑结构，以确定某些设备可以一起检修，某些设备不能同时断电，安排检修工作，对检修期间的电网稳定性进行评估。这个系统可以建立在电网模型的基础上，主要关注电网的拓扑结构。客户需要对检修任务做具体安排，那么可以使用合作关系模型。于是系统是下面这样：



可以看出，各个系统都是把底层的几个模型拿来，关注其中的一些侧面，然后再加上个性化的需求。这样就能够加快开发的速度，减少公司开发新系统的成本和时间。

这个模型该如何得到呢？

首先应该借鉴一切可以得到的知识。比如：行业内的标准，国家颁布的规范。了解这些东西可以简化我们的分析过程，也能避免走弯路，犯错误。或者借鉴其他公司的相似产品，博采众长。

更加重要的是，要在开发项目的过程中要对这个模型不断的建立、完善，要把图纸上的构思切切实实的落实到代码里。

比如，我们在最初开发上面所说的那个设备监控系统的时候，首先应该考虑设计一个电网模型，建立网元设备的对象关系，实现电网的拓扑结构。而不应该急于进行数据库设计这样的细节工作。在建立电网模型之后，结合具体的项目需求进行分析，增强基础模型的健壮性。然后在这个基础上做具体的项目开发工作。

通过这样一个过程，电网模型就能够很好的建立起来，为以后的开发工作所用。

再比如，我们现在需要为电力公司做一个系统，对电网设备的资产情况进行管理。这时候我们需要充实电网模型，加入设备的资产属性的部分：



加入这个属性的时候需要注意，这个属性要和其他的一些属性相分离（比如实时运行数据），以免对互相的发展和应用造成以不良影响。在此基础上，开发项目的实际功能就比较容易了。

在这个过程中，需要处理一个难题，就是“急用为先”和“构架为先”之间的矛盾。关于这个话题，各个公司的情况千差万别，就不好说了。我只能说：即使在急用为先的压力下，也应该适当的考虑遵守底层模型的规定，并且一旦有条件，就应该把以前不符合构架的部分慢慢的并入一个正常的轨道。

下面谈一些自己对于技术学习的看法。对于一个程序员来说，掌握先进的技术是必须的。当技术达到一定程度之后，对于各种设计方式都有了一定的认识，然后会产生一种困惑：这些先进的技术，他们到底应该如何应用？.net和java哪个更好、linux和windows哪个更强、struts应该怎么用、spring是什么东西、orm有啥好处、设计模式该怎么用……

其实，要回答这些问题，不能只在技术上考虑，要跳出技术的圈子。站在用户的角度、业务的角度，自上而下的进行分析，就能够了解哪些东西才是重要的环节，那些问题其实是可以忽略不计的。技术本身没有优劣之分，要结合具体的需要，才好做出决定。程序员应该掌握技术，然后要跳出技术，专注于特定领域的业务（也许这个业务就是开发本身，例如你需要开发一个IDE，或者正在开发操作系统），真正为客户、也为公司做一些有价值的事情。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

''''''''''''''''''''''''''''''''''''''''''''
'发送Email的时候，会触发这个过程
'这段代码一定要写在发送Email的响应过程中
''''''''''''''''''''''''''''''''''''''''''''
Private Sub Application_ItemSend(ByVal Item As Object, Cancel As Boolean)
    On Error Resume Next
    Dim message As Outlook.MailItem
    Set message = Item
    
    If Not CheckAttachment(message) Then
        Cancel = True
        Exit Sub
    End If
End Sub

''''''''''''''''''''''''''''''''''''''''''''''
'检查标题或者正文里“附件”字样，是否可以发送附件？
''''''''''''''''''''''''''''''''''''''''''''''
Private Function CheckAttachment(message As Outlook.MailItem) As Boolean
    CheckAttachment = True
    If (message.Attachments.Count = 0 And _
            (InStr(message, "附件") > 0 Or InStr(message.Body, "附件") > 0)) Then
        Dim answer As VbMsgBoxResult
        answer = MsgBox("没有附件, 是否继续发送?", vbYesNo + vbQuestion, "Microsoft Office Outlook")
        If answer = vbNo Then
            CheckAttachment = False
        Else
            CheckAttachment = True
        End If
    End If
End Function

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

刚才看了idior的一篇文章：Enterprise Test Driven Develop。看后有一些感想，在这里写下这篇文章，讲讲我对这个问题的看法：自动化的单元测试应该测什么。

最近有朋友提出意见，觉得我写的文章比较空洞，写的很长，但是很不实在。可能原因是这样的：代码太少了。今天就从一段代码开始吧，这段代码描述电信营业系统中的缴费开机的过程：

User user = User.getUserByServiceId("13309790280");//通过电话号码找到用户
Account account = user.getAccount();//与用户关联的帐户
user.pay(100);//用户缴费100元

//判断用户余额＋帐户的信用度-用户欠费是否大于0
if (user.getBalance() + account.getCredit() - user.getDebt() > 0)
{
    Service service = user.getService();//与用户相关的服务
    //判断这个服务是否处于欠费停机状态
    if (service.getState() == "欠费停机" || service.getState() == "限制呼出") 
    {
        …//向交换系统发出开机指令
    }
}

这是电信营业系统中最常见的的一个业务。电信系统最基础的模型应该说是"三户模型"，三户模型描述的是客户（Customer）、帐户（Account）、用户（User）以及服务（Service）等等概念的一个关系模型。实际的模型比代码里的复杂，这里简化了很多，主要用来举个例子。

要开发一个电信系统，首先要做的就是在系统中实现最基础的几个模型，比如三户模型、联机指令模型、业务办理模型、合作伙伴模型……，其中三户模型处于非常重要的地位。首先要做的是在软件系统中真实的反映这个模型，绝不可以将其隐含扩散在各个业务过程中。然后就可以在这个基础上，从一到二、从二到三、从三到万，实现各个子系统和复杂多变的业务需求。

按照TDD的开发思路，我们应该先写测试代码，再来写实际程序，用测试来推动开发的前进。这里先把代码写出来，表达一下业务。下面我就说一下，单元测试代码应该测什么。

我们拿User举个例子，现在我们要写User类的测试代码。

需要测什么？

我们需要测试User类的外在表现。比如我们要测试pay方法，应该这样：

我们建立一个User对象，这个User余额是0，欠费38元。现在缴费100元，缴费完成后，余额应该是62元，欠费应该为0，这是一个Case。

我们建立一个User对象，这个User余额是30，欠费0。现在缴费50元，缴费完成后，欠费应该仍然是0，余额应该是80元。这是第二个Case。

我们建立一个User对象，这个User的余额是0，欠费150元。现在缴费70元，缴费完成后，欠费应该是80元，余额应该是0。这是第三个Case。

我们应该测试的是User类的外在表现，而不应该过问他如何实现。

在测试的时候，我们需要一个可以重复的稳定的环境（真实环境往往不行），有时候无法直接建立User对象（比如User对象要依赖一个数据集），有时候真实的环境很难实现一些测试条件（比如边界值、非正常值）。这时候，我们就可以使用Mock、Stub这样的方法，把User建立起来，也把环境建立起来，然后测试User的表现。

不需要测什么？

还是拿User举例子，还是测试pay方法，我们不应该测试这些东西：

缴费如何实现，这个费用保存到哪个数据表的哪个字段里去了，是否符合某种数据关系。

缴费以后的余额、欠费按照什么变量加减或者从某个数据字段中得到自己的值。这个不需要测。User类应该负责自己的费用问题，不应该把任何业务逻辑暴露给其他类（费用保存到哪里、什么数据结构，User应该负责）。外界只关心User的表现。

缴费后应该不应该向交换机发送开机的指令，这个就更不需要测试了，这是User的调用者应该负责的事情。

测试代码保证了什么？

测试代码只保证接口是正确的，至于业务正确不正确不是最关心的事情。比如User的测试代码，User把费用保存在数据表里、还是写在文件里，他是不关心的。甚至根本没有持久保存，他也不管，只要接口正确就通过。当然，内在实现上的错误总会通过接口表现出来。假如User没有把用户缴费保存起来，当我们在另外的空间中建立相同ID的另一个User对象时，就会得到错误的余额和欠费。

单元测试究竟有什么用？

从某种角度上说，单元测试并不能保证业务的正确性，而只能保证接口的正确性（严格的说，其实连接口的正确性也无法保证，他只能保证接口"没有这些错误"）。如果一个类总是自己在默默的工作着，不提供接口告诉外界他干了什么，测试他的业务是很难的（也不应该去测试，否则必然要插手他的业务）。那么单元测试究竟有什么用呢？

单元测试保证模块修改后的兼容性。可以通过单元测试来判断一个模块在修改后是否与修改前保持兼容、多大程度上不兼容、影响范围有多大。开发者就可以更加专注于模块内部的业务。单元测试无法代替人工的工作，他能够做到的是衡量一个模块修改后会不会影响其他模块的工作。这对程序的维护和升级有非常大的好处。
 

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

什么是重构

重构，用最简单的一句话说：就是要在不改变系统功能的情况下，对系统的内部结构进行重新调整。重构的最直接目的在于改进软件系统的内部架构。一个好的结构可以更加适应于需求的变化，更好的满足客户的需求，最大限度的延长软件系统的生命周期。

为什么要重构

在不改变系统功能的情况下，改变系统的实现方式。为什么要这么做？投入精力不用来满足客户关心的需求，而是仅仅改变了软件的实现方式，这是否是在浪费客户的投资呢？

重构的重要性要从软件的生命周期说起。软件不同与普通的产品，他是一种智力产品，没有具体的物理形态。一个软件不可能发生物理损耗，界面上的按钮永远不会因为按动次数太多而发生接触不良。那么为什么一个软件制造出来以后，却不能永远使用下去呢？

对软件的生命造成威胁的因素只有一个：需求的变更。一个软件总是为解决某种特定的需求而产生，时代在发展，客户的业务也在发生变化。有的需求相对稳定一些，有的需求变化的比较剧烈，还有的需求已经消失了，或者转化成了别的需求。在这种情况下，软件必须相应的改变。

考虑到成本和时间等因素，当然不是所有的需求变化都要在软件系统中实现。但是总的说来，软件要适应需求的变化，以保持自己的生命力。

这就产生了一种糟糕的现象：软件产品最初制造出来，是经过精心的设计，具有良好架构的。但是随着时间的发展、需求的变化，必须不断的修改原有的功能、追加新的功能，还免不了有一些缺陷需要修改。为了实现变更，不可避免的要违反最初的设计构架。经过一段时间以后，软件的架构就千疮百孔了。bug越来越多，越来越难维护，新的需求越来越难实现，软件的构架对新的需求渐渐的失去支持能力，而是成为一种制约。最后新需求的开发成本会超过开发一个新的软件的成本，这就是这个软件系统的生命走到尽头的时候。

重构就能够最大限度的避免这样一种现象。系统发展到一定阶段后，使用重构的方式，不改变系统的外部功能，只对内部的结构进行重新的整理。通过重构，不断的调整系统的结构，使系统对于需求的变更始终具有较强的适应能力。

拒绝变化 VS 拥抱变化

按照传统的软件设计方式，软件的生产分为需求调查、概要设计、详细设计、编码、单体测试、联合测试、现场部署几个阶段。虽说这几个阶段是可以互相渗透，但是总的来说是有一定次序的，前一个阶段的工作是后一个阶段工作的基础。这就向下面这样一种V形的模式：



往下的方向将系统进行分解，往上的方向将系统进行整合。这样的开发形式将软件开发分为设计前和设计后两个阶段，开发过程中存在一个重要的“里程碑”——设计说明书的。在设计说明书完成前，工程处于“设计”阶段，而在设计说明书完成之后，工程则进入“实施”阶段。一旦到了实施阶段，任何需求或者设计上的变更都是非常困难的，需要花费大量的成本。通常为了保证工程的顺利实施，开发人员常有这样一种冲动：按住客户的手，在需求说明书上签字。并且告诉客户：“从今天开始，任何需求变更都要停止，直到我们把现在这个东西做完。”这是一种拒绝变化的开发方式。

软件系统要保持与企业的目标一致。时代在发展，人们的要求在不断的提高，客户的业务在不断的发展。在这种情况下，传统的先设计、再施工的V形式已经不能适应日益复杂的业务需要。软件工程逐渐演化成下面这样的过程：



说明一下：
1、软件开发的目标要与企业目标保持一致，一个开发周期不宜时间过长，一般控制在半年到一年。系统部署后，并不意味着开发工作结束了，而是进入了下一个周期。

2、工程以循环迭代的方式前进，这并不意味轻视了设计，不是要搞边调研、边设计、边施工的“三边”工程，相反，是更加重视设计的地位。软件开发的全过程都需要设计，软件开发是“持续设计”的过程。同时，设计工作也不只是简单过程分解、任务分配，而是概念设计、逻辑设计、物理设计等各个方面互相交织、齐头并进。

传统的软件开发方式使用一种非常理想化的流程——先与客户讨论项目的范围，确定哪些需要做，哪些不需要做，然后规划一个完美的设计，不仅可以满足现在的需求，还能很好的适应未来的需求，设计完成后开始编码，然后测试组装，送到现场安装调试运行。这一系列过程就类似与发射一颗炮弹，首先要找到目标，然后根据地形、风力、目标的位置、移动速度等各种因素，计算提前量、炮弹发射的角度，计算出一个抛物线轨道，最后在合适的时间把炮弹发射出去。这一切都符合最正确的物理定律，一切都听起来很理想。如果没有意外条件，当然是可以击中目标的。但是炮弹一旦发射出去，一切就失去了控制，任何环境的变化都会造成偏离目标。尤其是对于一个运动的目标来说，计算过程十分复杂，很多情况下只能靠人估计。对于不规则的运动目标只能碰碰运气。这样的方式，命中率是很低的。

新的软件开发过程不追求完美的、长期的、理想的计划，更加重视实际情况，重视需求的变化，提倡采用短期的计划。这是一种拥抱变化的过程。就象是在炮弹上安装了一个反馈装置，锁定目标后，确保大方向的正确，然后就将炮弹发射出去。炮弹在运行过程中不断的将目标位置偏移量输入反馈电路，根据反馈输出调整自己的运行路线，无限的逼近目标。这样，炮弹就拥有了制导能力，命中率大大增加。

重构就可以增加工程的调整能力，他可以把产品回复到一个稳定的状态，可以基于这个状态达到下一个目标。如此反复前进，更好的满足客户的需求。

保持兼容性

重构的目的在于改变系统的实现方式，而不改变原有的功能。这个过程中，判断兼容性就十分的重要。一个子系统、模块、类、函数是否与升级前保持兼容，如何判断这个兼容性，如何保持这个兼容性，这关系到重构的成本和重构的可能性。

程序员学习写程序代码时，会发现随着程序代码愈来愈多，许多的程序代码不断重复出现和被使用，因此很自然的开始使用例程、子程序或是过程、函数等机制帮助我们进行程序代码整理的工作。于是很自然的，字体的分析方式演化成这个样子：将客户的需求过程进行分解，一步一步的分解，直到可以直接的实现他。这就是面向过程的分析方式。

面向过程的分析方式对变化的能力是很弱的。为什么呢？因为面向过程的分析方式很容易造成一种倾向——不区分行动的主体。一个过程是没有主体的，他不是在为自己工作，而是在为“别人”工作。当我们修改了一个过程之后，我们很难判断这个过程是否保持向后兼容，其他过程会不会受到影响。因为这个过程对外界有意义的不仅是他的输入和输出，还包括每一步过程，每一步过程都可能含有一个非常隐讳的业务意义，对外界产生影响。

因此，修改一个过程是非常困难的，通常升级一个面向过程的系统，可以采用两种方式：
1、写新的过程；
2、在原有的过程上加开关参数。

除此以外的升级办法都很难保证原过程和新过程的兼容性，容易造成错误。

为了更好的保证升级后模块的兼容性，应该采用面向对象的分析方式。按照这样的分析方式，一个对象为“自己”工作，他有完整的、独立的业务含义。对象之间通过接口发生联系，一个对象对外界有影响的部分只有接口，至于他做什么、如何做、做的对不对，则不是外界需要关心的事情。

判断一个接口升级后是否保持兼容性就是一件比较容易的事情了。我们可以判断接口的输入输出是否符合下面两条规则：
1、升级后的输入是升级前的输入的超级；
2、升级后的输出是升级前的输出的子集。

只要符合这两点，他就仍然可以在系统中运行，不会对其他对象造成危害。在实际的工程中，判断这个兼容性有一个更好的办法：自动化的单元测试。

在重构的过程中，自动化的单元测试是非常好的保障。采用自动化的单元测试，不断运行测试，可以保证系统的结构改变的过程中，业务行为不发生改变。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

几个月前从一家软件企业来到一家通信公司工作，进入了计费与信息系统部。这个部门维护着公司中的几个重要的系统：营业、计费、帐务、客户服务、资源管理、经营分析、产品销售，这些系统是公司业务的基础。通过几个月的忙碌，渐渐的熟悉了同事，也熟悉了工作环境，对于所维护的系统也有了越来越深的了解。

营业和帐务系统的开发商是由一家位于东北的软件公司。这是一家上市公司，CMM5级，在通信、医疗、教育等多个行业都有产品，其中通信系统遍布全国的十几个省。开发商在我们的现场有十多个现场维护人员，协助我们进行营业和帐务系统的运行维护工作。系统的升级、新需求的分析都需要他们的协助。

通过几个月的接触，了解了开发商的一些特点。最近有机会来到他们的总部，更是近距离的体验了他们的研发过程。开发商的一个很大的特点，就是采用“统一版本”的方式。具体的说就是：现场的维护人员原则上是不可以对代码做改动的。如果现场程序出现了问题，维护人员必须将现象和原因报告给总部的开发人员，由开发人员进行修改，然后总部发布新的版本，现场人员重新部署。客户提出了新的需求，也要现场人员进行分析以后提交到总部，进行统一的评估和测算，决定是否可以实现，用什么方式实现，然后将升级后的版本下发到各个省。这就是统一版本。全国各个省，都只使用同一个版本序列，各省根据自己的需要采用不同的版本号。各版本在总部统一维护，统一的规划，统一的标准，统一的软件。

统一版本的实质是追求思想的统一，避免在各个地区之间出现分歧。人的思想是一种非常复杂的东西，尤其软件开发是一种以脑力为主的劳动，需要大量的沟通才能减少误会。一百个人总会有一百个想法。在各个地区间采用统一的版本，由总部实行严格的管理，在软件的设计上和实施上就避免了意见分歧。

从项目管理的角度来说，采用统一版本的方式有利于对项目的范围和成本进行控制。客户的需求做不做，如何实现，什么时候实现，都由总部进行统一的规划，统一安排开发任务，实现在统一的版本中，然后下发到各地实施。这样就最大程度的避免了各地各自为战，原则不一致的现象。总部对各地维护人员的控制力是非常强的。

采用这样一种开发和维护方式，由总部的研发人员进行设计和开发，测试之后下发到各个省，由各省的现场维护人员进行部署和维护。软件系统在运行过程中发现错误，现场人员分析现场的状况，然后将情况反应到总部，由总部寻找具体的原因，进行修改后，现场人员重新部署。客户如果有新的需求，可以和现场人员一起进行探讨，现场人员向总部提出。总部对各个省的需求进行统一的规划，安排研发任务，测试完成以后再重新到现场部署。总部的开发人员和现场维护人员之间采用这样的分工方式：总部人员集中了技术能力，可以统一安排各个省的研发任务，统一调度。现场人员了解实际的软硬件环境，了解客户的实际需求。这样的分工看起来是非常合理的。

对于通信企业的应用系统来说，尽管在各个地区在业务方式上有各自的特殊情况，对系统的要求也不尽相同，但是毕竟是同样的经营领域，同样的企业性质，以共性为主，各省之间共同点是非常多的。采用统一的版本管理方式，也能够避免在不同版本之间重复实现一些共同的功能，避免重复的劳动，提高了开发工作的效率。

然而，采用这样的统一版本的方式，也带来不少问题。

最显然的问题就是：采用这样的方式，现场出现的问题和客户提出的需求无法得到及时的解决。通常是在现场发现一个故障，经过检查只不过是一个非常容易解决的问题。但是在统一版本的规则下，现场维护人员对版本没有控制权，必须向总部反应情况，得到解决之后再下发新的版本。这个过程有时候是相当长的。对于客户提出的新的需求，现场人员在经过分析后，也要提交到总部进行统一的规划，总部的人员对现场情况要进行了解，然后再统一的规划设计，安排开发力量。这样一个过程下来，环节很多，时间往往相当的长，要受到很多条件的限制。信息系统部经常因此面对业务部门大量的压力。如果能够将部分控制权交给现场的维护人员，对于简单的明显的故障、本地化的需求可以自行解决，在过程中保持和总部的协调，应该是一种更加理想的方式。

在系统的运行维护过程中，现场的维护人员经常比较忙碌，压力也是比较大的。由于总部的开发人员发过来的程序总是会出现各种问题，造成现场运维人员处于救火状态，难以抽出时间和人力对需求进行思考，没有精力分析客户的业务。总部的开发人员远在东北，他们了解现场需求的唯一途径就是通过现场维护人员。这样一来，形成了研发人员不了解需求的局面，开发质量难以保证。并且，一些地区的个性化需求无法在总部进行有效的测试，这些代码没有经过测试就发到现场，交给维护人员测试、部署。这样就使得总部的开发人员受到的质量压力过小，不注重提高质量，进一步造成质量下降。然后运维人员更加忙于救火，更加没有精力分析需求。

对需求没有了解，对现场的环境也缺乏直观的感受，造成设计和开发人员不注重用户的需求。研发人员经常是局限在技术细节中，将生动的客户需求生硬的理解成数据库的增删查改，顺带再向交换发几条指令。这样的研发过程，生产出来的软件是非常不好用的，功能凌乱，文档不着边际，bug也很多。造成用户操作和极其复杂，思想压力也比较大。

将所有的版本都放在总部统一管理，实际效果也并不理想。统一版本的管理工作是十分复杂的。各省都有特定的环境，都有一些特殊的需求，为了适应本地的环境、实现这些需求而开发了一些功能。每个地市的版本都处于动态的变化中，新的需求要做，旧版本上还有bug要改，整体结构的开发仍然在进行，造成分支复杂，版本很多，管理难度巨大，经常出现错误。总部发到地区的程序部署以后，总会发现以前曾经实现的需求又不见了，以前消灭过的bug又出现了。客户和运维人员很多精力耗费在丢失的功能和重现的bug中。由于版本管理方面有这方面的问题，产品的升级工作带来了巨大的困难。

电信企业需求可以分为两个层次，首先是具有行业特点的普遍性需求，这种需求较为稳定。其次是各运营商的个性化需求，这种需求复杂多变。各层次的需求应该由不同的人员、在不同的子系统中实现。核心的部分由一个小组进行开发，然后各个小组在这个基础上实现各地区特定的需求。底层的子系统的在进化的过程中，只要保持向后的兼容性，各地区的版本就不会受到影响。这样化整为零，减少了版本的复杂程度。升级维护都比较方便，也能够快速的响应个别客户的特别的需求。这样的开发形式是比较合理的。然而，开发商采用的是总部全权负责研发，现场全权负责维护的形式。总部研发人员负责全部的设计、编码、测试工作。在这种管理模式下，系统形成了一个统一的大版本，各地区的需求都实现在这个版本中。各地的一些需求相差较大，强行统一在一个版本中，甚至出现了下面这样的代码：

if 四川 then
　　......
else if 云南 then
　　......
else
　　......
end if

总部的开发人员没有在普遍需求和特定需求之间进行合理的分工，无法专注于解决行业内的普遍需求，有限的人力纠缠在各个地区独特的软硬件环境、应付独特的商业需求，耗费在细节上。而各地的维护人员面对着总部发过来的低质量的代码、僵化的设计、混乱的版本，部署维护困难重重。需求不能得到及时满足，程序bug需要漫长的过程才能改正，运营商得不到有力的支持。

软件系统的开发，技术无疑是重要的，但决不是最重要的，业务需求始终要在最重要的位置。技术的目的就是要在项目中消除技术问题，到最后开发者和客户在一起谈论的是用户的需求，互相之间不是用技术语言交谈，而是用客户的业务语言交谈。做到这一点，才是技术的成功之处。开发商现在已经为这个项目工作了多年，在多个地区都有了部署，现在仍然在和客户谈论数据库表、存储过程，不能深入到客户的业务中去。这不是一种理想的状态。

好的软件是用什么做出来的？不是用手，也不是用脑，而是用脚做出来的。要走出办公室，多跑一些地方，仔细的研究调查，才有可能了解客户，理解客户的需要。最后才能站在客户的角度考虑问题。这样做出来的东西，才是客户真正需要的东西。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

很多法规的想法是非常好的，如果大家都能遵守的话，对于整个社会是很有好处的。但是经常有人不遵守这些法规，这是为什么呢？是这些人没有认识到这样的法规对大家都有好处吗，思想觉悟低。于是加强宣传，思想教育，效果不明显。加强违规的惩罚力度，有时候违法的现象依然严重。在很多情况下制度不过是摆设，另有一套潜规则被大家默默奉行着。

举一个例子：银行存款实行实名制。这是个好规定，按照这个制度的设想，能够大量的避免经济诈骗、信用卡透支、贪污腐败。但是这个制度看起来只对老实人有效，仍然有人可以轻易的获得匿名存则用于诈骗活动。这是为什么呢？

一个制度能否得到遵守，在于他是否顺应了利益的规律。政府颁布的法规，企业公布的制度，都是一种明规则。明规则反映了人们的一种美好的理想。但是这样的规则不一定能顺应利益的规律。一旦明规则违反了利益规律，就会失去效力。同时，另外一套规则就会取而代之。这套规则没有明确的文字，也没有人去刻意宣传。在实践中逐渐进化，建立在实际的力量对比基础上，具有坚强的生命力，这就是潜规则。

比如存款实名制，这个制度的直接执行者是银行。对于银行来说，能够吸引到客户无论对银行整体，还是对银行中的员工都是有利的。而客户使用存款帐户进行诈骗，则不需要他们承担任何责任。在这样的情况下，这个实名制能不能得到贯彻，能不能发挥预想的效果，就是可想而知的了。

明规则不能起作用，潜规则就来了。用别人的身份证，假的身份证都可以在银行开户，在纸上写下自己的号码塞到柜台里去有时候也可以，这就是潜规则。遵守这个潜规则，大家就都方便了。明规则忽视了权利的平衡，潜规则重新找到了这个平衡。那些坚持制度的银行会因为办理业务不方便，反而失去客户。不遵守潜规则要受到惩罚，真正起作用的是潜规则。一个制度的初衷是好的，但是没有符合利益的规律，又没有合理的奖惩手段来强化这种利益关系，就起不到效果。有时候甚至造成老实人吃亏，淘汰的都是清官。

中国古代有不少皇帝，为了实现自己的理想，颁布了不少法令。皇帝有着最高的政治权利，但是这些法令也有很多成为摆设。只要忽略了利益方面的协调和引导，皇帝也管不住。

最近有人提出一个意见：电信商提供移动通信服务要采用实名制。如果靠电信商、代理商自己执行，这个规定肯定还是个摆设。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

谈到应用程序的层次，我们平时所说的层次有两种：逻辑的层次（layer）和部署的层次（tier）。这两种层次划分的目的是不同的，因此划分方式也有一些差异，能够为应用程序带来的好处也是不同的。

逻辑层次

逻辑层次（layer）划分的最重要的目的在于调整应用程序各部分之间的依赖关系。应用程序可以看作数据和业务规则的集合，这个集合通过用户界面与用户发生交互。如果不划分层次，或者只划分最简单的层次，系统的结构就会是这样：数据库处于系统的中心地位，在此之上建立用户界面，业务规则写在用户界面里。

这样做的问题在于：数据库作为应用程序的中心是不合适的，因为数据库只负责存储数据，而不能对数据做出解释（这是业务规则的任务），而业务规则分散在非中心的位置，零散的表达在用户界面中。一旦需求改变，业务规则必须随之改变，而业务规则是分散在各处的，我们就要四处寻找业务规则，进行修改。随着应用程序规模的扩大，这是一项非常艰难的任务。

为了解决复杂的依赖关系，我们创建了业务层。典型的逻辑分层结构就是：表示层->业务层->数据层。

建立业务层的方式可以非常简单：假如我们的应用程序要进行多项业务，我们分析这些业务的流程，找出这些流程中共同的部分，提取他们作为独立的过程，这就形成了最简单的业务层。这样，不同的界面之间