小A是支枪，子弹未打光----之"狙击步枪"篇

在开始今天的正文之前，先举一个例子，话说：

一位老太太离开家门，拎着篮子去楼下的菜市场买水果。她来到第一个小贩的水果摊前问道：

“这李子怎么样？”

“我的李子又大又甜，特别好吃。”小贩回答。

老太太摇了摇头没有买。她向另外一个小贩走去问道：“你的李子好吃吗？”

“我这里是李子专卖，各种各样的李子都有。您要什么样的李子？”

“我要买酸一点儿的。”

“我这篮李子酸得咬一口就流口水，您要多少？”

“来一斤吧。”老太太买完李子继续在市场中逛，又看到一个小贩的摊上也有李子，又大又

圆非常抢眼，便问水果摊后的小贩：“你的李子多少钱一斤？”

“您好，您问哪种李子？”

“我要酸一点儿的。”

“别人买李子都要又大又甜的，您为什么要酸的李子呢？”

“我儿媳妇要生孩子了，想吃酸的。”

“老太太，您对儿媳妇真体贴，她想吃酸的，说明她一定能给您生个大胖孙子。您要多少？”

“我再来一斤吧。”老太太被小贩说得很高兴，便又买了一斤。

小贩一边称李子一边继续问：“您知道孕妇最需要什么营养吗？”

“不知道。”

“孕妇特别需要补充维生素。您知道哪种水果含维生素最多吗？”

“不清楚。”

“猕猴桃含有多种维生素，特别适合孕妇。您要给您儿媳妇天天吃猕猴桃，她一高兴，说不

定能一下给您生出一对双胞胎。”

“是吗？好啊，那我就再来一斤猕猴桃。”

“您人真好，谁摊上您这样的婆婆，一定有福气。”小贩开始给老太太称猕猴桃，嘴里也不

闲着：“我每天都在这儿摆摊，水果都是当天从批发市场找新鲜的批发来的，您媳妇要是吃好了，

您再来。”

“行。”老太太被小贩说得高兴，提了水果边付账边应承着。

其实通过上面的例子，不难发现，在三个小贩向老太太推荐自己的卖的水果时，出现了三种

不同的结果．其中＂

第一个小贩一上来就不问清红皂白，只掌握了表面的需求（老太太要买）就完全用自己的主

观臆测来向客户推荐自己的商品（我的李子又大又甜）．这种情况其实多出现在新手或那些急于

写代码的程序员．

第二种则是比第一种要更成熟，他在耐心听完客户的描述（老太太想买酸李子）之后才开始

介绍推销自己的李子．这种情况是一般软件设计过程中通用的做法，即根据客户的目标和愿望（

老太太买李子不是为了儿媳妇而是为了抱孙子）直接进行开发的，需求分析做的一般，这也是目

前IT公司比较普遍的做法．

第三种显然要比前两种高明的多，因为他所销售的弥猴桃要比李子贵很多．其实他这里用的

是销售中比较高明的手段，就是在归纳用户需求的基本上，通过分析来引导用户需求，从而最终

超越并创造出新的客户需求．

所以这里需求要分为表面需求（如产品和采购指标）和深层次的潜在需求（客户遇到的问题）

其实与客户交流时常发生．每一个到你公司寻求帮助（解决方案）的客户其实都可以把他们

做为一个病人，而我们就是医生（有专业的架构和开发经验和行业背景）．而病人通常是不会知

道自己的病因是什么，只会按表面层次上所体现的症状来让你诊断，而医生通常在了解用户问题

(他的需求)后，会结合自身的经验（行业知识）来帮助用户找出真正的病根所在（即挖掘出需求

背后的需求）．这种抓药方式才是真正的治标治本．

其实一般的技术人中因为平时过于关注技术本身，会有意无意的忽略上面的问题．而其实恰

恰是只有真正理解和重视用户需求，才能让我们从所谓的"技术开发核心"转型到"分析和设计核

心"上来．而如果不重视需求分析，我们就会像第一个小贩那样，最终什么都得不到，即使我们对

这个客户说我们采用了什么高新技术，什么优秀框架等等，用户也只会云里雾里一头雾水，最终

还是无法让其真正将预算投给我们．

说到这里，有必要介绍一下SOA了，不是因为它时髦，而是SOA其实还是一个面向业务需求

的架构方式，这里不要太在意"面向服务"这几个字，其实归根结底最终还是面向需求，面向" 时刻

在变动的" 需求．因为公司企业在激烈的市场竞争中需要灵活配置，快速响应的系统．通过SOA

精心设计的体系架构"实现"商业利益（因为标准不是架构，架构也不是"实现"）并让公司企业迅速

抓住在市场出现稍纵即逝的商业机会．而这才是SOA真正存在的价值．从这个角度上讲，SOA的

应用范畴要在EAI之上，尽管用SOA架构方式进行EAI整合是不错的选择 (因为从头进行SOA架构

对一个有一定的 IT资产(硬+软件)的公司却无疑是一次大的手术．)

SOA的发展可以分为两个阶段，以2006为"分水岭"，2005年以前是各大软件供应商均专注于

自己的 SOA理论研究和框架开发．2006年以后各个大型软件服务提供商开始结成盟，陆续形成了

一系统 SOA规范和标准，并推出各自的面向SOA开发，发布，运营服务产品，如：

BEA：EAI软件Tuxedo、应用服务器WebLogic以及SOA信息传输软件AquaLogic等通基础平台　

IBM: WebSphere 等　　

Oracle: Oracle SOA套件 等

SAP : Enterprise Services Architecture Adoption Program(企业服务架构验收程序) 等

Microsoft: WCF,BizTalk Server(充当ESB角色)等

SOA只是一种架构软件的方式，并不是什么新技术，甚至有专家提出即便使用CORBA（Common

Object Request Broker Architecture），DCOM等老牌技术也可以开发出SOA应用．

当然在形成了事实标准之后，一系列规范也相应出台，如SCA(服务组件架构：Service Co-　

mponent Architecture), SDO(服务数据对象：Service Data Objects) ,BPEL(业务流程执行

语言:Business Process Execution Language, 最初是由BEA、IBM和Microsoft联合制订),

ESB(企业服务总线：Enterprise Service Bus)等等．

说了上面这些东西，可以有些朋友开始奇怪我为什么要把写作方向转到SOA上，主要还是因为

业务需求的关系．之前已说过业务需求在实际设计开发的重要性．而做为小A这个技术型从业者而

言，当其遇到技术和业务需求这两方面的问题时，即使知道业务很重要，但也需要一个切入点来帮

助其过渡到重视公司业务上来．而通过SOA的学习，可以一方面研究新的软件架构技术，比如微软

的WCF，另一方面各大公司无论从白皮书到实际案例上都会有关于业务需求分析方面的内容介绍．

所以通过研究SOA，可以满足其同时钻研技术和业务的双层需要．所以小A隐约感觉这是一个切入

点．而下面这张表格摘自园子里一位朋友翻译的SOA in the Real World.pdf的内容，可以帮助理

清一些概念和认识上的问题:)

做应该做的事情并不容易，不多也不少就更加困难了。那么，我们应该从需求分析阶段开始就

引入“明智”。

用UML为软件的所有部分进行建模并不“明智”；不进行建模，直接编码同样不是 “明智”之举。

而找出真正需要建模和编码的东西才是“明智”的。那些“东西”是什么呢？他们是最本质的用例和对

这些用例所处场景的本质。他们是实现了场景本质的组件和这些组件中的特殊部分。因此，事关

本质。

而去年他老人家就向敏捷开发抛出了某些友善信号，请看这篇文章：敏捷到底是什么？

其核心内容如下：

敏捷是关于以下三件事情的：

1.最重要的，敏捷是一门社会工程学。这是敏捷最大的特点。它关注的是，如何以一个团队的

形式开展工作，如何激励团队成员，如何相互合作等等。

2.敏捷是轻量级的。RUP完全依赖显性知识，与此不同，敏捷还依赖隐性知识。在RUP中，我

设法把我们认为是最佳的实践记录下来。然而，人们根本不阅读关于开发过程方面的书，写下这些

书也就毫无意义了。相反，敏捷认为，只要有掌握足够知识的人，就可以开发出优秀的软件。当然，

这个观点倍受质疑，但是事实的确如此。

3.敏捷提供技术实践。这其实是敏捷中贡献最微弱的部分。它所提供的技术实践几乎没有包括

新技术。迭代与增量式开发，都是存在很久的观点。用户故事，则是某种特殊类型的简化版用例。

最为有趣的新想法就是测试驱动的开发。我并不是说敏捷技术实践毫无价值，而只是强调，如果它

仅仅就是这些内容的话，我们就不会为敏捷如此痴迷了。

看来UP阵营表现的比较大度，很有"大家"风范，小A也期盼着这两种开发方法和平共处，共同

繁荣的那一天．

好了，到此今天的内容就要结束了．

当然本文的内容有一定的主观因素影响，是小A 结合自身性格和技术特点所做出的某种选择，

不确保本文发表后将来还是"一程不变"．所以大家不用生搬硬套．另外希望本文能为鼓励大家寻找

思路提供一些"愚见"．如果不同意本文观点，请在看完之后尽快忘记所谈内容，以免误人前程．

好了，今天的内容就先到这里了．有兴趣的朋友可以在回复中进行讨论．

tag:开发,webservice,soa,wcf,手 枪,步枪,framework,SNS,UP,agile

作者:代震军,daizhj

原文链接:http://www.cnblogs.com/daizhj/archive/2008/09/12/1289817.html