成功，是世界上最让人向往的东西，因为它代表着自由、富裕、尊重。然而成功的过程决不“人道”：10000个也许是认为最聪明绝顶的人，历经资金、商业模式、管理、竞争的重重磨难，躲过命运的无情盘剥，也许最后才有几个人能偶尔活下来，接受更严峻的发展考验。所以，成功的创业者才显得逾足珍贵。

残酷吗，子非创业者，焉之创业之乐，就是有一些不安分的人把每一个困难的克服当作天下最幸福的事，沉浸在不断成长的乐趣中。在他们眼中，人生百年，转瞬即逝，留下一段经历，比平庸而终老更有意义。

然而，也有人说：子非创业者，怎知创业之不乐，也许创业根本就是一杯毒酒， “努力就会成功”这个最古老最罪恶的谎言，打乱了多少人原本自在的生活，让这些本应在各自岗位上做出丰功伟绩的人，就在这样错位的奋斗中崩溃。

一个故事为证：

他很聪明，在一家几百人的企业，他负责一个不大不小的部门。他的智慧和能力解决了很多业务中的难题，领导赏识他，同事佩服他，收入一直不错，他自己也获得骄傲而满足。

他有一个女友，漂亮俏皮而青春活泼，两人走在一起时，不时会引起路人羡慕的眼光。但是他总觉得差点什么，总觉得不满足，特别在女友看到橱窗里硕大的钻戒和偶尔路上晃过的开着宝马的富豪时，这种感觉格外明显。直到有一天，一个人无意中赞扬了他一句：你应该当老板，才让他终于恍然大悟自己在为什么难受，“创业”开始象毒蛇一样缠绕在他心间，挥之不去，原本开心的工作怎么也提不起兴趣。

又一个失眠的早上，他突然决定了，于是他对女友说：我要辞职，去创业。女友有点担心，但是想到他的能力还有成功，默默的点头了。和家里壮志豪言的说出了自己的理由，家人也表示默许。受到爱人和家人鼓舞的他，兴冲冲的向公司的递交了辞呈，在领导惋惜的目光和众人不解的神情下，头也不回的走出大门，仿佛正在走向亿万财富、鲜花和掌声。

费尽口舌，求朋友、告奶奶筹集了全部可以借到的资金，跑断腿的办理完工商营业执照和选址租办公场地，一间象模象样的公司就这样成立了。第一天在自己的公司上班，看着刚刚上岗的员工，他热泪盈眶，骄傲的仿佛世界之王。

后面的日子是忙碌而充实的，员工培训、熟悉业务，让他有点小小的着急，为什么员工就不能向他一样融会贯通这么简单的一个商业模式呢。不过转念想想自己的能力也许特别强，也就只能暂时安慰自己-----一切需要一个过程。

慢慢的也有几笔小单回来，虽然多数是自己参与其中指导，但是也足以让他更加信心百倍。庆功、喝酒，一切激励似乎作的尽善尽美，但是很发现，业务永远在这样一个层次，无法逾越。开会，每个部门都说到资源不够，他有点恼火，小公司永远都是资源不足的，如果这么大的投入，是个傻子也可以做出业绩来，还要他们做什么？这些事情如果是自己做，可以想出很多办法解决，但是一个公司能靠自己一个人做吗。所以怒火还是得忍着，毕竟依靠兄弟们，于是继续鼓励，并调整新的激励政策。

随着业务不温不火的开始有所转机，他突然发现现金流这个东西有点不足了，毕竟市场投入前期的回报率是极低的，眼看发完这个月的工资可能会有问题，而此时手下一个大单，一旦成交可以扭转整个公司的局面，让他必须做决定赌一把。带着几个人拼死拼活的研究方案，请客吃饭，不会喝酒的他经常喝得烂醉回家，让曾经向公主一样的女友，含着眼泪、捏着鼻子伺候着吐出的秽物。而此时，他们也很久没有像以前那样牵着手看夕阳了，每次当女友提出看电影或是旅游，他都哄着她说现在还很忙，等业务上了轨道就会去。于是女友虽然不高兴，还是撅嘴答应了。

在业务即将成交的头晚，最让人担心的事情还是出现了，竞争对手眼看无望，调整新的价格体系，让客户顿时犹豫了起来，于是周期顿时延长，心急如焚的他恨不得下跪也无法打动客户坚毅的神情，市场经济就是这么残酷无情。而资金也适时地终于见底了，员工开始有了点小波动。他周旋稳定员工和争取客户当中，同时又陷入了借钱的尴尬。而就在这时，更坏的消息传来，更大的竞争对手终于嗅到了肉香，参与进来，以雄厚的资金，超乎想象的价格拿走了这个单。

于是他绝望了，在部门的检讨会上，他声色俱厉的训斥几个失职人员，长久以来积累的情绪终于爆发。而那几个员工也同样委屈，毕竟为了这个项目，他们也付出了很多。终于，和谐的气氛打破了，在持续收到几份辞呈之后，公司陷入一种微妙的状态：留下来的都是安于现状的人，不推不动的消耗着他剩余不多的资金。这时候，家人的一句善意的责怪这个项目考虑不周，都让他暴跳如雷，女友嚷着要出游更是让他心烦意乱，有点责怪为什么此时她就不能多为他考虑。

麻烦的事情才刚刚开始，借款的朋友急需用钱，临时请他还钱；税务机关三番五次上门清查，因为本来就不是太干净的发票问题开始有点纠缠不清；员工的保险未办，遭到有关部门的警告，还有就是市场又出现了他们产品的仿制品····

一切开始混乱了，他每天在不同的事务间疲于奔命，而员工的积极性越来越低，他经常看到他们正在用公司的电脑打简历。市场无法投入更多的费用，老客户开始对后续延迟的服务不满。最严重的是几个员工要为拖欠的工资上告。他开始陷入恐慌，开始害怕到这个地方，整晚的失眠，在网络上漫无目的的找应对办法。他的情绪进一步引起投资人的恐慌，大家开始有意的提醒他还钱。

终于，公司还是毫无悬念的破产了，员工不欢而散，由于没有拿到全额的工资而恶言相对，税务的罚款、还贷耗尽了他本来不多的老婆本。把最后的手续办完，坐在零乱而空旷的办公室，他忽然想起很久没有联系的女友，掏出手机打个电话，却听到了女友不耐烦的回答和旁边另外一个男人的声音！

这天，他仿佛老了很多，深陷的、布满血丝的眼睛完全失去了以往的神采，让人不相信他就是那个曾经风光无限的明星员工。明天，他又要开始找新的工作，想象到碰上原来同事时，大家的眼光让他无地自容。家人是唯一的港湾，但偶尔也会流出惋惜的叹气，看着父母日渐佝偻的背影，他感到坐立不安。但是，看着欠下的帐单，即使明天更加无望，一切也只能这样继续。

有一天他突然明白了些什么，创业并非像人们所说的那样简单，里面包含了一些道理：商业模式、财务管理、人力资源管理、客户管理、品牌管理、生产管理等等知识短板，正是这些曾经不起眼的知识让他陷入困境。他笑了，不过是苦涩的笑，今天明白了，明天会继续选择这条路吗？

不要以为这是我编的故事，这是很多朋友都很熟悉的情节，只是随着主人公和剧情的不同，每天不断在各个城市上演，包括我自己本人。在成功者的光环后，谁又看到他们每天只睡3个多小时，身体健康极度恶化，最后猝死在自己的办工桌前。在创业的路上，从来没有“付出就有回报，努力就会成功”的这种说法，一场非典、一个政策，都会让你苦心经营的根基彻底摧毁。一个小疏忽，一时情绪的失控，就会让你走向灭亡，这就是我为什么在沙盘模拟中突然冒出一身冷汗的原因。

所以后来很多朋友问我创业怎么才能成功，我往往告诉他们，创业，首先不是考虑怎么成功，而是考虑如果失败了，你失去了一切，是否还能重新爬起来继续前行。所以，当你准备创业了，你就如同准备饮下一杯毒酒，你的身体将是你最大的赌注。

曼生，你明白了吗，现在的一切本来就是我们当初的决定所注定要面临到的问题，创业本不能承受生命之重，它只是一种生活方式，为了让我们在老了的时候有事情回忆，而不去后悔当初没有为那个冲动而尝试。和“他”相比，你已经很幸福，起码你还有深爱你的女友，和我们这些关心你的人，放下心结，重新上路吧。

而听完这一切，朋友，你还会选择创业吗？如果你的答案依然是肯定的，那么我很开心祝福在路上又多了你这样一个伙伴。只是当我们携手准备饮下这杯毒酒时，请你和我一样带着笑容。

作者 Randy Shoup译者 郭晓刚 发布于 2008年6月12日 下午7时5分

社区

Architecture

主题

设计,

性能和可伸缩性

标签

eBay

在eBay，可伸缩性是我们每天奋力抵抗的一大架构压力。我们所做的每一项架构及设计决策，身前身后都能看到它的踪影。当我们面对的是全世界数以亿计的用户，每天的页面浏览量超过10亿，系统中的数据量要用皮字节（10¹⁵或2⁵⁰）来计算——可伸缩性是生死交关的问题。

相关厂商内容

SOY Framework：Java富客户端快速开发框架

视频演讲：开放平台技术架构剖析

活动：体验基于OpenSolaris的Web/企业应用（8.30 杭州）

可伸缩性最佳实践：来自eBay的经验

免费迷你书下载：领域驱动设计精简版

相关赞助商

[[InfoQ中文站架构社区|http://www.infoq.com/cn/architecture/]，关注设计、技术趋势以及架构师所感兴趣的话题，通过新闻、文章、视频访谈和演讲以及迷你书等为中国架构社区提供一流资讯。

在一个可伸缩的架构中，资源的消耗应该随负载线性（或更佳）上升，负载可由用户流量、数据量等测量。如果说性能衡量的是每一工作单元所需的资源消 耗，可伸缩性则是衡量当工作单元的数量或尺寸增加时，资源消耗的变化情况。换句话说，可伸缩性是整个价格-性能曲线的形状，而不是曲线上某一点的取值。

可伸缩性有很多侧面——事务的方面、运营的方面、还有开发的方面。我们在改善一个Web系统的事务吞吐量的过程中学到了很多经验，本文总结了其中若 干关键的最佳实践。可能很多最佳实践你会觉得似曾相识，也可能有素未谋面的。这些都是开发和运营eBay网站的众人的集体经验结晶。

最佳实践 #1：按功能分割

相关的功能部分应该合在一起，不相关的功能部分应该分割开来——不管你把它叫做SOA、功能分解还是工程秘诀。而且，不相关的功能之间耦合程度越松散，就越能灵活地独立伸缩其中的一部分。

在编码层次，我们无时不刻都在运用这条原则。JAR文件、包、Bundle等等，都是用来隔离和抽象功能的机制。

在应用层次，eBay将不同的功能划分成几个应用程序池。销售功能由一组应用服务器运行，投标功能由另一组负责，搜索又是另外一组服务器。我们把总 共约16,000台应用服务器分成220个池。这样就可以根据某项功能的资源消耗，单独地伸缩其中一个池。我们也因此得以进一步隔离及合理化资源依赖关系 ——比如销售池只需要访问后台资源的一个相对较小的子集。

在数据库层次，我们也采取同样的做法。eBay没有无所不包的单一数据库，相反我们有一组数据库主机存放用户数据、一组存放商品数据、一组存放购买数据……总共1000个逻辑数据库分布在400台物理主机上。同样，这种做法让我们得以单独为某一类数据伸缩其数据库设施。

最佳实践 #2：水平切分

按功能分割对我们的帮助很大，但单凭它还不足以得到完全可伸缩的架构。即使将功能一一解耦，单项功能的资源需求随着时间增长，仍然有可能超出单一系 统的能力。我们常常提醒自己，“没有分割就没有伸缩”。在单项功能内部，我们需要能把工作负载分解成许多我们有能力驾驭的小单元，让每个单元都能维持良好 的性能价格比。这就是水平分割出场的时候了。

在应用层次，由于eBay将各种交互都设计成无状态的，所以水平分割是轻而易举之事。用标准的负载均衡服务器来路由进入的流量。所有应用服务器都是 均等的，而且任何服务器都不会维持事务性的状态，因此负载均衡可以任意选择应用服务器。如果需要更多处理能力，只需要简单地增加新的应用服务器。

数据库层次的问题比较有挑战性，原因是数据天生就是有状态的。我们会按照主要的访问路径对数据作水平分割（或称为“sharding”）。例如用户 数据目前被分割到20台主机上，每台主机存放1/20的用户。随着用户数量的增长，以及每个用户的数据量增长，我们会增加更多的主机，将用户分散到更多的 机器上去。商品数据、购买数据、帐户数据等等也都用同样的方式处理。用例不同，我们分割数据的方案也不同：有些是对主键简单取模（ID尾数为1的放到第一 台主机，尾数为二的放到下一台，以此类推），有些是按照ID的区间分割（1-1M、1-2M等等），有些用一个查找表，还有些是综合以上的策略。不过具体 的分割方案如何，总的思想是支持数据分割及重分割的基础设施在可伸缩性上远比不支持的优越。

最佳实践 #3：避免分布式事务

看到这里，你可能在疑惑按功能划分数据和水平划分数据的实践如何满足事务要求。毕竟，几乎任何有意义的操作都要更新一个以上的实体——立即就可以举 出用户和商品的例子。正统的广为人知的答案是：建立跨资源的分布式事务，用两段式提交来保证要么所有资源全都更新，要么全都不更新。很不幸，这种悲观方案 的成本很可观。伸缩、性能和响应延迟都受到协调成本的反面影响，随着依赖的资源数量和客户数量的上升，这些指标都会以几何级数恶化。可用性亦受到限制，因 为所有依赖的资源都必须就位。实用主义的答案是，对于不相关的系统，放宽对它们的跨系统事务的保证。

左右逢源是办不到的。保证跨多个系统或分区之间的即时的一致性，通常既无必要，也不现实。Inktomi的Eric Brewer十年前提出的CAP公理是这样说的：分布式系统的三项重要指标——一致性（Consistency）、可用性（Availability）和 分区耐受性（Partition-tolerance）——在任意时刻，只有两项能同时成立。对于高流量的网站来说，我们必须选择分区耐受性，因为它是实 现可伸缩的根本。对于24x7运行的网站，选择可用性也是理所当然的。于是只好放弃即时一致性（immediate consistency）。

在eBay，我们绝对不允许任何形式的客户端或者分布式事务——因此绝不需要两段式提交。在某些经过仔细定义的情形下，我们会将作用于同一个数据库 的若干语句捆绑成单个事务性的操作。而对于绝大部分操作，单条语句是自动提交的。虽然我们故意放宽正统的ACID属性，以致不能在所有地方保证即时一致 性，但现实的结果是大部分系统在绝大部分时间都是可用的。当然我们也采用了一些技术来帮助系统达到最终的一致性（eventual consistency）：周密调整数据库操作的次序、异步恢复事件，以及数据核对（reconciliation）或者集中决算（settlement batches）。具体选择哪种技术要根据特定用例对一致性的需求来决定。

对于架构师和系统的设计者来说，关键是要明白一致性并非“有”和“没有”的单选题。现实中大多数的用例都不要求即时一致性。正如我们经常根据成本和其他压力因素来权衡可用性的高低，一致性也同样可以量体裁衣，根据特定操作的需要而保证适当程度的一致性。 

最佳实践 #4：用异步策略解耦程序

提高可伸缩性的另一项关键措施是积极地采取异步策略。如果组件A同步调用组件B，那么A和B就是紧密耦合的，而紧耦合的系统其可伸缩性特征是各部分 必须共同进退——要伸缩A必须同时伸缩B。同步调用的组件在可用性方面也面临着同样的问题。我们回到最基本的逻辑：如果A推出B，那么非B推出非A。也就 是说，若B不可用，则A也不可用。如果反过来A和B的联系是异步的，不管是通过队列、多播消息、批处理还是什么其他手段，它们就可以分别地伸缩。而且，此 时A和B的可用性特征是相互独立的——即使B受困或者死掉，A仍然能够继续前进。

整个基础设施从上到下都应该贯彻这项原则。即使在单个组件内部也可通过SEDA（分阶段的事件驱动架构，Staged Event-Driven Architecture）等技术实现异步性，同时保持一个易于理解的编程模型。组件之间也遵守同样的原则——尽可能避免同步带来的耦合。在多数情况下， 两个组件在任何事件中都不会有直接的业务联系。在所有的层次，把过程分解为阶段（stages or phases），然后将它们异步地连接起来，这是伸缩的关键。

最佳实践 #5：将过程转变为异步的流

用异步的原则解耦程序，尽可能将过程变为异步的。对于要求快速响应的系统，这样做可以从根本上减少请求者所经历的响应延迟。对于网站或者交易系统， 牺牲数据或执行的延迟时间（完成全部工作的实践）来换取用户的延迟时间（用户得到响应的时间）是值得的。活动跟踪、单据开付、决算和报表等处理过程显然都 应该属于后台活动。主要用例过程中常常有很多步骤可以进一部分解成异步运行。任何可以晚点再做的事情都应该晚点再做。

还有一个同等重要的方面认识到的人不多：异步性可以从根本上降低基础设施的成本。同步地执行操作迫使你必须按照负载的峰值来配备基础设施——即使在 任务最重的那一天里任务最重的那一秒，设施也必须有能力立即完成处理。而将昂贵的处理过程转变为异步的流，基础设施就不需要按照峰值来配备，只需要满足平 均负载。而且也不需要立即处理所有的请求，异步队列可以将处理任务分摊到较长的时间里，因而起到削峰的作用。系统的负载变化越大，曲线越多尖峰，就越能从 异步处理中得益。

最佳实践 #6：虚拟化所有层次

虚拟化和抽象化无所不在，计算机科学里有一句老话：所有问题都可以通过增加一个间接层次来解决。操作系统是对硬件的抽象，而许多现代语言所用的虚拟 机又是对操作系统的抽象。对象-关系映射层抽象了数据库。负载均衡器和虚拟IP抽象了网络终端。当我们通过分割数据和程序来提高基础设施的可伸缩性，为各 种分割增加额外的虚拟层次就成为重中之重。

在eBay，我们虚拟化了数据库。应用与逻辑数据库交互，逻辑数据库再按照配置映射到某个特定的物理机器和数据库实例。应用也抽象于执行数据分割的 路由逻辑，路由逻辑会把特定的记录（如用户XYZ）分配到指定的分区。这两类抽象都是在我们自己开发的O/R层上实现的。这样虚拟化之后，我们的运营团队 可以按需要在物理主机群上重新分配逻辑主机——分离、合并、移动——而完全不需要接触应用程序代码。

搜索引擎同样是虚拟化的。为了得到搜索结果，一个聚合器组件会在多个分区上执行并行的查询，但这个高度分割的搜索网格在客户看来只是单一的逻辑索引。

以上种种措施并不只是为了程序员的方便，运营上的灵活性也是一大动机。硬件和软件系统都会故障，请求需要重新路由。组件、机器、分区都会不时增减、 移动。明智地运用虚拟化，可使高层的设施对以上变化难得糊涂，你也就有了腾挪的余地。虚拟化使基础设施的伸缩成为可能，因为它使伸缩变成可管理的。

最佳实践 #7：适当地使用缓存

最后要适当地使用缓存。这里给出的建议不一定普遍适用，因为缓存是否高效极大地依赖于用例的细节。说到底，要在存储约束、对可用性的需求、对陈旧数 据的容忍程度等条件下最大化缓存的命中率，这才是一个高效的缓存系统的最终目标。经验证明，要平衡众多因素是极其困难的，即使暂时达到目标，情况也极可能 随着时间而改变。

最适合缓存的是很少改变、以读为主的数据——比如元数据、配置信息和静态数据。在eBay，我们积极地缓存这种类型的数据，并且结合使用“推”和“ 拉”两种方法保持系统在一定程度上的更新同步。减少对相同数据的重复请求能达到非常显著的效果。频繁变更、读写兼有的数据很难有效地缓存。在eBay，我 们大多有意识地回避这样的难题。我们一直不对请求间短暂存在的会话数据作任何缓存。也不在应用层缓存共享的业务对象，比如商品和用户数据。我们有意地牺牲 缓存这些数据的潜在利益，换取可用性和正确性。在此必须指出，其他网站采取了不同的途径，作了不同的取舍，也同样取得了成功。

好东西也会过犹不及。为缓存分配的内存越多，能用来服务单个请求的内存就越少。应用层常常有内存不足的压力，因此这是非常现实的权衡。更重要的一 点，当你开始依赖于缓存，那么主要系统就只需要满足缓存未命中时的处理要求，自然而然你就会想到可以削减主要系统。但当你这样做之后，系统就完全离不开缓 存了。现在主要系统没办法直接应付全部流量，也就是说网站的可用性取决于缓存能否100%正常运行——潜在的危局。哪怕是例行的操作，比如重新配置缓存资 源、把缓存移动到别的机器、冷启动缓存服务器，都有可能引发严重的问题。

做得好，缓存系统能让可伸缩性的曲线向下弯曲，也就是比线性增长还要好——后续请求从缓存中取数据比从主存储取数据成本低廉。反过来，缓存做得不好 会引入相当多额外的经常耗费，也会妨碍到可用性。我还没见过哪个系统没机会让缓存大展拳脚的，关键是要根据具体情况找到适当缓存策略。

总结

可伸缩性有时候被叫做“非功能性需求”，言下之意是它与功能无关，也就比较不重要。这么说简直错到了极点。我的观点是，可伸缩性是功能的先决条件——优先级为0的需求，比一切需求的优先级都高。

希望以上最佳实践能对你有用，希望能帮助你从新的角度审视你的系统，无论其规模如何。

软件开发的过程

作者 Kurt Christensen译者 郑柯 发布于 2008年8月20日 上午9时38分

社区

Agile

主题

敏捷实施,

变更

在“射箭高手的秘密诅咒”一文中，纽约时报专栏作家Katie Thomas描述了一种奇怪的痛苦情绪，它广为人知，人们称之为“目标恐慌”。当世界顶尖的射箭高手向目标发出一箭时，这种情绪会导致他们失去控制能力，如此现象让人费解。人们通常认为这是一种心理问题，新的研究表明：“目标恐慌”实际上是神经失调的表现。

为了理解这些以前无法解释的痛苦，神经病学家开始探究大脑深处存在的处理方式。比如最近《纽约客》发表了一篇文章，其中Atul Gawandem博士描述了对于“四肢疼痛幻觉”的全新治疗方法。“四肢疼痛幻觉”是指，接受截肢手术的人会感受剧烈疼痛，不过这些疼痛出现在已被截去的手臂或腿部之上。医生将接受截肢的人放在多面镜子之前，这会让患者产生四肢健全的幻觉。接下来医生会让患者完成多种任务，比如指挥不存在的交响乐团。来自Walter Reed医院的全新研究显示，这种“镜箱治疗法”可以有效去除“四肢疼痛幻觉”症状。令人惊讶的是，为大脑提供一系列全新的、出其意表的感官输入，这会让大脑改变内部的处理流程。

当然，在人工智能领域之内，使用数据改变处理这些数据的算法，这并无特别之处。此种“学习算法”的应用非常广泛，涵盖了从语音识别到信用卡欺诈检测等很多领域。实际上，随着处理海量数据能力的增强，似乎学习算法接受的数据要比算法本身还重要。在2008创业学校上的演讲中，Peter Norvig比较了五种可以自我调整的算法在表现上的差异，这些算法是用来处理自然语言的。结果表明：选择更好的算法所带来的表现提升，远不如让它们处理更多数据带来的提升更明显。

可是这种方式能够用来跟软件开发的过程做类比么？在《人类赖以生存的隐喻》一书中，George Lakoff和Mark Johnson讲述了隐喻塑造我们理解世界的方式，以及隐喻揭示与混淆我们身边世界的方式。对于大脑、软件，以及软件开发，唯一的隐喻就是：机器——也就是硬件。可是在这两个例子中，如果能将处理过程看做软件——也就是可编程的，也许能取得更好的进展；虽然易于出错，但是也易于修复。如果软件是软件开发的隐喻，那么软件开发的流程创建和提炼的方式，应该与软件创建和提炼的方式相同；小窥一下，处理软件开发流程，只需构建需要的部分，而且总是通过迭代和测试驱动的方式。

大家都已经习惯于事先明确定义最佳流程，要想抛弃这种观念，也许有点让人胆战心惊，可是现实告诉我们：要想为一组特定的人制订软件开发的流程，不应事先进行流程的明确定义，而应将精力放在流程的演进上；这也是与人类大脑和软件本身最一致的方式。

　　一天，佛朗西斯科决定把他的发现付诸实践。他先走进一家墨西哥小酒吧，要了一杯价格为

　　10个墨西哥分的啤酒。喝完之后，他用1个墨西哥比索付帐而要求找补美元。接着，他怀装找回的1美元（在墨西哥只值90个墨西哥分）越过边境又进了一家美国酒吧。这次，他仍旧要了一杯价格为10美分的啤酒喝起来，然后，他用刚才在墨西哥小酒吧找回的1美元付帐，根据他的要求又找回了1个墨西哥比索（在美国只值90美分）。

　　现在，佛朗西斯科发现，当他喝完两杯啤酒之后，钱袋里的钱却1分也没有少，仍然有一个比索。于是，他继续不断地重复这一方法，整天在墨西哥和美国之间愉快地喝啤酒。

　　问题是：谁在真正支付佛朗西斯科的啤酒帐？

一天，一只兔子在山洞前写文章，一只狼走了过来，问：“兔子啊，你在干什么？”答曰：“写文章。”问：“什么题目？”答曰：“《浅谈兔子是怎样吃掉狼的》。”狼哈哈大笑，表示不信，于是兔子把狼领进山洞。

　　过了一会，兔子独自走出山洞，继续写文章。一只野猪走了过来，问：“兔子你在写什么？”答：“文章。”问：“题目是什么？”答：“《浅谈兔子是如何把野猪吃掉的》。”野猪不信，于是同样的事情发生。

      最后，在山洞里，一只狮子在一堆白骨之间，满意的剔着牙读着兔子交给它的文章，题目：“《一只动物，能力大小关键要看你的老板是谁》。” 　　

　　这只兔子有次不小心告诉了他的一个兔子朋友，这消息逐渐在森林中传播；狮子知道后非常生气，他告诉兔子：“如果这个星期没有食物进洞，我就吃你。”于是兔子继续在洞口写文章.

        一只小鹿走过来，“兔子，你在干什么啊？”“写文章”“什么题目”““《浅谈兔子是怎样吃掉狼的》”“哈哈，这个事情全森林都知道啊，你别胡弄我了，我是不会进洞的”“我马上要退休了，狮子说要找个人顶替我，难道你不想这篇文章的兔子变成小鹿么”

　　小鹿想了想，终于忍不住诱惑，跟随兔子走进洞里。过了一会，兔子独自走出山洞，继续写文章，一只小马走过来，同样是事情发生了。最后，在山洞里，一只狮子在一堆白骨之间，满意的剔着牙读着兔子交给它的文章题目是：《如何发展下线动物为老板提供食物 》

随着时间的推移，狮子越长越大，兔子的食物已远远不能填饱肚子。一日，他告诉兔子：“我的食物量要加倍，例如：原来4天一只小鹿，现在要2天一只，如果一周之内改变不了局面我就吃你。

　　于是，兔子离开洞口，跑进森林深处，他见到一只狼“你相信兔子能轻松吃掉狼吗”狼哈哈大笑，表示不信，于是兔子把狼领进山洞。过了一会，兔子独自走出山洞，继续进入森林深处这回他碰到一只野猪----“你相信兔子能轻松吃掉野猪吗”野猪不信，于是同样的事情发生了。

　　原来森林深处的动物并不知道兔子和狮子的故事最后，在山洞里，一只狮子在一堆白骨之间，满意的剔着牙读着兔子交给它的文章题目是：《如何实现由坐商到行商的转型为老板提供更多的食物》

　　时间飞快，转眼之间，兔子在森林里的名气越来越大，因为大家都知道它有一个很历害的老板，这只小兔开始横行霸道，欺上欺下，没有动物敢惹它．时时想起和乌龟赛跑的羞辱，它找到乌龟说：“三天之内，见我老板！”扬长而去．

　　乌龟难过的哭了这时却碰到了一位猎人．乌龟把这事告诉了他，猎人哈哈大笑．于是森林里发生了一件重大事情－－猎人披着狮子皮和乌龟一起在吃兔子火锅，地下丢了半张纸片歪歪扭扭的写着：山外青山楼外楼，强中还有强中手啊！！

　　在很长一段时间里森林里恢复了往日的宁静，兔子吃狼的故事似乎快要被大家忘记了，不过一只年轻的老虎在听说了这个故事后，被激发了灵感于是他抓住了一只羚羊，对羚羊说，如果你可以象以前的兔子那样为我带来食物那我就不吃你。

　　于是，羚羊无奈的答应了老虎，而老虎也悠然自得的进了山洞。可是三天过去了，也没有见羚羊领一只动物进洞。他实在憋不住了，想出来看看情况。羚羊早已不在了，他异常愤怒。正在他暴跳如雷的时候突然发现了羚羊写的一篇文章题目是：《想要做好老板先要懂得怎样留住员工》

在软件开发中资源使用

老李(libaojian@infoer.com.cn)

在一个软件系统的开发中，每个团队成员都面临着资源不足的问题，如何权衡资源，让资源动态的适应情景，推进工作的进展，当显示出资源分配和控制者的能力。当拳头都合力打出，体现了资源的最大效用。

从一个项目酝酿的时候，到后期维护，一般不可能有很多的资源交给你支配。从多年的经验，分析出资源包括了4大类资源

Ø         时间资源（进度 周期 时间）

Ø         人力资源（角色 一个萝卜一个坑 或者一个萝卜多个坑）

Ø         能力资源（个人）

Ø         支持资源（特定问题的支持）

只有将这些资源 合理的搭配和使用 才会使的问题解决起来更加的容易一些，才会使一切在掌控之中。否则将会出现失控的局面。

下面将围绕这4个资源来展开问题的分析。

时间资源：

在国内软件系统开发的大环境下，基本没有让人满意的资源支持，一般的系统，在不规范的的环境下开发都面临时间不足的情况。作为项目责任人，只能是努力的去调配，使工作顺利开展，尽大可能推进进度。

我总结处理的方式步骤如下。

1，仔细分析系统的架构说明书（高层用例）和技术研究成果，尽可能的争取合理的时间资源。

2，当不能争取到合理的时间资源的时候，分析并缩减工作量，根据客户和市场的具体情况，进行合理的功能实现和产品的包装。

3，当2的解决方法不能争取到的时候，就要在资源分配上想办法了。一般的方式就是利用现成的工具，设计成果，快速开发工具等方法。总之，能节优时间的方式都采用。

从多年的经验 我总结出下面的方法，不一定合适，具体情况具体分析罗

 a, 充实人力（有相关经验的人） 缩短开发时间 同时提高能力资源

 b, 寻求各种方式进行培养 提高团队战斗力 同时提高能力资源

 c, 寻求已经有的好的设计 代码 拿来直接用 ；开发代码生成工具 节约时间 ；修改设计文档格式，达到crc目的即可，并且可以作为正式文档的元素和储备。

     在时间资源方面，总结就是省。寻求各种方式，省时间，依赖于其他资源进行时间的节约。

人力资源：

以人为本是好多公司人性化的借口，当公司压榨团队成员的时候，如何将这个最难玩的资源掌控好学问很大。虽说用制度来衡量和管理是最科学的，但是人这种高级动物，想法太多。曾经总结了若干调动团队积极性的条条。只是人力资源管理的一个方面。

   我总结的原则是

1， 岗位不能缺失，不管是通过招聘，培养的方式，每个坑必须都有萝卜，可能会有一个萝卜多个坑的情况

2， 寻找各种方式，使每个萝卜达到最大的饱和战斗力。

3， 寻求各种方式，增强团队战斗力和凝聚力

能力资源：

1， 挖取个人潜在能力并快速培养

2， 增强个人自信心

支持资源：

1， 知识库 搜集各种知识资源，包括行业知识，分析设计知识，代码片断

2， 内部培训交流 挖取每个成员的优势 知识分享

3， 寻找外培机会 免费和付费的

4， 书本材料

5， 办公用品

6， 员工的家事和健康

 资源的分类

    可重用资源（模式，代码，方法） 不可重用资源（时间）

可重用资源的累计

当我们拥有第一桶金的时候，我们就开始了资源的累计。所有的成员都是资源的累计者和创造者，当给每个成员进行创造资源的任务的同时，将足够的支持资源尽力的给他，并且以合适的方式和合适的内容。创造的资源经过整理成为我们资源库的资源。

系统负责人就是控制资源，整理资源，分配资源，累计资源。使雪球越来越大。进而形成自己的模式，自己的风格，自己的资源库。一切形成习惯的时候，就向良性的发展走去。

办法总比问题多。

不可重用资源的节约

   提高效率 增强战斗力

 一碗牛肉面的思考 转帖
            推荐人：kitty 2007-1-30 10:11:40

               
            　　我跟朋友在路边一个不起眼的小店里吃面，由于客人不多，我们就顺便和小老板聊了会儿。谈及如今的生意，老板感慨颇多，他曾经辉煌过，于兰州拉面最红的时候在闹市口开了家拉面馆，日进斗金啊！后来却不做了。朋友心存疑虑地问他为什么。

              
               　　“现在的人贼呢！”老板说，“我当时雇了个会做拉面的师傅，但在工资上总也谈不拢”。
              
              
            　　“开始的时候为了调动他的积极性我们是按销售量分成的，一碗面给他5毛的提成，经过一段时间，他发现客人越多他的收入也越多，这样一来他就在每碗里放超量的牛肉来吸引回头客”，“一碗面才四块，本来就靠个薄利多销，他每碗多放几片牛肉我还赚哪门子啊！”

              
              
            　　“后来看看这样不行，钱全被他赚去了！就换了种分配方式，给他每月发固定工资，工资给高点也无所谓，这样他不至于多加牛肉了吧？因为客多客少和他的收入没关系。”

              
              
            　　“但你猜怎么着？”老板有点激动了，“他在每碗里都少放许多牛肉，把客人都赶走了！”“这是为什么？”现在开始轮到我们激动了。“牛肉的分量少，顾客就不满意，回头客就少，生意肯定就清淡，他（大师傅）才不管你赚不赚钱呢，他拿固定的工钱巴不得你天天没客人才清闲呢！”

              
               　　啊！结果一个很好的项目因为管理不善而黯然退出市场，尽管被管理者只有一个。
              
               　　当我们把这个案例告诉给其他的朋友并讨论的时候，他们先是拍案叫绝，继而沉思，时而悲愤，时而慷慨陈辞。
              
               
              
               　　下面是一个博士，一个研究生，和一个MBA对这个问题的激辩，请大家先谈自己的想法，这可是第一手的实战啊！
              
              
            　　1.首先我们考虑将小老板所用两种方案进行折中，即：底薪加提成的方法，提成根据每碗的利润分配。这样既可以防止他少放牛肉，又能防止他疯狂地多放牛肉。

              
              
            　　2.后来又想到这一条是有条件的。问题是每碗的利润界定后怎么个分配法？一碗面能挣多少是瞒不过大师傅的，如果不能让双方的利益在某个点达到平衡，一切又会回复原样。而要达到所说的那种平衡涉及到一个复杂的相关函数问题，说不定还要用到博弈论。

              
               　　3.把面馆承包给大师傅，老板拿了提成后回家养花弄鸟去。当然，提出这个方案后大家都有过短暂的脸红，再否定！
              
              
            　　4.然后我们谈到了企业文化、正义、道德、人性，并一致认为：管理学博大精深，成为一个优秀的管理者非得经过百般磨练方能修得正果，再先进的管理理论也有不适用的时候。

              
               
              
               　　是啊，就这个小小牛肉面的故事，却反映出了一个小企业管理中的种种问题。
               
              
            　　首先就是一个关于大师傅激励的问题。可以设计一个激励机制，就是在定额约束下的销量或利润累积奖励。首先根据每碗面的顾客可接受效用制订一个材料定额，大师傅的工资还是按照销售量提成，但是前题是月度的材料消耗不得偏离定额太多，例如允许波动幅度为20%，否则只有基本工资。或者说每碗面规定需要添加的牛肉克数，一批牛肉的总量是固定的,拉面的卖出量是可以计算的，多少碗面放多少斤牛肉限定住了，哪个加牛肉的要敢给我多加或者少加,工资就对不起了。还是底薪加提成工资，老板自己心里得算清楚一碗面的成本是多少？利润是多少？如果牛肉放多了，客户多了，以牛肉最大量为定量,以面条量为变量,控制一下放面条的多少使自己还有利润可赚，这个就得有一个取值的过程了!虽然现在都讲公司效益与员工利益进行挂钩，股权分配是个好法子，但对于一个小店，搞什么股权激励，有点不切实际了。

              
              
            　　其次，我想饭店也是制造，必须有工作程序、定额消耗以及制度规范，可以没有书面东西，但老板必须心中有数才行。对这个小老板的拉面店来说，其实就是师傅以技术入股的方式和老板利润分配，大家都双赢。两个人合伙做，费用两个人摊，进行规划化管理。在工作程序上：比如制订sop，包括面条的量，水的量，肉的量等bom明确规定，制造方法、工艺也请大师傅标准化；在定额消耗上，也与上述的激励密切相联；薪水报酬上：参考社会上的平均工资和本店的盈利水平，结合师傅的劳动量、劳动结果（营业额的增加降低、顾客的反馈等）进行综合评定。

              
              
            　　此外，将复杂的事情简单化：老板娘放牛肉不就得了？关键的资源一定要掌握在关键的人手里！关键资源才是最重要的。老板掌握了店面的所有权，才可能有大师傅为他打工；老板娘掌握了牛肉的分发权，才有可能防止材料的浪费和滥用。不过，老板还应该再掌握大师傅这一核心的人力资源，怎么掌握还是一个难题……唉，人力资源……而且，作为小规模店铺，老板要熟悉每一个环节，才能做好管理。如果牛肉拉面老板很熟悉牛肉面的制作，师傅也不敢乱来。有效的经营监督就是这样。

              
              
            　　另外，任何工作除了要有监督、控制，其余的事情都可以通过沟通来解决。我们认为本例中没有一种好的办法能一劳永逸地解决分配问题，在这种作坊式的小企业里，老板与员工每天有大量时间接触，关系是否和谐非常重要。惟有靠小老板良好的个人魅力并善待下属，才会让大师傅内心产生归属感及满足感，积极工作努力为老板创造利润，到那时候牛肉的多少就不成麻烦了。
              
               　 通过以上的分析，我认为管理应该是这样的：
              
               1.底薪加提成，提高积极性；
              
               2.不能把全线流程的权利都下放给大师傅，比如加牛肉；
              
                3.建立有效的制度，包括奖赏和惩罚，制度根据顾客的满意程度和利润来　建立；
              
               4.大师傅的工资提成不能只和销量挂钩，应该和老板的利润挂钩，比如一碗面中老板利润的30%是大师傅的利润；
              
               5.有效的沟通、激励，平时给大师傅精神的奖励，让大师傅认为自己也是面馆的主人。
             

　　1.他在背诗和有韵律的词句时很出色；

　　2.他能注意到你愁闷和高兴的情绪变化；

　　3.他常常问诸如“时间从什么时候开始”的问题：

　　4.他很少迷路；

　　5.他的动作很优美；

　　6.他唱歌时音阶很准；

　　7.他经常会问打雷、闪电和下雨是怎样形成的等问题；

　　8.经常说过的一个词你用错了，他就会纠正；

　　9.他很早就会系鞋带，出人意料地早会骑车；

　　10.他特别喜欢扮演什么角色并编出剧情；

　　11.出外旅行时，他能记住沿途标记，说：“我们曾到过这个地方……”

　　12.他喜欢听各种乐器，并能通过辨音认出它们；

　　13.他地图画得很好，对物体描绘清晰；

　　14.他善于模仿各种身体动作以及面部表情；

　　15.就像喜欢根据大小和颜色把玩具分类一样，他善于划分种类；

　　16.他长于把动作与情感联系起来，譬如他说：“我发昏了才做出这事……”

　　17.他能够相当精彩地讲故事；

　　18.他能够对不同的声响发表议论；

　　19.某人被引荐，他有时会说：“她使我想起了谁。”

　　20.对别人能完成与不能完成的事他能做出准确的评论。

　　这其中，1、8、17表现出的是语言才能；6、12、18表现出的是音乐才能；3、7、15是逻辑数学上的才能；4、11、13是空间上的才能；5、9、14是身体动觉才能；10、16、20是自我认识才能；2、10、19是他人认识才能。

　　倘若你对上面的某项才能有关的三个问题上都答“是”，那么，你的孩子就可能具有那一才能。

　　苏茜能把钢琴弹得如梦一般，保尔能把破收音机整旧如新……但一纸书面的智商测查值并没有反映出他们的能力，反倒往往使这样的孩子遭了殃。实际上，孩子具有许多专家门测查不出来的能力，波士顿大学医学院神经学教授霍毕德·加德纳作了创造性的研究，认为孩子有六种基本能力，他们在受到鼓励以后，至少会在其中一个方面得到发展。读一读他关于这六种能力的描述，可以帮助我们找出并培养孩子的潜在特长。

　　语言方面他很早就是个兴致勃勃的交谈者，他能用自己加工过的词名，很擅长学会一些新词汇或长句子，喜欢写诗或讲故事。很早就学着独立读书。

　　怎样使他得以发展呢？每天晚上上床时读书给他听。适当给他提供足够的书籍。要求他背诗，大人也背一些。玩文字游戏……对他写的或背的每项东西都应有所反应。

　　音乐方面他可能会倾听取暖散热器、汽车喇叭、打字机按键……所发出的音响。很小时他就喜欢摸琴键，并站住谛听。即使没有歌词，或是换了乐器，他也能知道是熟悉的曲子。他学新歌快而准。

　　促进他音乐才能的方法是，给他唱歌，租一部钢琴，买一支长笛，请一位适合的辅导老师，进入一个有音乐附加课程的学校，等等。

　　逻辑数学方面他擅长下跳棋和象棋，喜欢抽象思考，能很快地搞通一些等量关系。（2天＝48小时）。

　　给他一个透亮的塑料玩具盒，他会分门别类地装些小玩具。时常伴着他玩玩棋、牌，那怕他屡屡得胜。如果能就近为他寻找几个有数学才能的伙伴，那他们就可以组成个“数学俱乐部”了。

　　空间方面他有丰富的想象力。比如基娣，她4岁时就想用立体画法画奶油箱子，今年15岁的她艺术上成绩不凡，正筹划做一名摄影家。

　　应该给这样的孩子从小提供画画的场所，还应用粘土、塑料造型等。带着他到陌生的地方去远足，并请他把走过的地方画下来。让他学学肖像的绘制和其他绘画课程。

　　身体动觉方面有很大成绩的运动员和舞蹈家都有这方面的天赋。这种天赋是两种基本技巧构成的：使自己动作优美和熟练驾驶东西。许多工程师也有这一才能。如果你的孩子对翻跟头、游泳、骑车一学就会，在穿针、使用多种工具、拆装钟表和收音机等方面都挺顺手，那他就有这方面的天赋了。

　　把孩子推荐到舞蹈或体操、体育的小俱乐部去，尽力而为地为他提供些装修机械或电子玩艺。学校的体育运动或木工活对他很适合，在运用肌肉、神经、技巧的天地里，他会十分超众的，这些天地含有工艺和文体表演。

　　对己对人的认识方面一般我们长留心孩子认识自己的缺点，但那些懂得如何计划和使用自己才能的孩子，我们往往是在他们长大后才发现的。认识别人的能力不难发现，他常会注意到别人的变化，看侦探书或惊险影剧，并能很快指出坏蛋。

　　如果孩子能认识自己，那对其见解一定要加以赞扬。如果他能认识别人，那对他参加“侦察小组”的游戏是挺有益的。对于这两方面的才能兼有的孩子，参加表演短剧是很好的形式，表演之后可同他一道讨论人物的个性，并让他对每一个家人做大致的描述。

透视迭代开发2007-04-23 来自：java060515


引子：我们为什么需要迭代开发？

　　我们都知道，人对于世界的认识是一项主观活动，它受到各种因素的影响，使得我们不能够一下子对所要认知的事物有一个清晰的了解。具体到软件开发中来，我们会发现，你很难在开发之前弄清楚客户所有的需求。一方面，客户对自己想要什么可能并没有一个明确的想法，这就好比在买衣服的时候，我们在专卖店里看到一个衣服，会觉得自己穿起来很帅，但是你仍然需要把它真实的穿在身上才能看到实际效果，而在你看到这件衣服之前，你能够仅仅凭着想象在脑海里刻画出这件衣服的样子么？

　　其次，软件工业中我们讲究的是投入和产出比，软件业的成本主要是人力资源的成本。这也是软件项目对时间特别敏感的原因。时间比计划延长一个月，对于一个数十人的团队来说就意味着几十万的成本增加。但是又有谁能够保证自己所做的软件是完美无缺的呢？于是很多时候我们必须对已经开发的部分进行修正，而修正就需要时间。 传统的开发方式下，很多软件项目都是在匆忙交付后发现用户不满意，于是继续修正，再次引发用户的不满意，再次修正，在这样反复地拖延中，客户和软件开发商都筋疲力尽。

　　我们需要迭代开发，是因为我们深知对事物的认知就是一个探索的过程，软件开发也是一样。在温博格《探索需求---设计前的质量》一书中提到：

　　美国第34任总统艾森豪威尔上将曾经说过，"计划本身什么都不是，而编制计划的过程就是一切"。我们认同这样的说法，并把它推广到需求过程：产品什么都不是，而开发的过程就是一切。

　　或用另一种方式表达：发现什么都不是，而发现过程（探索过程）就是一切。

　　软件项目本身的意义就在于和用户一起探索他们真正需要的东西并且帮助他们实现。而这种探索，如同在第一段中我们阐述的那样，需要不断的反复，如果我们没有做好迭代和反复的准备，而是希望一次性的把所有工作都做完并且还做得非常好，结果可能恰恰相反。

　　我们需要迭代开发，是因为我们追求软件质量的最大化。没有人可以制造出完美无缺的东西，但是我们可以通过不断的检查和反馈，使得那些不适合的东西在早期被暴露出来，迭代给予了我们这样一种检查合反馈的机制，让我们不必在事情结束的时候才惊奇的发现我们所一直努力在做的东西其实是一堆废物。

　　实践：正确实施迭代开发

　　事实上在业界，迭代开发的观念早已经深入人心，然而有多少团队在正确地实施着迭代方法呢？有多少团队通过迭代得到了他们想要的东西呢？很多人简单的把迭代理解为开发的分阶段进行。我们常常看到有项目经理们这样说：我们打算通过4次迭代完成软件的开发，第一次迭代，完成需求分析和软件设计，第二次迭代，完成多少多少模块的开发，第三次，完成其他多少模块的开发，第四次，配置，部署，上线，测试，修正软件bug。虽然我们言必称“迭代”，但是这样的迭代和过去传统的瀑布型开发有多少区别？我们又能够从这样的伪迭代中得到什么好处呢？

　　在本文以下部分将对迭代开发实践中几个关键方面进行阐述，这几个方面我们概括为以下关键词：变化，周期，目标，反馈，合作。

　　变化
　　迭代思想带给我们最重要的一个启示，就是要适应变化，要积极、主动地拥抱变化而不是拒绝变化。

　　在过去的开发中，我们常常会拒绝变化，以需求分析工作为例，有些项目组在需求分析完成后会要求用户签字，等到交付时，如果客户有什么意见，他们就会拿出那份客户已经签字画押的文件来理直气壮地说：这是你们签字过的东西，我们做的难道不是和这里所说的一样么？

　　是的，开发出来的可能是和需求定义文件的内容一样的，但问题是：这份需求定义文件上描述的内容是不是真正能够帮客户实现自己的价值呢？难道我们进行软件开发的目的就是让客户在一份他们根本不清楚有什么意义的文件上签字，然后用这个来反驳用户的真正需求么？我们在软件立项之前总是会告诉用户，这个即将开发的软件会帮助他们如何如何。我们有什么理由为我们做不到这一点而理直气壮地责备客户呢？客户亲笔签名的需求文档难道不是我们整理出来并且讲解给他们听的么？

　　如果一个软件项目的目标是帮助客户实现某一方面的增值，但是这种增值的目的并没有达到，我们就可以认为这个软件项目是失败的。即使软件厂商通过这个项目达到了盈利的目的，满腹牢骚的客户也会把自己的意见传播出去。而如果软件厂商认为这种事情是天经地义的话，那么它在以后的软件项目中也很难帮助自己的客户实现他们想要的价值。

　　我们必须让自己具有适应变化的能力。因为这种变化是客户需要的，因为这种变化能够让软件更能体现出自己的价值。我并不是说应该无条件地接受这种变化，但是我们可以在事前就这些问题和客户进行充分的讨论和沟通，让他们明白，世界总是变化的，需求本身可能会变化，而这种变化需要人力和物力的支持。让客户也能够适应自身的变化，这是非常重要的。

　　将剩余的工作列入下一次迭代计划中去，
　　将本次迭代的结束时间向后延迟，等待任务的完成
　　前一种办法适合于有很大工作量没有完成的情况，这可能也同时说明计划的制定有问题，在制定下次迭代计划时应该考虑对任务完成时间进行调整。后一种办法适合剩余工作量不是很大的情况。

　　通常来说，一次迭代完成以后应该有一个产品的新版本可用。这也就意味着：将集成和发布分散到每次迭代中去。借助于一些自动化工具（比如ant），我们甚至可以做到每日构建。

　　一个迭代周期应该有多长呢？这并没有一个统一的说法，而是应该视目标和可用的资源而定。但是，迭代周期不宜过长，也不宜过短。迭代周期过长的话，会延缓反馈的时间，可能将许多问题隐藏或是堆积了起来。迭代周期过短，会让人身心疲劳，事情难有大的成效。一般来说，迭代周期应该在2-6周之间。如果安排的迭代周期超过了两个月，你可能就必须审视一下迭代计划的合理性了。

　　不要认为下一次迭代应该和上次迭代的时间差不多，刻板地把所有迭代规定一个统一的时间是一个很坏的做法。但是你可以把以前迭代周期中的工作效率作为估算下次迭代时间的一个依据。

　　目标
　　一次迭代必须有明确的目标：我们希望通过这次迭代达到什么目的。在制定目标时，应该同时考虑另外一个问题：如何检查该目标是否已经达成。这就是所谓的“里程碑”。

　　迭代计划必须有明确而可行的目标。明确的意思是它应该是可度量的，不能太模糊，因为你很难检查一个模糊的目标是否达成。比如，我们可以说，这次迭代的目标是对xxx方面的需求作进一步细化和评审，完成xxx模块的开发以加入到软件的下一版本中去。这样的目标是明确而且可行的。反过来，如果我们这样说：我们要通过和用户的讨论明确绝大部分愿景，同时要有一个初步的开发。“绝大部分”和“初步”这样的词让人感到困惑：多少是绝大部分呢，在总量尚未明确的前提下，怎么能够知道完成的确是“绝大部分”而不是“一小部分”？“初步的开发”似乎告诉我们这次开发量比较小，但是具体开发哪个部分，或者开发到什么程度，并没有指出一个明确的概念。

　　由此产生了一个困惑，软件项目是一个不断探索的过程，我们怎么能够明确地对未来的事情作安排呢？譬如在项目初始调查用户愿景时，为了实现“明确”的目标，是否这样定义任务：完成20%的用户愿景调查？

　　很显然，用户愿景总量到底有多少我们并不知道，所以在这次迭代完成以后如果我们问：是否真的完成了20%而不是15%？很难得到答案。

　　为了避免出现这种情况，你必须换个角度来看问题，比如我们可以说：对xxx部门和yyy部门的用户做愿景调查。在迭代完成后，可以检查是否这两个部门所有用户的访谈，调查都已经完成，是否这些部门每个人都认为自己表达了全部的意思。

　　所以，如果你发现很难对制定的目标进行度量，那么换一个角度来看事情吧，你可能就会找到一个合适的表达方式。如果你从所有的角度都看不到事情是可以度量的，那么这可能意味着这件事情可能还没有到应该去实施的地步，这时你应该把它从迭代计划中去掉。对于这种情况，有人可能会说：那我们这次迭代可做的事情就很少了，如果真是这样，那就进行一次小的迭代吧，可能把这次迭代的工作做完了以后就会有更多的工作可以安排了。

　　有些项目经理在日程表上，很详细地写着：第一次迭代，某月某日到某月某日，第二次迭代：某月某日到某月某日，第三次迭代。。。这样的做法是不恰当的。因为它假设了后面几次迭代的任务量，但是实际上，在前面的工作完成之前，你很难对以后的工作得到一个明确地概念。而且在这样的计划上，可能并没有用于测量迭代成果的里程碑，这样的迭代最后很可能会演变成为瀑布式的开发。所以，在一次迭代完成之前，不要对急着去计划下次迭代，特别是不要试图精确定义下次迭代的时间，因为你连下次迭代要做什么都还不清楚。

　　为什么目标的可度量性这么重要呢？在团队开发中，很多信息因为人与人的交流不畅而无法得到正确地反馈，这让我们没有办法实时地掌握项目的进展情况，退而求其次，我们必须阶段性地了解这些信息。如果目标难以度量，迭代结束后我们很难明确到底有哪些工作没有完成，也就无法看到事情的问题所在。

　有些团队中会要求每个成员每天对自己的工作进度以百分比的形式做汇报，他们以为通过这样的方式可以确实的掌握事情的进展，但实际上并不行，因为软件开发中存在很多不确定因素，有时候我们认为事情已经完成了一大半，但是可能因为技术或者其他的原因发现这一大半工作方向是错的，这时候就要推倒重来，而且人们在汇报工作量的时候总是会有一些感情的因素在里面，这就使那些看似精确的百分比打了个折扣。

　　所以，我们需要更加实际和细致地划分工作，对目标的完成情况进行度量。这也是迭代周期不能太长的一个原因：如果你把大量有前后关联的工作划分入一个迭代周期，在设定的结束到来时，突然发现只完成了一小部分，这时候虽然亡羊补牢仍然可以，但是中间浪费了大量的人力和物力。

　　反馈
　　一个男人在大街上走着，他并没有发现裤子上的拉链已经松开了，虽然看到这个情况的人有很多，但他们有各种各样的担心，比如不想多管闲事，怕让那个男人难堪，或者干脆就是想看笑话。结果就是这个人继续穿着一条敞开拉链的裤子在大街上行走。

　　这件事情至少带给我们两个启示：1，得到反馈是重要的；2，要想得到正确的，有价值的反馈，你需要其他人的配合。

　　对于用户需求来说，没有用户及时地反馈，我们就可能把那些不符合需求的开发继续下去，由于软件中各种功能和模块的依赖性，这种不符合最后可能被放大到数倍。越迟得到反馈，问题可能就越大。

　　软件开发中一个很重要的概念是“可行性”和“合理性”，无论我们做需求，设计还是开发，集成，测试，都会遇到这两个问题。有些事情的可行性和合理性是我们可以通过事前的分析进行判断的，但是有些问题就必须有一定的实践作为基础。这也是一个反馈的问题。譬如说在某项目中技术架构师决定采取一个技术架构，但是经过一些阶段的开发发现它有一些技术上问题不能实现用户的关键需求，这时候就必须放弃它。

　　“反馈”意味着两个意思，对一件事情的调查和根据调查做出决策。

　　在意识到反馈的重要性之后，你会要求所有的人都对迭代的成果做出反馈。可能存在的问题是，是不是所有的人都意识到了反馈的重要性并且认真地去做了呢？如果客户认为他们只需要对迭代出来的产品“看看而已”，那么你就很难了解他们一些深层次的想法。再比如一次迭代中某些模块开发的进度比较慢，开发人员可能会抱怨技术方案不能满足要求，而实际的原因可能是设计不合理或者根本就是有人没有认真工作。

　　中国国家队前主教练米卢曾经说过“态度决定一切”，反馈作为迭代开发中至关重要的一个方面，必须得到足够的重视。

　　获得反馈的方式和对于反馈信息的分析是另外一个重要的方面。一般来讲，根据软件开发角色的不同，我们非常关注的是两类人的反馈：项目组之外的客户和项目组之内的各种实施人员。

　　软件项目一般都会要求客户方安排专门的业务人员进行配合，在迭代开发中，这种配合不只是进行需求的整理和发掘，还包括对已经完成软件版本的评测。在这个过程中应该有需求分析师的配合。

　　在每次迭代完成之后，软件项目组应该有一些总结和分析活动。通过这些总结和分析，找到做得好和做得不好的方面。

　　在非迭代式的开发中，也有反馈的环节。比如通常在软件交付阶段会有一个试用期让用户提出意见。而软件团队在各种开发中都会有一些总结活动。迭代式开发的独特之处在于尽量早地引入反馈机制；使得反馈机制更加制度化；并且，更加快速和灵活地分析这些反馈，把得到的结论应用到下一阶段的开发中去。

　　对于一些机制引起的问题，比如组织结构不合理，角色分配不明确之类。最好有一个明确的问题记录表。在每次迭代完成以后将这些问题记录下来，同时在下次迭代中努力改善它。如果相同的问题连续出现在几次迭代中，可能就说明项目管理出了问题。

　　合作
　　软件团队中的合作是人们一直都在提倡的。我们在这里提到“合作”的意思并不只包含团队内部的协作，还包括和客户的合作。

迭代开发需要快速反应，这需要各种不通角色人员的配合。如果人们做事情总是拖拖拉拉，就会延缓软件项目的进度。而且每个人对自己在迭代中应该做什么事情必须很清楚，这需要事前的准备和角色的合理分配。

　　迭代需要用户的配合，实际上最好能够有客户方真正的系统使用者参加到迭代过程中来，因为他们是最有发言权的。很多项目中会让项目经理或是系统分析师担当客户代表的角色，这样做有很多弊病。有时出于各种原因客户确实不能到现场配合的，我们也可以通过其他的途径获得客户反馈。比如一个阶段迭代完成以后，可以把相关操作用截屏加文字说明的方式发给客户，让他们对产品有一个直观的印象。

　　为了让团队能够有效快速地配合，应该尽可能使用各种自动化工具。比如自动化测试管理工具，以及配置管理，集成以及发布之类的工具。通过对这些工具的有效应用，使得各个成员能够快速获得信息。

　　迭代开发要拥抱变化，主动适应变化。要让每个参与者都认识到这一点：不能够固步自封，或者满足于现有的成就，不去思考可改进的地方。从管理者的角度上，必须重视每一个反馈信息。

　　迭代开发追求对任务的度量。很多组织会把这种度量和员工的绩效考评联系起来。这种做法可能是合适的，但是如果只是简单衡量工作量或者工作完成速度和质量，有可能会比较片面。毕竟软件开发是一个环环相扣的过程，表面上来看这个环节处理不好，实际上可能是准备工作做得不好，或者其他人的配合不好。

　　所以如果在迭代过程中出现了问题，一定要客观地分析，特别是应该挖掘导致这些问题出现的深层次原因。譬如在一次迭代中测试人员发现了一些bug，但是两次迭代过去了，这些bug仍然存在，这就说明对bug的处理不够迅速（当然如果因为某些原因这些事情被故意推迟了的情况不算）。这时就必须分析一下到底是什么原因造成了信息的不通畅。而不能简单地批评相关责任人。

　　总结
　　本文对迭代开发的五个关键（变化，周期，目标，反馈，合作）方面进行了讨论。作为一种方法论，迭代开发的好处在于它使软件团队变得更加灵活。在实施迭代开发的过程中，应注意不能流于形式化，切实做好每个环节的工作，这样才能获得满意的结果。

软件开发公司技术管理办法的一个设想
2007-04-23 来自：java060515  [收藏到我的网摘]

1.目的

　　为了规范公司软件技术的研发、使用及升级维护流程，加强公司对公共软件技术的管理，对公司公用软件技术生命周期进行有效的控制，提高公司软件产品的开发效率和质量。

　　2.范围

　　1． 公司级公共软件技术的研发和升级维护过程。

　　2． 公司级公共软件技术应用过程。

　　3． 公共软件技术包括：Delphi、.Net、Java、嵌入式开发4条技术线的软件应用框架、外购控件包、公共基类、通用技术解决方案、通用工具软件。

　　3. 职责

　　技术委员会：

　　1） 发布公共软件技术的某个版本。

　　2） 甄选和招募技术委员会成员。

　　3） 收集技术提议，做出技术规划。

　　4） 组织软件技术人员进行公司公共软件技术的研发。

　　公共软件技术研发项目组：

　　1） 负责公共软件技术的技术论证、开发。

　　2） 对应用人员进行培训。

　　3） 跟踪技术的发展，解决技术应用中的问题。

　　应用系统软件项目组：

　　负责实施和应用公共软件技术，对应用情况进行反馈。

　　4. 控制流程

　　1． 技术规划

　　1） 技术委员会平时负责收集整理公司范围内的软件技术的自主研发、技术升级扩展或技术外购的提议。

　　2） 每年定期（经理会期间），技术委员会组织人员对收集整理的提议进行评估筛选，确定下阶段软件技术研发的重点，并制定研发任务。

　　3） 对于急需技术的提议，技术委员会随时组织人员进行评估筛选，安排研发任务。

　　2． 技术论证

　　1） 确立研发任务后，技术委员会甄选合适人员作为某项技术的技术研究员，对确定的研发任务进行技术论证和试验。

　　2） 技术研究员收集和验证某项技术的技术资料，撰写技术可行性研究报告，明确技术自主研发或采购要求，人力和时间投入估算，预期收益等内容。

　　3） 技术委员会组织人员对技术可行性研究报告进行评审，确定技术研发的策略，策略包括取消、继续论证、暂时挂起、进行开发。

　　4） 对继续论证的技术重复1）-3），直到次技术的研发策略变化。

　　5） 如果是由于目前公司资源不足或是目前形势尚不足以做出判断，可以让技术研发进入暂时挂起状态，等待重新提议和评审。

　　3． 技术开发

　　1） 对于技术可研报告评审评定为进行开发的技术，技术委员会组织人员进行下一步开发工作。

　2） 技术委员会甄选人员组成公共软件技术研发项目组，确定研发项目任务目标和工期要求，确定项目组负责人。技术研发项目组可以并入应用系统项目组进行管理。

　　3） 研发项目的负责人指定详细的开发计划，并按计划进行开发工作，开发工作包括设计、编码、测试和撰写开发文档。

　　4） 开发完成后，项目负责人组织相关人员对开发成果进行评审，一般情况下，技术总监、技术委员会主席以及技术应用的相关人员要参与评审。

　　5） 评审不通过时，需要根据评审意见进行修改，然后重新评审。

　　4． 技术应用

　　1） 评审通过后，研发项目组负责撰写培训材料，对应用此项技术的开发人员进行技术应用培训。

　　2） 如果需要，研发项目组成员进入应用系统项目组进行有关开发工作。

　　3） 项目组指定一个此项技术的负责人，项目组解散。

　　5． 技术维护

　　1） 技术负责人跟踪此项技术发展，收集此技术的应用反馈意见，处理Bug。

　　2） 技术应用的项目组把技术的改进要求和建议统一提交到技术负责人，技术负责人根据收集的反馈和对此项技术的跟踪情况，不定期向技术委员会提交技术升级提议。

　　3） 技术委员会进行合并提议进行下一轮技术规划。

转自：http://blog.sina.com.cn/luansir

   为了盘点2006中国品牌年度盛事，推动“品牌中国”计划的全面实施，由品牌中国产业联盟、新浪网、《中国企业家》、《财经时报》、《第一财经日报》、分众传媒、航美传媒等机构联合发起举办的“第三届品牌中国高峰论坛暨2006品牌中国年度人物颁奖典礼”于2007年2月3日至4日在 北京隆重举行，“品牌中国总评榜(2006-2007)”正式启。新浪财经独家图文直播。以下为：首钢发展研究院企业所所长王育琨在“主题演讲：品牌价值与文化传承”上演讲。

　　谢谢主持人，谢谢大家！

    今天的品牌中国盛会是一次誓师大会，是一次浩大的进军。中国需要品牌中国这样的品牌文化普及大会。

    一个懂得尊重品牌的民族，才会诞生伟大的品牌。一个拥有伟大品牌的国家，才能拥有不断前行的力量。

    但是，我们在这样说的时候，一定要非常警醒。因为过多的民族情感可能使我们永远与世界级品牌绝缘。在今天品牌中国的论坛上，提出了一些很煽情的口号。尤其是向文波总经理，反复强调“民族品牌”、“保护民族品牌”，我就有点紧张。

    为什么紧张呢？因为所有世界级品牌传达的不是民族自豪感。我们国家的很多品牌注入了过多的国家使命，注入了过多的民情感，而你看看世界级的品牌，它是不是宣传这个东西在里面，我们发现没有。而我们的品牌建设，往往自觉注入国家使命和民族情感。在全球一体化的市场中，没有人为你的民族自豪感埋单。美国人、西班牙人、摩洛哥人不会为你的民族情感埋单。人们只为自己的生活品质和生活方式埋单。沃尔玛抓住了“最便宜的折扣店”这一条，十年如一日塑造了今天的商业帝国。我们只要抓住了改变人类生活方式和生活品质这一条，就抓住了世界级品牌的关键。

    今天听到了不少品牌概念。我理解的世界级品牌本质的内涵就是：“改变人类的生活品质，改变人类的生活方式”。 世界级品牌传达的是一种改变人类生活方式的力量与自信。树立世界级品牌的理想，就是要树立改变人类生活方式和生活品质的理想。但是一说到这里，可能有人说说了，你要站在月球上看中国，我倒认为不是这样的。世界级的品牌并不是说你非要站的多高，而是像分众传媒的江南春一样，从人的生活习惯里面创办品牌。像沃尔玛那样，从邻里关系中提炼出“最便宜的折扣店”这个最强大的武器。

   论坛交给我的主题是中国为什么缺乏世界级的品牌。这是个人人都可以发表意见的题目。简单地说，

1、  中国市场太大了，一锤子买卖就能赚个没完，没有必要创立品牌；

2、  中国消费者太有爱心了，父爱主义泛滥，让中国企业长不大

3、  中国的环境太宽厚了，中国商业环境太宽厚了，做坏事、恶事的收到的惩罚很小，还有一大堆保护你的体制和人物。严师出高徒，没有严师，没有惩罚，人类懒惰的本性就削弱了品牌。

4、  企业家太弱了，弱者思维统摄了中国企业家。

我不太习惯宏大的主题。我喜欢跟3、2知己的寒窗夜话。我理解的建立世界级品牌，不简单是誓师大会，不能只是铿锵战鼓响彻云霄，也不能仅仅是磅礴气势震撼登场。应该有小桥流水和秉烛夜话。上个星期与深圳市一个负责同志的秉烛夜话，正好切入今天的主题。

上星期有位深圳的负责同志跟我探讨一个问题。他说你是研究企业和企业家的，你来分析一下怎么两个知名企业对同一件事有完全不同的态度和做法？他说1995年深圳梅观高速建成通车，华为和富士康在高速路的两侧，当时有个协议，高速路给这两个公司开两个出口，有这两个公司把开出口的钱在建成通车后拨给梅观高速公司。华为很痛快，按时拨付。而富士康现在还没有给。这是不是跟任正非和郭台铭的个性有关？这个问题太好了，把这个问题拿到今天的论坛上，提出了中国为什么缺乏世界级品牌的第一个要素：

创建世界级品牌的要素：企业家文化。

这位朋友说了两家公司的一个行为。从企业家文化的角度来解读有这样三个层次：

这个行为的背后，这个现实反映了贴牌生产与自主品牌的两重天的一个冷现实。富士康属于世界500强，而华为不是；富士康营业收入超过1000亿元人民币，而所纳税额为1000、2000万元；华为去年营业收入为528亿元，而所纳税额为40、50亿元；富士康收入大于华为2倍，而纳税仅为华为的400-500分之一。华为的纳税额接近营业收入的10%，而富士康却是营业收入的万分之一；税率1000倍的差异，税额400、500倍的差异。富士康的利润率可能只有1%，而华为的利润率为营业收入的50%左右。华为的最低工资，是富士康平均工资的10倍。华为人能够享受公司增长的红利。

在两重天的现实背后，是不同的观念。跨入宽门的郭台铭：起步容易，发展快，不用投入很多，开张就能赚钱进来，订单有了，劳工原料后续给，打败竞争对手，赚钱就是抠出来的；跨入窄门的任正非：起步难，创自己的品牌，走上了一条艰苦卓绝的创业之路，也走上了一条广结战略同盟的间接路线战略之路。靠20多年的积累，跻身世界建设巨子。

观念的背后是企业思维：郭台铭：苍狼文化，吃光了草地就换地方，围歼黄羊不惜牺牲草地，让黄羊吃得走不动、麻痹然后出击。一个地方吃完，就到另一个地方；任正非：以技术为本的价值创新。不是现在才搞，而是在2万元收入时，在一家挤在简易房中吃死鱼和拣烂菜时就拿出一半来稿研发！

思维后面是精神：郭台铭：做大了，我就是救世主，不论我是怎么起家的；任正非：警醒事物昙花一现的本质，警惕两次不能踏入同一条河流，华为还没有一项原创技术，保持一种刻骨铭心的自觉。品牌后面的精神，任正非达到了一个令人肃然起敬的高。这也是建立世界级品牌的第一个要素：企业家文化！

企业家文化的另一个重要体现：跟上公司这个生物的进化，掌握前端的理念和技术。

记得维克多·雨果曾经说，“你可以抵抗敌人军队的入侵，但你没有办法抗拒顺应时代需求而产生的观念。”当然，这个观念要向有力量，必须凝了很高的精神质素，同时还必须向波士登那样已经物化为“登峰造极”的现实，才会有雨果硕的力量。

今天联想集团的李岚来宣讲联想品牌的新进境，“一起奥运，一起联想。”我对联想全球化品牌的塑造，还是有一些忧虑的。

联想并购IBMPC以后，主要有三个里程碑的事件，一是改组经营团队，二是决定提前两年停止使用IBM品牌树立联想品牌；三是决定在全球复制联想中国的双业务模式。所谓双模式就是对大客户的关系型模式与对小客户的交易型模式。

在联想的2006年年终总结中和杨元庆的一系列答记者问和演讲中，都把双业务模式尤其是交易型业务模式说成是联想的核心竞争力。对此我有点担心。当然担心的不只是我，还有联想的高管。如，首席财务官马雪征，看上去就忧心忡忡。她直言不讳：“美国的形势最令人担心。供应链问题使联想很被动：我们创造了需求，但却未准备好去满足这种需求。” 马雪征抓住了关键问题：冷落消费者，会使消费者很快离你而去。主管供应链的刘军也是特别难熬：戴尔的制造基地周围是一大堆核心供应商，戴尔因此可以做到零库存，而联想却要全球分散去采购，加大成本还降不下库存。断货市场发生，因此让联想的主管们纷纷抢元件囤积，这就更增加了供应链的危机。

PC市场走过了产品性能、产品加服务、整体解决方案这样三个阶段，现在到达了敏捷供应链阶段。PC同所有制造业一样，已经不是产品、服务与价格的竞争，而是敏捷供应链之间的竞争。敏捷供应链就是一个虚拟大企业，由一个盟主和众多联盟员一起满足特定市场和客户的需要。现在不再是单体企业的一体化供应链决定乾坤，而必须是把上下游资源纳入一系列相关的联盟体系之中。戴尔的敏捷供应链，支持了戴尔的敏捷制造、敏捷物流、敏捷设计等等，是戴尔模式的重点所在。单体企业的一体化供应链已经不够，上下游资源纳入一系列相关的联盟体的敏捷供应链正取得势头。而且，敏捷供应链不是一个简单的观念变化，而是要从观念之上要到思维、精神，观念之下还要到现实运营。现实运营不是一天两天就能成就的，还必须有个积累。戴尔的敏捷供应链是戴尔20多年的积累。联想凭空而起，难上加难。

不从这样的高度，而仅仅区分两种业务模式，怕是联想乏力的根本所在。

联想面临的选择很现实：是寻进化的契机还是固守曾经的荣耀？

创建世界级品牌第二个重大转化：从私企到共器。

这个演化，联想没有抓住，许多中国公司都没有抓住。柳传志并不理解全球化的公司，其股东、客户、流程、供应链已经具备了公器性质。在2006年底中国企业家论坛上，学者王志乐说现代跨国公司是种社会公器，我们中国企业家还没有意识到这个转变。跟王志乐在同一个论坛上当嘉宾的柳传志则在一边评论说，“关于企业是公企还是私企的问题，现在企业我没有认为是公企。是否可以这样理解，中国国有企业是中国的公企？民企还是私企。私企还是要强调利润是第一位的”。把“公企”与“公器”混淆，说明虽然联想已经是国际资本主导下的联想了，但是当家人的观念还没有转过来。柳传志不会把联想作为公器来对待。那是他的命根子。

我们熟悉的三星案例。一般的认识，都是在亚洲金融危机的深重时刻，李健熙认识到自主创新的重要性，认识到OEM没有前途，于是洗心革面奋发搞研发。其实，李健熙更深一层的反思是，他看到他那100名董事会成员，100名高管，这100个生死弟兄，帮助他创造不了世界级的品牌，他必须改造董事会，在全球范围内引进独立董事，才可以保证三星走上正路。

品牌的内涵是宽越国界和民族的。品牌的建设也是跨越国界和民族的。跟不上这个形势，还是一切从现有企业的派系争斗和平衡出发，调配全球资源来建设世界级品牌，中国就不可能拥有世界级品牌。

对今天演讲的简单总结：创建世界级品牌，不仅仅要靠誓师大会，不仅仅要发起浩大的进军，更要有于无声处听惊雷的震撼，还要有一大批从事地下开掘工作的企业家。企业家本质上就是工作在地下的人，一个挖掘开采和探索地下世界的人，他谨慎、不动声色、不可思议、不为人知和不可动摇地向前推进，几乎看不到什么苦恼的迹象。而当他一旦走上地面，要么就是已经成功，要么就是个在四招摇的骗子。

因此，我要向誓师大会的发起人、参与者致敬，更要向在地下工作的企业家致敬！

主持人：

　　让我们再次用掌声向王育琨先生致敬！其实王育琨先生就像他自己用到的词语叫震撼登场。

　　刚才我跟波司登的高德康在一起交流的，高德康先生对王育琨先生的价是：敏锐、独到。

有时无知是福。俺看到一点新鲜的科普也能觉得造化神奇。刚才读Gerald Jay Sussman（SICP作者）的文章，Building Robust Systems – an essay，竟然心如小鹿乱撞，手心湿润，仿佛第一次握住初恋情人温柔的手。

这篇文章主旨明了：构造复杂的健壮系统非常困难。我们的软件能够有效完成某件具体任务，却不能适应业务领域的变化。一点细微的需求或部署的改动都能让我们的系统变得脆弱。反观生物进化的历史，无数生物在频繁变更的严酷大自然里繁衍生息。也许我们能从中学到让系统随环境变更而自动演化的秘密。当然，不是所有的软件都身段僵硬。35年前问世的Emacs至今是最高效的编辑器之一（不怕惹众怒地说一句，流行的EditPlus和UltraEdit除了学习曲线，还是不能和Emacs比），实属居家旅行杀人越货之必备利器。20年前问世的TeX ，1989年就停止更新代码，但这并不能阻挡它横扫科技出版业，变成科技出版物排版的事实标准，基本上干掉了科技出版业里的排版员这项本来很有前途的工作。不过，这些都是特例。我们需要了解的是构造复杂系统的通用方法。不然skynet和matrix怎么能够问世嗫？

Sussman在文章里讨论了生物在残酷进化里得来的五坨特性。这些特性对谙熟生物的老大们也许不是新鲜事，却能让我这个靠三思科普生物的半文盲肾上腺素急剧释放：

•  冗余(redundancy)和简并(degenerate，不知道这个翻译对不对)
  强健的生物系统都有大量冗余。比如肾和肝。割掉一个肾，我们仍然能活蹦乱跳。把肝的三分之一供奉给乙肝病毒，我们被歧视乙肝携带者的公司气死的几率也大多得肝癌挂掉的几率。
  
  生物系统也高度简并：同一功能可以由不同的部分来完成。比如我们的能量既能从糖获得，也能从脂肪获得，还能从蛋白质里获得（这个造成我们为节食和消耗热量绞尽脑汁，实属进化跟不上变化的特例，另当别论）。而这三者的代谢过程都不一样。甚至我们的遗传代码也是简并的。我们有20来种氨基酸，但核苷酸构成的密码子组合却有64种。这样才能让点突变不至于影响某个密码区的蛋白质，使得突变能积累起来，同时不会导致明显的表现型后果。不然领导某天生出一特聪明的小孩儿(变异了)，但就是长得像头羊，我们非得抓狂不可。简并成于进化，也成就进化。环境改变了，大不了某个部分废掉，但生命继续（系统依然满足规格）。而废掉的功能为变异（或修补）腾出空间。整个系统没有被惊扰。
  
  现在的软件系统往往包含冗余，但很少刻意加入简并。作者顺便对Python拍砖：Python的口号是TIOWWTDI（There is only one way to do it），明显是零简并系统。
  
• 探索行为
  探索行为也是生物系统健壮的基石。生物需要的合适功能通过“生成-测试”的机制获得。系统某部分生成功能，而另外相对独立的部分测试功能，决定接受还是拒绝测试结果。比如说支持细胞上的微管阵列决定细胞的形状。微管们总是不断被生成和摧毁。那些有幸碰到细胞膜里稳定子的微管们得以存活。最终结果就是细胞的形状又稳定子的位置决定。所以细胞形状的生成和维护机制同确定细胞最终形状的机制分开(操作系统设计里policy和mechanism分开有点类似)。
  
  探索过程中测试者不必知道行为提供者。行为提供者也不必知道测试机制。这样的结果是变异和适应非常灵活，因为测试者和行为提供者可以自由发展。反正合者生，不合者死。负面作用就是这种选择代价高昂。自然选择的每一秒都伴随着无数生命的消亡。
  
• 隔离和定位
  我们身体的每一坨细胞都源于单一的受精卵。所有细胞的遗传信息（才1GM内存！）都一样。但是，我们有各种专门细胞，比如皮肤细胞，神经细胞，肌肉细胞等。这些细胞再进一步组织成组织，器官，和器官系统。这一切之所以可能，是因为细胞们能根据环境特异化。也就是说，细胞的行为并没有被编入细胞间的信号传递，而是由基因组决定。不同的信号组合可以激活或关闭细胞的某项功能。不同的细胞组合起来，进一步实现更为复杂的功能。
  
  优秀的软件系统有类似的特点。它们高度模块化。不同的模块在不同的环境里执行对应的功能，进行不同的组合。
  
  
• 防御，修补，和再生
  生物大都能防御异物的攻击，修补缺损的部分，再生死亡的肌体。现在的软件开始包括防御功能，比如安全特性。不过，很少有强大的修补和再生功能，虽然号称自己能自我调控的系统不少。前两年IBM闹腾得欢的autonomous computing最近好像也让位给牛皮轰轰的SOA。Erlang的容错系统倒非常诱人：它的基础设施让系统比较轻松地侦测出问题的进程，然后在不影响系统运行的前提下重启该进程。
  
  
• 组合
  复杂系统都是又小模块组合而成。这点我们并不陌生。我们构建的系统模块依赖事先写好的规范。比如接口的规范，比如接口调用的顺序。这种规范现行的办法随着系统复杂程度的增高变得越来越难。相反，人类的基因组信息不过区区1G，还不够容纳一个普通操作系统的规范，却足以决定我们的构造和行为。我们的“系统接口”必须能够自我配置，适应环境。代价是系统的初始化时间太长，9月怀胎不过是刚开始。
  
  

文章也讨论了具备这些通用特性的健壮系统需要哪些基础功能：

• 通用的部件
  健壮的系统总是由一系列通用部件构成。每类部件都有广泛的应用范围。每个部件能接受范围宽广的输入，但能输出范围狭窄的结果。这好比久经考验的电子原件。他们能在充斥了噪音信号的环境里正确工作，输出可以预测的信号。
  
• 可以扩展的泛型操作符。比如同样是加号，+, 既可以处理整数相加，也能处理实数相加，也能处理矩阵相见。更重要的是，还能让用户扩展该操作符的语义，引入新的功能。这样不仅能让新程序容易编写，而且能旧的程序自然增加功能，应对新的环境。这点其实很多语言都有所支持，尤其是现下流行的动态语言。比如说在Lisp环境下开发，我们可以开发一个简单的版本，让程序运行起来。然后我们就在这个运行的程序里不断调试，修改，和加入新的功能，直到这个系统健全。这里有演示录像。
  
• 生成和测试
  我们的系统应该让我们能够写出返回多项选择的函数，然后同步测试这些结果，挑选出合适的结果。如果结果不好，系统自动回溯。这样做的危险是回溯可能导致指数级的运行时间。不过这也是进化不可避免的代价。其实生成-测试的理念早已用到编程当中。比如Prolog的自动回溯。和众多动态语言支持的模式匹配--比如Erlang, 比如Scala，比如Ocaml。
  
• 通过约束得到的普适过程
  这个大概是说通过一系列的约束条件，我们可以构建出对应的约束网络。通过这个网络，我们能生成适应这些约束条件的过程或函数。这样生成的函数能满足广泛的应用环境。
  
• 工程中的简并
  作者提出了两种方法。一是利用AI中常用的技巧：目标导向（goal-directed）的方法。这个本质上是说我们不规定系统怎么做一件事，而是告诉系统要达到什么目标。Prolog简直是解决这类问题的天生杀手。当然，现代的函数编程语言也是解决这类问题的利器。二是对同一问题实现多种独立解法，然后让系统挑选合适的方法。
  

文章还讨论了支持系统健壮和进化的方法：

• 组合子
  简单说，我们应该通过搭配组合相对独立的部件来构建系统。函数语言对这种编程方式尤其擅长。特别是支持transparent referential integrity和lazy evaluation的函数语言，比如Haskell：我们搭建出基本的模块。Haskell系统提供一大堆强大的黏合工具，让我们把这些模块轻松地组装起来。不过文章也强调，关键还是模块的质量。函数编程只是有效的手段。
  
• Continuation
  这个特性在Ruby， Python，Scheme, Smalltak等现代动态语言里都有。Continuation是非常强大的编程手段。一个Continuation对象被创建时能保留当时系统的有关状态，并在其他任意时间被调用。这让程序员获得对时间的直接控制。我们可以暂停某段计算，并在一段时间后继续那段暂停的计算。牛人Avi就利用Smalltak对Continuation的完善支持写出了绝对让人惊叹的Seaside Web编程框架。不信邪的老大们可以去体验以下用Seaside搭建的应用，dabbledb。
  
• 回溯和并发
  没有回溯，我们就不能自动检验多项选择，排除不合适的结果。没有并发，我们不能同时检验多个结果，计算的代价太高。这些好像不新鲜。
  
• 任意联系
  标注元数据便是一个例子。我们不能也不可能预测系统运行时数据间的所有关联。所以构建可以任意扩展的数据关联系统就非常重要了。这好像也不新鲜。比如说至少20年前人们就认识到Metaobject Protocol的重要性，有兴趣的老大可以去读这本经典的书。现在Java支持的Annotation也可以算一个例子。
  
• 动态配置的接口
  这个比较新鲜，属于正在研究的难题。现在的方法是让一个群体内的计算实体（agent）通过不断地交流信息来建立大家理解的规则。俺没有看明白。

总之，这篇文章属于高来高去的主题演讲性质的文章，但它对生物系统以及生物系统与计算系统的联系的描述着实让我大开眼界。也许文章结尾是最好的总结：正经的工程不过几千年历史。我们构造健壮系统的手段还远未成熟。我们还没有从漫漫几十亿年生物进化中吸取经验….

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出版、作者信息和本声明。否则将追究法律责任。本文地址：http://blog.csdn.net/jobchanceleo/archive/2007/04/13/1563866.aspx

不可否认，作为打工者，我们都从某种程度上被老板认为是种工具，类似扳手之类的、可以被随时换掉又俯拾皆是的工具。初入职场的我们听到这种理论可能很不以为然—老子学习这么多年，步入社会被人当成工具，简直笑话，公司是把我当人才看的。

很多让我们不舒服的东西，反倒可能是正确的。在职场打拼时间久了，我们会发现：自己确实被当作工具这个事实。人才也不过是把高级扳子而已，职业经理人就是镶金、合金扳子。

被当成工具也无所谓，君视臣为草芥,臣视君为寇仇，你把我当扳子，我把你当一堆X，公平又合理。要不是最近身边哥们儿、姐们儿发生了一些状况，我的认识可能也止步于此。

 太多事发生之后，我重新总结和整理了自己的理论。公司是把我们当工具不错，但不是低层次的劳动必用工具，而是理财（生财）工具，最贴切的比喻就是：公司把我们看成股票。

 定义
潜力股—初入职场的我们，虽然实际价值不大，但意气风发、有无限的可能性；
蓝筹股—基本上是入行五年之后的我们，有能力、有阅历、有经验，总之是实力雄厚；
垃圾股—没有成长潜力、因种种现实打击失去了进心。

买家（公司）的态度
适当购进潜力股—既然是潜力股，那么就只代表一种可能，是有风险的，公司培养很久可能成不了蓝筹或者成了蓝筹被别人抢了；

大力购进蓝筹股—大不了高开高走，能给公司实现赢利就行。这种方案的风险在于有股票是伪蓝筹，最后不得不割肉（裁员）跑掉；

小心购买垃圾股—有时,垃圾股不过是时运不济、没找到自己适合的位置才沦落至此的。如果公司能独具慧眼看出其中潜蓝筹，加以投资，回报相当可关。别小看这种股票，市场里有专门炒这个发财的。

我们的态度

潜力股对策—让自己增值、增值、再增值，尽早走入蓝筹行列。不要永远是潜力股，不然很容易成为垃圾股；

蓝筹股对策—全方位提高自己、保持职业水准、延长职业黄金期；

垃圾股—受打击之后，是个人都可能会有消沉。不同的是失败都永远消沉了，被停牌永远退出市场；成功者从失败中站起来吸取教训、看清骗子、提高自己，再次让自己成为蓝筹。

行走职场，每个人都有可能成为三种股票中的一种，甚至可能如我几次变为垃圾股。没关系，当成为垃圾股时只要始终记得我们是潜力蓝筹、不断提升自己的价值、笑对下一个买家，成为真正的蓝筹是早晚的事。

 到时候我们要对公司说：“要对我这支蓝筹好些啊！我和股票不同的是一般股票你不卖，这支股票不会减少或者消失，我可是会自己跑路的啊！哈哈！”

　　 在服务器端Java（ServerSide Java）研讨会3月22日的一次会议上，SUN公司的高级工程师Ed Burns说：开发人员可以使用JSF开发出企业级的AJAX应用程序，这些应用经过了充分的行业证明，具有良好的健壮性，可靠性，易用性和伸缩性。

　　 Ed Burn还表示：“可以通过不同的方式来使用JSF和AJAX。 其中一种方式是同时使用JSF和Project Dynamic Faces 或DynaFaces。 通过这种方式，使用者不需要JavaScript的知识，如果使用者喜欢使用JavaScript还可以构建功能更加强大的应用程序。另一种方法是使用AJAX支持的JSF组件，这种方法只需要有对AJAX很少的知识就可以。另外开发人员还可以只使用AJAX或使用一种AJAX框架。” 　　B 　　 urns说：“除了Project Dynamic Faces，还有其他的方式来同时使用JSF和AJAX，其中包括使用ICEsoft公司的 ICEfaces, Ajax2JSF, AjaxAnywhere 和Backbase。”Google公司的Adam Bosworth可以告诉你为什么AJAX在经历失败后又会成功。（点击此连接到相应页面）。

　　 Burns还说：“早在AJAX还不是如此强大之前，JSF的面向对象设计已经为JSF可以在AJAX中使用做了准备。JSF的如下主要特性使得它对于AJAX来说是友好的，其中包括灵活的可扩展组件模型，明确的请求处理生命周期（Request Processing Lifecycle）和一个灵活的可扩展渲染模型。

　　 Burns 说,AJAX的成功在于其具有的如下理念：JavaScript对页面的开发人员来说透明，但却可以被组件开发者看到；通过状态管理使客户端和服务器端轻松保持同步等。使用JSF和AJAX还可以解决跨浏览器的问题。同时，Project Dynamic Faces将AJAX强大的功能引入到已有的和未来的利用JSF开发的应用。

    在2007年于纽约召开的AJAX World大会上，位于康涅狄格州斯坦福德的Virtua公司首席咨询师Kito Mann做了一个名为“看啊，不用JavaScript也可以（Look Ma, No JavaScript）”的讲演，表达了和Burns一样的观点。Mann讲演的主旨是：“使用JSF，可以在不编写任何JavaScript代码的情况下构建应用程序。” Mann说，JSF是针对于JAVA的一种标准的web用户界面框架，其规范包括服务器端用户界面组件，事件模型，一组基本的用户界面组件和基本的应用结构。Mann还是JSFCentral.com的创建者之一。JSFCentral.com是一个由使用JSF技术的开发人员，架构师和经理组成的社区。另外，他还是Java 社区Process' JSF专家组的成员之一。

     曼恩说，JSF还提供广泛的工具支持和用RAD(快速应用开发)模式的方法去开发Java Web。此外, JSF是建立在Servlet API之上的，并且促进了第三方用户界面组件市场的发展,他说。

    总体来说,“JSF提供透明的AJAX支持，”曼恩说。"我们的想法就是JSF编程模型能与AJAX一起工作。"
有多种支持JSF的IDES(集成开发环境),包括Sun的Java Studio Creator，BEA 的Workshop Studio，Oracle的 JDeveloper 和 Exadel Studio Pro (现在在JBoss umbrella旗下)，曼恩说。
而且，JSF架构加上AJAX支持很容易，他说。

    事实上，曼恩说JSF有三个主要的AJAX集成策略。

    一是把AJAX支持加到现有组件中，二是把AJAX支持直接集成到JSF组件中，三是对现有AJAX控件封装成一个JSF组件，曼恩说。

    用在第一种方法中的技术包括Exadel的Ajax4JSF，Ideo技术的开源AjaxAnywhere offering和Sun的DynaFaces,，曼恩说。

支持AJAX直接集成到JSF组件的产品或技术包括Simplica的ECruiser，Infragistics的NetAdvantage，Sun的Project Woodstock，和来自ICEsoft, Backbase and Exadel的技术，曼恩说。

    封装现有的AJAX控件到JSF中，两个主要的选择是Sun’s jMaki和Dojo Foundation’s Dojo Faces，他说。

　　“这两个菩萨，哪一个重要？”苏东坡问他。

　　“当然是拳头大的人重要。”佛印说。他们走入内殿，看到观音菩萨手持念珠。

　　“观音也是菩萨，她数念珠干什么？”苏东坡问道。

　　“喔，”佛印说，“她也学别人拜佛呀。”

　　“拜哪一个菩萨呢？”苏东坡说。

　　“咦，拜观音菩萨呀。”

　　“这是怎么回事？她是观音菩萨，为什么要拜自己呢？”

　　“咦，”佛印说“你知道求人不如求已嘛。”

儿子，老爸一直在外面出差，原谅老爸。

你拍一，我拍一，小松松要坐飞机
你拍二，我拍二，你是妈妈的乖宝宝
你拍三，我拍三，奶奶喂你吃饼干
你拍四，我拍四，爷爷教你写大字
你拍五，我拍五，小松松跳个妞妞舞
你拍六，我拍六，爸爸给你剥石榴
你拍七，我拍七，你和妈妈做游戏
你拍八，我拍八，八头小牛吹喇叭
你拍九，我拍九，你和壮壮交朋友
你拍十，我拍十，松松是个好孩子

　　“哥是天上一条龙，妹是地上花一丛。龙不翻身不下雨，雨不洒花花不红。”

　　这首流传于大江南北的民歌，巧借比喻，将自然现象与情爱愉悦“水乳交融”，有声有色地唱出了男女之“大礼”，又不伤大雅，这是很优美的歌谣!

　　特别是陕北民歌，爆烈烈的令人咋舌，火辣辣的惹人心跳。

　　“只要和妹妹搭对对，铡刀剁头也不后悔!”听听，爱得有多真；“眼睛仁仁想你哩，看见人家当成你!”看看，恋得有多深；“阳世上跟你交朋友，阴曹地府咱俩配夫妻；一碗凉水一张纸，谁坏良心谁先死!”一腔痴心何等忠烈。这就是生生不息的歌谣、彻头彻尾的爱情。崖畔上一位不识字的妹子盼着走西口的哥哥，心怀爱情，口吐莲花：“夜夜听见马蹄子响，扫炕铺毡换衣裳。听见哥哥唱着来，热身子扑在冰窗台。听见哥哥脚步响，一舌头舔烂两块窗……”

　　滚烫的语言，不加任何修饰，这就是爱的华章!

　　正如王国维先生在《人间词话》中所言：“粗服不掩国色。”歌谣中的爱情天长地久，足以让满腹经纶的爱情诗人汗颜不已。在歌谣面前，纯美艳亮的名诗都将变得苍白。

　　“骑上毛驴狗咬腿，半夜里来了你这个勾命鬼。搂住亲人亲上个嘴，肚子里的疙瘩化成了水……”

　　尽管当代诗人使出浑身解数，极尽缠绵悱恻之能事，终归不及民歌来得轻巧、大方：“一碗谷子两碗米，面对面睡觉还想你!”语言纯美到了炉火纯青的地步，对爱情的吟唱达到了极致。

　　的确，歌谣中的爱情火辣辣的，叫你我羞于启齿，却永远也不会忘记。□

抽象思维和分析：架构师必须能够理解表述模糊的概念并将其变成相关各方能够理解的项目构件。开发人员经常具有很强的数学能力，而好的架构师则倾向于表现出更强的口头表达能力。架构师可以偏爱任何经典的、经过时间考验的软件系统开发方法。

　　在寻找优秀的指挥的时候，您首先要找的是一名优秀的音乐演奏家。但并非每个音乐演奏家都能成为优秀的指挥。架构师的专业发展方面也与此类似。越来越多的 IT 组织开始认识到良好软件体系结构的重要性，架构师职业正迅速发展为 IT 内一个独立的门类。由于要从相当小的候选范围内招募架构师，因此这就给管理带来了一些新挑战。即使人力资源部门找到了候选者，针对经验进行的筛选也比其他门类更为严格。跨越这些障碍的最快方式是要认识到，大部分好的架构师同时也是好的开发人员，因此寻找架构师人才时可能首先应该从普通开发人员中找起。招聘人员在对候选者(内部或外部)进行详细审查时，应该考虑这个观点。不过，对此资源进行挑选可能比较麻烦，因为只有极少的优秀开发人员具有成为架构师的特征或愿望。

　　本文列出了开发人员成为架构师要进行的工作。我将从可能考虑进行此转型的开发人员和评估进行此转型的开发人员的经理这两个方面来探讨这一问题。我还将提供一系列在做出这些决策时要考虑的因素。

　　个人特征

　　软件开发团队和管理层之间的联系始终是 IT 中的一个关键所在。二者都倾向于以完全不同的方式考虑给定的问题。大部分相关技术都是讨论项目经理应如何跟踪和解释开发人员的进度和问题。但沟通不足的情况仍然非常普遍，而且这是项目失败的首要原因。好的架构师是解决这个问题的最有效办法。架构师的主要责任是提供开发人员和项目经理之间的共用沟通媒体。他们负责让业务规则及需求与工程实践及限制相适应，以确保成功。以下是成功架构师的一些主要特征。

　　愿意并有能力进行沟通：在开发人员中发现架构师的最有价值标准是有效的沟通。您需要技术娴熟、经验丰富的开发人员，这样的人员需要有就项目中的业务相关问题进行沟通的经历。架构师经常必须对理解方面的差距进行预计，然后才能有所贡献。他们必须愿意克服困难来确保技术和业务观点的融合。他们并不必对意见交换工作进行计划和协调;这仍然主要是项目经理的工作。他们的任务是确定表述系统设计时的最佳工具和构件，以促进有效的意见交换。他们必须能够判断当前方法显得不足而需要采用新方法的情况。写作技能也非常重要，还需要具有制作草图的技能或使用制图软件的能力。

　　具有处理谈判细节方面的经验：架构师经常需要负责讨论系统开发的技术折衷方案。优先级的冲突可能会带来实践限制、风险规避或可能导致在各个不同业务组之间需求不同。优秀的架构师能够有效地评估技术可能性，并能在不损失项目的主要价值的前提下制订开发计划来处理各种利害关系和限制。这与前面讨论的沟通技能紧密相关，但同时也要体现架构师的技术能力。好的架构师候选者应该是经常帮助对有争议的讨论进行引导的人，能够使讨论得出新的想法，而不会使其在一个位置停滞不前。

　　自觉主动;积极解决设计问题：架构师的日常工作目标经常并不明确。很多开发人员直接参考功能规范来列出任务清单。架构师通常则是向这些开发人员提供所需结构的人员，以便尽可能提高工作效率。好的候选者不仅进行沟通方面的工作，而且也会预计各种设计问题并加以解决——通常在没有任何具体指示的情况下自觉进行。无论所分配的职责如何，积极参与项目的开发人员都有机会从一起工作的人员中脱颖而出。

　　抽象思维和分析：架构师必须能够理解表述模糊的概念并将其变成相关各方能够理解的项目构件。他们必须能够理解抽象概念，并以具体的语言对其进行沟通。开发人员中好的候选者经常要求或自己主动解释开发生命周期中容易混淆的问题。他们能迅速评估各种想法并将其纳入后续工作的操作建议中。

　　开发人员经常具有很强的数学能力，而好的架构师则倾向于表现出更强的口头表达能力。管理人员经常说开发人员具有“工程意识”，而这是一个用于评估架构师的非常有意义的方面。架构师应该具有很强的解决技术问题的能力，但还必须能够准确获知更为全面的人员如何与技术交互的信息。这要求具有某种形式的抽象思维(而不再是代码的细节)，这种思维能力可能较难形成。

　　有些人认为，某种级别的正式教育是成为优秀开发人员的必备条件之一，我并不同意这种精英论。我遇到了很多高中就辍学的优秀开发人员。不过，对于体系结构设计工作，我的个人经验以及我对所需能力的认识都让我相信，好的架构师通常至少获得了一个有挑战性的学士学位。

　　跟踪生命周期

　　好的架构师通常有在具备定义良好的软件开发生命周期(Software Development Life Cycle，SDLC)的组织工作的经验。架构师必须理解在其所属专业内最重要的操作过程。这并不意味着需要有其他前提，例如，并不需要高能力成熟度模型(Capability Maturity Model，CMM)级别的工作经验。好的架构师可能来自使用 SDLC 的多个小型迭代的极限编程(Extreme Programming，XP)方法的组织。务必注意各种传统软件开发操作，如 Michael A. Jackson 的方法：Jackson 结构编程(Jackson Structured Programming，JSP)和 Jackson 系统开发(Jackson System Development，JSD)。Jackson 的研究对架构师职业发展的意义就像 Donald Knuth 的研究对程序员一样重要。架构师可以偏爱任何经典的、经过时间考验的软件系统开发方法。

　　SDLC 也可以成为评估架构师合适人选的有用机制。每个 SDLC 阶段都具有能提供相关线索的特征。SDLC 包含很多小的变体，但在此部分，我将使用几乎所有方法的公共基础部分。下面的列表详细说明了 SDLC 的各个阶段，并列出了好的架构师候选者在每个阶段表现出来的特征。

• 　　分析：在分析期间，好的架构师会考虑非技术影响，以便了解需求和将在其中进行开发的环境。架构师可为风险评估任务带来广泛的软件经验供参考。寻找具有丰富经验的开发人员，以帮助业务部门理解技术人员正确解释需求所需的信息。寻找在开发的早期阶段能够预计可能遇到的问题的开发人员。
• 　　设计：在高级设计期间，好的架构师会收集问题空间的各个抽象元素，并就其进行沟通，以便开发团队草拟将要开发的系统的相关图表。架构师负责将需求谨慎地映射到所得到的系统体系结构的功能。在详细设计期间，他们所扮演的角色并不是核心角色，但为了根据整个系统的规则对特定模块的元素进行审查，仍然需要他们。寻找善于让团队能够预计设计决策对最终系统的影响的开发人员。寻找善于确定一些最佳构件来促进与技术和非技术受众沟通设计问题的开发人员。
• 　　实现：在实现期间，架构师对项目进行引导，以确保其符合系统体系结构。他们在一线评估技术更改请求，并确定如何对设计进行调整，以最好地处理此类请求。架构师还要密切了解开发人员的进度，特别要跟踪系统中模块间的集成点的状态。寻找经常对讨论进行引导来连接多个子系统的开发人员。寻找项目经理可以依赖其快速地进行与更改和出现的问题相关的风险评估的开发人员。
• 　　测试：架构师对系统集成和用户接受度测试进行指导，并负责评估进度的正确沟通的持续测试结果。寻找理解错误模式且善于将测试复查结果转换为行动计划的开发人员。
• 　　维护：在维护期间，架构师将发起关于系统集成的讨论。无论处理 IT 基础设施问题，还是确保部门之间的技术合作，架构师都必须完全理解应用程序，必须快速学习姊妹应用程序的体系结构，而且必须就集成点和风险进行有效沟通。寻找具有系统集成经验且表现出快速掌握全貌的能力的开发人员。系统集成是一项独特的任务。

　　架构师培养建议

　　有些组织能比其他组织更有效地进行架构师培养。如果充分考虑到招聘此类新专业人才的困难，努力促成能鼓励开发人员发展为架构师的环境是非常明智的策略。但务必避免对不愿意或不适合走这条路的开发人员进行处罚。组织应该为开发人员制订多条发展路线，包括那些愿意继续担任开发人员的人。对架构师而言，资深开发人员不可或缺。他们可以实现系统中最关键的模块。通过对其他开发人员进行代码检查和测试支持，他们可帮助确保总体软件质量，而如果质量不能保证，即使最好的体系结构也毫无用处。

　　组织应制订个人评估程序，以鼓励开发人员考虑其职业目标，其中要包含体系结构设计的选项。应该鼓励经理在其下属中寻找体系结构设计人才。应该实现指导计划，让架构师与希望成为架构师的开发人员协作工作。应该鼓励开发人员通过参加各种协会、撰写文章和参加会议，从而参与到专业领域中来。通过这样参与进来，可帮助开发人员从新的角度理解系统，并帮助他们更好地就其认识进行沟通。这样还能培养可提高效率的重要创新想法。

　　结束语

　　开发人员一旦迈出了通向体系结构设计专业方向的第一步，就可以利用很多资源来获得帮助，其中包括很多来自 IBM 的资源。有时候，此过程的最困难的部分就是第一步，而本文提供了一些线索和提示，经理和开发人员可以利用其来评估应该鼓励哪些人努力成为架构师。

EJB用自己的悲剧人生警告Sun，不可对新技术的推广掉以轻心，但Sun还是再次犯下同样的错误。与Microsoft和Intel成功的商业推广策略截然不同的是，Sun 完全没有估量到，JSP作为一项成功技术的价值和影响力，在JSF的推广上，出现了令人痛心的失误。如果JSF以JSP3.0的名义推出，那么JSF的日子恐怕要比现在好过得多。

    1. JSF没有站在JSP巨人的肩膀上

    前文说过，EJB是Sun的伤心往事，它用自己的悲剧人生，警告Sun，不论技术也好，商务也好，凡事应该有一个全盘的规划，再也不能想到什么是什么了。一项好的技术，如果不加以适当的推广，最后可能逃脱不了被束之高阁的命运，大把的资金投入，自然也难免竹篮打水一场空。

    当然，如何进行商业运作，Sun比我高明得多了，似乎轮不到我在这里说三道四，不过，Java已经不单单属于Sun了，Java已经成为全世界的Java，所以，所有的Java程序员，都有发表自己意见的权利。未必都是真知灼见，但Java世界就是因为有这些不同声音的存在，才显得无比的精彩。

   其他的技术我不敢妄加评论，就JSF这项技术而言，Sun的商业策略实在是不敢恭维。在JSP已经深入人心的时候，为什么不继续沿用JavaServer Pages的这个如雷贯耳的名称，而要标新立异地推出一个JavaServer Faces的怪物呢？你看人家Microsoft，在ASP流行开来之后，推出ASP.NET，是多么的顺理成章。 

    暂且不论这两项技术的区别有多大，就冲着似曾相识的名称，Microsoft就让大批的ASP用户，自觉自愿地加入ASP.NET的阵营。没有任何抵抗，Microsoft兵不血刃，不费一枪一弹就完成了从ASP向ASP.NET的过渡。

    同样的策略Intel也曾使用过。第一代“奔腾”芯片推出后，获得了巨大的成功，“奔腾”一词，一时间名噪天下。Intel看到了这一点，并且立刻明白了该怎么做，所以，当下一代芯片制造出来时，Intel完全没有在命名上费什么脑筋，直接冠以“奔腾II”的名字，马上令一大批“奔腾”的爱好者趋之若骛。此后，“奔腾III”“奔腾IV”，Intel将“奔腾”一词的所有油水都榨干了，才心满意足地构思下一个名字。

    相比之下，Sun则完全没有估量到一项成功技术的价值和影响力。令多少对手眼红的JSP背后庞大的用户群，Sun却视若无物，不知道Sun是没有看到这一点呢，还是不屑利用这一优势。

    不管怎样，当JSP如日中天时，不知借JSP之势点燃JSF的大火，反而暴殓天物，另起炉灶，Sun简直就是在自毁JSF的前程。也许Sun主观上并不存在这样的故意性，但客观上造成了这样一种局面，也是不可原谅的失误。

    2. JSF唯有一切从头再来

    如果JSF没有叫做JSF，而是叫做JSP 3.0，情形会是如何呢？

    可以想见，首先，大批的JSP爱好者会蜂拥而至，庆贺JSP的新版本；然后，一批“牛人”们很快发现，JSP的新版本，引入了他们期待已久的组件模型和事件驱动模式，JSP终于有了和ASP.NET抗衡的资本；接下来，“牛人”们必定奋笔疾书，以超凡的热情四处撒播JSP 3.0的种子。

    于是，网络上、论坛里，到处充斥着为JSP 3.0唱赞歌的文章，JSP 3.0成为炙手可热的名词，而Sun专家们借JSP 3.0的名义推销的JSF组件模型和事件驱动模式，说不定现在已经成为Java Web编程的新贵。

    将JSF以JSP3.0的名义发布，绝非戏言，是完全可行的。从技术上来看，JSF是建立在Servlet/JSP基础之上的，和JSP有着天然的联系，将JSF作为JSP3.0的一个崭新的扩充部分，随JSP3.0一起发布，即符合从JSP到JSF的平滑过渡的要求，同时也能满足程序员对于JSP3.0新特征的期待。

    实际上，JSF和JSP融合的趋势越来越明显，例如在JSF1.2版本之前，JSP和JSF各有一套独立的表达式语言（EL，Expression Language），而从JSF1.2开始，这两套不同的表达式语言已经统一为Unified EL，并且从JSF和JSP规范中分离出来，自成一体。所以，让JSF搭上JSP的快车，一起前进，其实是很自然的事。

    可惜，这些只能发生在Sun的梦里了。JSP与JSF，一字之差，Sun将一项颇具潜力的Java Web框架技术，亲手打回到娘胎中，让其以一个初生婴儿的身份，光着身子降临到Java Web世界。这个本来可以衣着光鲜地与ASP.NET一起独步江湖的汉子，现在唯有恨恨地抛下一句“君子报仇，十年不晚”，然后黯然离去了。

看不懂之一：    一方面搞开发的已经不是太好找工作，每次招聘会都会有大量的求职者；另一方面软件人才的培养规模却越来越大，国家支持的大量新软件学院，各种与软件开发相关的民办大学，各种以就业为目标的软件开发培训班（如新东方的JSP程序员培训16500三个月〕；
看不懂之二：    搞开发的程序员认为税后4000已是低薪，税后6000也就一般；同时大家又都哀叹中国软件市场不成熟，盗版多，用户接收程度低，价格低，利润少；不知道程序员希望获得的薪水都是从哪里来的？

看不懂之三：    新技术，新工具层出不穷，一个比一个复杂，一个比一个玄妙；而会用的人，或自认为自称为“熟练掌握”的人也是层出不穷；

看不懂之四：    整个软件产业的发展一再证明：软件成为产业必须有规模化的经营和团队式开发，个人式小作坊式的开发没有生路（这也是软件工程的产生原因），同时国外的软件公司团队规模越来越庞大，内部分工越来越精密；而在国内，个体的、小团体的软件开发方式却越来越流行，许多软件开发人员的开发工作完全以个人方式完成，并且许多人在极力宣扬“个人比公司好”的思想；

看不懂之五：    许多程序员对自己的待遇不满意；却有越来越多只会（我强调的是只会）VB简单编程的人员（许多都从其他行业转行而来）加入程序员的队伍，使得程序员队伍的水平和素质越来越差，企业不愿给这样“混饭吃”的程序员以更好的待遇；

看不懂之六：    国外做产品的公司往往是大公司，才能保证产品的质量和研发的长久性，而做服务，做二次开发和应用开发的往往是小公司，才能贴近用户的需求，并且充分满足它；在国内正好相反，做产品的往往是小公司，做集成和服务，做二次开发的往往是大公司（包括用友、金蝶，也热衷于按框架进行项目承接）；

看不懂之七：    国外企业是先有规范管理的制度和思想，才上ERP软件；国内是没有科学的管理就先上ERP软件，结果是软件没人用，管理仍落后；

看不懂之八：    国外做ERP，CRM产品的都是相当有实力的大企业；国内却有无数个人（单个的开发人员）开发出了全套的ERP，CRM软件；

看不懂之九：    几乎所有软件开发公司和个人都强烈反对盗版－－因为这意味着自己的软件挣不着钱；但几乎所有开发软件的公司和个人的开发工具和环境都是用盗版安装的；

看不懂之十：    ERP，CRM这样的东西本来是未来规范管理，科学决策的；但在国内的企业上ERP，CRM往往都是由一个领导来拍板，而拍板的领导往往不懂ERP和CRM，只懂得攀比，还有拿回扣；

看不懂之十一：    推销软件时大多数客户都会告诉你：你的软件不符合我们的需求；而符合他们需求的软件他们也并不去买；

看不懂之十二：    大家都在羡慕印度的软件产业发展迅猛，并暗自较劲要如何赶超；但对于印度软件产业的基石－－开发工作程式化，大量采用软件工人，又满心鄙夷，谁也不愿去当工人；

看不懂之十三：    大家都认为软件工程可以提高软件开发的生产率，可又都不按照软件工程的基本要求去完成软件开发；就好比觉得文档应该齐备，可谁也不愿意写文档；

看不懂之十四：    很多人都反对微软的霸权，可又没有人真正去做和微软竞争的核心的东西；

看不懂之十五：    大家都认为软件这行有前景，可现在没有几个软件公司是赚钱的。

清晨的公车、地铁处，是一个让人心情压抑的地方，这里没有对话，没有微笑，甚至连埋怨也没有。

许多人静静地站着，极其耐心地站着。年轻的姑娘该有微笑吧？没有的，她们双手环抱，低着头，看着公车开来的方向。孩子该有微笑吧？也没有 ，他们背着沉重的书包，脸色疲倦而焦躁。

有一位澳洲媒体的编辑，他在上海、杭州考察了一圈，他说：“这里的人，心事为什么那么重？”编辑说，清晨，空气是那么清鲜，扫过水的街道湿漉漉的，没有灰尘扬起。太阳已经升上来了，金色的光辉从高楼大厦间斜射过来，这是多么美好的事情。人们经过了一夜的酣睡，该精神抖擞才对，可是，如此美妙的清晨，人们的表情为什么像地球末日即将来临。

没有人能回答澳洲编辑的问题。

在澳洲，人们的工作节奏是缓慢的，他们的生活是散淡的。每个周末，当中国城市灯火辉煌时，澳洲城市里的商家，却打烊回家了。

是的，我们现在无法回到的澳洲人那样的生活，我们越来越趋同于新加坡、东京、纽约人的生活节奏。

但是，我们又有什么理由，让我们在这个美妙的清晨，丧失自己最醉人的笑容，我们为什么不能对昨晚一场美美的睡眠，对清晨的风和日丽而感恩，露出欢颜呢？

我们已被工作压弯了腰，我们已没有心境体会清晨的美妙。那么，让我们来听一首《圣经》的唱诗：

迎着晨曦，迎接新的一天，哦，主啊，我要感谢你！感谢你将新的一天赐给我们，感谢你赐阳光、雨露和空气，感谢你赐下生命活水，感谢你赐下永生盼望，感谢你在尘土中将我抬举，感谢你的大爱，我要感谢直到永远！

朋友啊，感恩才会快乐，快乐才是生命的意义所在。让我们从感谢清晨开始，露出你醉人的微笑吧。

道是悟的 而非学的 悟即思考
吾当生命不息 思考不止

思考的源泉来源于实践和理论
理论在于多读书 叫厚积 玄览
实践在于模拟 行动
思考在于从实践和理论中 薄发 涤虑 抽取

行动当有目标指导约束监控 而不至偏离
快速行动当有成熟的模式资源培训组织管理以及强大的支持力
吾辈注定做了实作者 就踏踏实实的实实在在做些事情

软件设计通过软件统设计模型来表示（参见《再议模型》），软件设计评价是对软件系统设计模型的评价。在这里，我们使用源系统表示软件要实现自动化的系统，它处于实体空间；目标系统表示要实现的软件本身，它处于形式空间。软件表示模型（即系统分析模型和系统设计模型，参见《再议模型》）是沟通源系统和目标系统的桥梁。表示模型的形成需要一个过程，我们称其为过程空间。下面我们使用图形方式来描述：

               这样，软件设计评价应该具有三类标准，分别是实体空间标准、过程空间标准和形式空间标准。

              
            实体空间标准以源系统做为标准来度量系统设计模型。这依赖于我们对于源系统的认识程度，我们知道应该具有这样一个标准，但实行起来非常困难。设计的合理性就是实体空间标准，它没有一个具体的内容和形式。

              
            过程空间标准在设计评价中经常被使用。它可以看作实体空间的间接标准，基于分析模型和设计模型是出于同一实体，其中具有自然的关联。我们说，设计是否附合需求，就是检验设计模型和分析模型的一致性。

               
            形式空间标准以目标系统的角度检验系统设计。从上述两种标准，可以保证目标系统的功能满足源系统，但不能保证目标系统在运行状态下的质量属性。所以形式空间标准是从目标系统的质量出发来考察系统设计的。考虑到质量，我们使用McCall/GE质量模型，它围绕产品改进、产品运行、产品移交三种使用情况来组织质量属性，可以看出是基于目标系统的。国际上有很多现行的基于质量评价系统设计的方法，我们后面会参考其中的部分。
            虽然从理论上我们可以知道软件设计评价具有三类标准，但却没有办法真正按照这些标准去检验一个软件的设计。

              
            实体空间标准应该是一个软件设计最终应该附合的标准。但是，这个标准很难直接应用于软件设计模型上，因为软件设计是思维的产物，在实体上检验这个产物是否正确，恐怕只能说“实践是检验真理的唯一标准”了。只有在错误非常明显的情况下，这个标准才会起作用。

               
            过程空间标准相对好一些。通过和软件生产过程前期阶段产物进行对比，可以找到其中不一致的地方，这可能就是设计上的问题了。同时，现代软件开发一般采用迭代的方式进行，设计活动可能分多次进行。这种迭代也要求我们检查设计对需求的覆盖情况。

               
            通过形式空间标准对软件设计进行检验时，往往并不存在一个唯一的检验标准。这是因为实际软件的质量要求不是唯一的，不同的软件有不同的质量属性要求。而特定软件的质量要求，是在需求分析、设计的过程中逐步形成的。这些质量要求，最终成为我们检验软件设计的标准之一。

                根据这些标准，我们现在设计一个软件设计评价表模版：

                  软件设计评价表
                  软件名称 迭代周期
                  设计人员
                  评审人员
                  设计合理性
                  
                  
                  
                  
                  需求附合度
                  功能点覆盖率（FPC）?%重点功能点覆盖率（IFPC）?%
                  优先功能覆盖率（PFPC）?%需求一致度(Should be 100%)?%
                  质量属性
                  模块性权重在过程中确定权重分数，100分制，下同
                  可修改性权重权重之和应为100%
                  可扩展性权重下同
                  性能权重 
                  可靠性权重 
                  可用性权重 
                  可移植性权重 
                  可维护性权重 
                  灵活性权重 
                  可重用性权重 
                  可理解性权重 
                  弹性权重 
                  安全性权重 
                  容错性权重 
                  评审结论
                  
                  
                  
                  

                在设计合理性方面，主要考虑以下内容：

              类的职责单一、明确
              模块结构清晰、完整
              活动、行为描述清晰
              实体关联清楚，状态合理

                对需求附合度的要求要在评价之间确定。

               
            质量属性的评价权重一般在设计开始之前确定，这个工作多数在架构设计时刻完成。最后，
根据质量属性的权重，可以计算设计的总体质量分数。这些都是最终评审结论的素材。

               
            一般来说，对于设计的评价通过建立场景的方法来实现。比如评价可修改性，一般先建立一个修改的场景，
对设计进行模拟修改，观察其是否易于修改。有些质量属性无法通过这种方法检验，只能通过对设计模型进行观察得出
结论。
            

岩前倚杖看云起；
松下操琴待鹤归。

阅透人情知纸厚
踏穿世路知山平

多言即少味，
无欲斯有为。

宠辱不惊，看庭前花开花落；
去留无意，望天上云卷云舒。

长空有月明两岸；
秋水不波行一舟。

香分花上露;
水吸石中泉。

月下共对一壶酒,
花前相看知心人。

重购的基本思想：
第一，提取，包括类（子类，超类等），函数。也就是把表达一个单独的逻辑含义的包装在一起，更好的表现他独立的意义。
这个里面就有一系列的Extract方法，Extract Method，Extract Class，把长的逻辑表达式也表示为由意义的单元。
第二，为变量函数等选择合适的地方，可能他们更多的与其他的类或者函数交互因而更应该那个类的方法或者变量。有一系列的
Move方法。move from，to，up，down。
第三，替换，用类型和Override来替代Switch，用Stratey，State模式来特换函数，以提供可变的行为。改变函数名，类的名
字，让他们更有意义。
第四，所谓的臭味，如同我们维护别人的代码，看着看着我们就忘了他在做什么了。这个里面有两个最突出的臭味，大和长
（男人会认为有什么不对吗？个人感觉挺好的，特别是如果你身边有个马SS的话）。大的函数，大的类，长长的参数，长长的
数据成员等等。这时就要把他们break into pieces.
第五，重构的方法学，小步前进，重视单元测试，持续重构。

项目管理：
1，合理的计划制订和风险应对措施以及团队构建结构
2，深入了解团队成员并结合1的成果进行合理的分工或者人员招聘
3，建立完善的资源获取渠道和高效的沟通渠道
4，建立高效的培训指导机制和目标注入方式
5，和上层，客户，市场部门，质量部门等协同部门间平等且直通的渠道

架构设计：
1，优秀的架构和简洁的接口（简洁如艺术的优雅）
2，明晰的层次和良好的扩展
3，可检测的性能指标设计

概要设计：
1，合理的功能划分和类骨架设计
2，主要流程的时序设计
3，核心实体以及配置文件的数据结构
4，技术难点的攻克和核心算法的设计

详细设计：
1，类属性和方法的设计和核心程序的实现
2，内部流程的时序

代码实现：
1，标准的注释 简赅的语言
2，良好的程序结构和异常处理

质量保证：
1，每日的简短跟踪和每日的实现部署
2，严格的质量指标制订
3，严格的版本控制和资源控制

业务用例对角色（什么样的个体和接口访问到我们识别出来的各种业务任务）
业务对象对业务对象（各个业务对象之间是如何彼此交互的，和他们共享信息的种类）
用例对用例（任务彼此之间的依赖，和被一定的过程共享的公用任务

用例设计误区
用例被创建的太大或者太小 －－ 粒度问题
用例在跨越团队的情况下不一致  －－ 用例一致性（形式 含义）
没有对用例分组的包进行良好的计划  －－ 模块划分不合理
不合理的对模型的访问进行控制，导致在团队分析协作的过程中发生冲突  －－ 开放式团队管理
过于细致的定义用例，在用例进入原型、设计和开发任务之前就定义每一件事情  －－ 粒度太小 需求确定的可以这么做 不稳定的当抽象为主 对应变更
定义用例时过于简单，使需求被工程团队可以有众多的解释  －－ 言语还是不确定 无法用语言表达的借助图形 图形无法描述的 定义术语集合 语言支持

角色模型
模块模型

在从用例向设计类转化的过程中，我们希望能够实现：

将分析小组的知识传授给工程团队。   －－ 文档传承 结构合理易于理解的文档（加以详细注释）不失为最好的选择
识别能够满足所有需求的技术方案 — 或者，什么地方不是可能的，识别与技术方案冲突的需求，并确定是否他们是重要的或者被改变或者被删除。
 －－ 需求阶段应该加入这样的分析和模型了
识别能够帮助确定团队结构、架构层次和对于购买软件的候选的接口。
 －－ 整合好的方案 不能整合的以清晰的头脑单做
指定技术方案的细节并开始计划如何在团队之中分配工作。
 －－
基于设计模型的细化时间进行计划和预算的预估。
 －－ 经验 改进
分配类到平台、产品和私有代码。
 －－ 拿手完
为了反馈和同步的目的，生成软件架构文档，软件架构文档能够被分发到内部和外部的团队成员。
 －－ 传承沟通

我们如何组织通用的服务？
回答：公用服务被单独的放在一个子包中（日志服务；数据同步和备份服务；访问控制服务和登陆服务）。
我们应该在 shipping 和 part management 之间画线吗？
回答: 我们不需要连接他们两个。
我们根据领域还是架构来定义子系统？
回答：架构在大多数地方都能与领域结合。
我们允许包之间的双向依赖吗？
回答：不。这是违背我们内部设计指导方针的不好的设计实践。
MDA 的观点下有四个原则：

以一种定义良好的符号表示的模型是理解企业级方案系统的基础。
系统的构建能够围绕着一系列模型通过使用在模型之间的一系列转换被组织的，并且能被组织到一个分层的和转换的体系架构框架中。
以一系列元模型来描述模型的一种正式的支持能力能够使在模型中有意义的集成和转换变得容易，并且是通过工具实现自动化的基础。
接受和广泛采纳基于模型的方法需要工业的标准提供开放性给客户，并鼓励供应商之间的竞争。

OMG已经定义了一系列的层次和转换，他们为MDA提供了概念性的框架和词汇表。
特别的，OMG 确定了四种模型类型：
计算无关的模型（CIM），
平台无关的模型（PIM），
被一个平台模型（PM）描述的平台相关的模型（PSM）和
一个实现相关的模型（ISM）。

问题领域模型和方案领域模型
业务建模 数据建模 安全建模 性能建模
狭义上讲，它是关于一个系统的不同抽象模型，和在模型之间定义良好的模型转换的。
广义上讲，它是关于抽象的各种级别上的模型，这些抽象作为基础为软件架构服务，这些架构最终将通过各种实现技术被实现。

痴人痴梦斥耻泪
缘散缘尽怨鸳恨

立绝壁顶望三千尺深沟
握金刚钻凿五万里长卷

倾半生力写七仞行酸诗
给一张脸抽九百团红印

春时青草绿欲滴
冬秋枯黄灶底柴
青春人生过有时
惜时打拼遍尝味

住田园种梯田年年穿戴田产棉
听泉声饮冽泉天天侍弄泉浇园
剩余的粮食和棉卖成钱
换来闲钱买来了纸和盐
写下了酸文撞倒了醋坛
可怜不可怜 唉 梦醒了

在浮躁的年代里，我们进取心太切，患得患失；虚荣心太强，战战兢兢。一心争强好胜，惟恐榜上无名。
     说起来夸夸其谈、头头是道，做起事来心中无数、手足无措。
在浮躁的年代里，我们哗众取宠,急功近利，惟名是图。于是我们盲目追赶朝流、投机取巧，不做实事、也做不出实事。
在浮躁的年代里，我们为达目的，不择手段。于是我们盗版，随意践踏别人的劳动成果，侵犯别人的知识产权。
在浮躁的年代里，我们随波逐流，没有主见，没有定力，人云亦云。于是我们只能整天围着Microsoft、IBM、SUN转圈。

因为我们浮躁，所以我们没有目标。
因为我们浮躁，所以我们没有发明C/C++、Java、Ruby，甚至面对Spring、Hibernate，我们也只有膜拜。
因为我们浮躁，所以我们做学问只得天天面对无趣的English，并美其名曰：“师夷长技以自夷”。
做官因为浮躁，所以成为庸官；做学问因为浮躁，所以一事无成；做人因为浮躁，所以为人浅薄。
在浮躁的年代里做学问难，做好学问更是难上加难！

                －－－－－以上引自某强人贴    

当浮躁成为流行的时候  给你打招呼的时候 我会说：这两天你浮躁了吗
你会说 当然浮躁了 不浮躁别人不给发工资呀

为了不浮躁，先用好别人的东西，再创新出自己的产品！！
8月18 Infoer-BDF(bussiness data flow)-EAI For Soa 第一版一定出品。

对于一个软件产品，我对于其成功的理解是用合适的资源创造了合适能用的产品，使得最终的目标达到了大家的要求。
举个例子：削铅笔。当我们开始酝酿的时候，合适的资源是一个铅笔刀和能够使用铅笔刀的人，当铅笔刀不够锋利的时候，
此时就需要进行磨刀的工作，此时，就要求有新的资源－－磨刀石。此时，对于管理决策者来说，是采购一个磨刀石呢还是
采购一个铅笔刀呢，这个问题在不同的场景下有不同的决策结果。而往往管理决策者一开始规划的很大，已经不存在铅笔刀

的
概念，而是采用了斧子，又因为时间和进度的关系，斧子大多都是钝的，当进行工作准备的时候，大家都在忙着磨斧子，大

概用
手摸了摸，觉的可以开始了，就开始削了。因为斧子的锋利度不一样，各人的进度和质量就不一样。此时，产生的状态有
1，斧子锋利的（分析 设计做的好的，编码功夫扎实的），很快的工作着
2，斧子较为锋利的（分析 设计做的不太好的），也就凑合着削，难免有时候，削断了铅笔，浪费着资源，影响着进度和质

量
3，斧子不锋利的（分析 设计做的不好的），有些决定重新磨，有些用斧子砸掉铅笔 走人不干了。
4，斧子不能用的   聪明的 自己买了铅笔刀 不聪明的在苦苦的挣扎.
这就是各人磨自己的坏处。软件开发是一个团队的工作。
所以，我们组件了团队，就要用科学的分工。在前期准备工作的时候，将分工磨刀，端水的端水（项目经理干这个最合适）
，主要设计人员磨，项目经理配合测试人员验证磨出刀子的质量。还有开发人员在学习刀子的用法。这样我们将风险降到最
低了。

我要从徐家汇赶去机场，于是匆匆结束了一个会议，在美罗大厦前搜索出租车。一辆大众发现了我，非常专业的、径直的停在我的面前。这一停，于是有了后面的这个让我深感震撼的故事，象上了一堂生动的MBA案例课。为了忠实于这名出租车司机的原意，我凭记忆尽量重复他原来的话。

“去哪里……好的，机场。我在徐家汇就喜欢做美罗大厦的生意。这里我只做两个地方。美罗大厦，均瑶大厦。你知道吗？接到你之前，我在美罗大厦门口兜了两圈，终于被我看到你了！从写字楼里出来的，肯定去的不近~~~”

“哦？你很有方法嘛！”我附和了一下。

“做出租车司机，也要用科学的方法。”他说。我一愣，顿时很有些兴趣“什么科学的方法？”

“要懂得统计。我做过精确的计算。我说给你听啊。我每天开17个小时的车，每小时成本34.5元……”

“怎么算出来的？”我追问。

“你算啊，我每天要交380元，油费大概210元左右。一天17小时，平均每小时固定成本22元，交给公司，平均每小时12.5元油费。这是不是就是34.5元？”，我有些惊讶。我打了10年的车，第一次听到有出租车司机这么计算成本。以前的司机都和我说，每公里成本0.3元，另外每天交多少钱之类的。

“成本是不能按公里算的，只能按时间算。你看，计价器有一个“检查”功能。你可以看到一天的详细记录。我做过数据分析，每次载客之间的空驶时间平均为7分钟。如果上来一个起步价，10元，大概要开10分钟。也就是每一个10元的客人要花17分钟的成本，就是9.8元。不赚钱啊！如果说做浦东、杭州、青浦的客人是吃饭，做10元的客人连吃菜都算不上，只能算是撒了些味精。”

强！这位师傅听上去真不象出租车司机，到象是一位成本核算师。“那你怎么办呢？”我更感兴趣了，继续问。看来去机场的路上还能学到新东西。

“千万不能被客户拉了满街跑。而是通过选择停车的地点，时间，和客户，主动地决定你要去的地方。”我非常惊讶，这听上去很有意思。“有人说做出租车司机是靠运气吃饭的职业。我以为不是。你要站在客户的位置上，从客户的角度去思考。”这句话听上去很专业，有点象很多商业管理培训老师说的“put yourself into others' shoes.”

“给你举个例子，医院门口，一个拿着药的，一个拿着脸盆的，你带哪一个。”我想了想，说不知道。

“你要带那个拿脸盆的。一般人病小痛的到医院看一看，拿点药，不一定会去很远的医院。拿着脸盆打车的，那是出院的。住院哪有不死人的？今天二楼的谁死了，明天三楼又死了一个。从医院出来的人通常会有一种重获新生的感觉，重新认识生命的意义，健康才最重要。那天这个说：走，去青浦。眼睛都不眨一下。你说他会打车到人民广场，再去做青浦线吗？绝对不会！”

我不由得开始佩服。

“再给你举个例子。那天人民广场，三个人在前面招手。一个年轻女子，拿着小包，刚买完东西。还有一对青年男女，一看就是逛街的。第三个是个里面穿绒衬衫的，外面羽绒服的男子，拿着笔记本包。我看一个人只要3秒钟。我毫不犹豫地停在这个男子面前。这个男的上车后说：延安高架、南北高架~~~还没说后面就忍不住问，为什么你毫不犹豫地开到我面前？前面还有两个人，他们要是想上车，我也不好意思和他们抢。我回答说，中午的时候，还有十几分钟就1点了。那个女孩子是中午溜出来买东西的，估计公司很近；那对男女是游客，没拿什么东西，不会去很远；你是出去办事的，拿着笔记本包，一看就是公务。而且这个时候出去，估计应该不会近。那个男的就说，你说对了，去宝山。”

“那些在超市门口，地铁口打车，穿着睡衣的人可能去很远吗？可能去机场吗？机场也不会让她进啊。”

有道理！我越听越有意思。

“很多司机都抱怨，生意不好做啊，油价又涨了啊，都从别人身上找原因。我说，你永远从别人身上找原因，你永远不能提高。从自己身上找找看，问题出在哪里。”这话听起来好熟，好像是“如果你不能改变世界，就改变你自己”，或者Steven Corvey的“影响圈和关注圈”的翻版。“有一次，在南丹路一个人拦车，去田林。后来又有一次，一个人在南丹路拦车，还是去田林。我就问了，怎么你们从南丹路出来的人，很多都是去田林呢？人家说，在南丹路有一个公共汽车总站，我们都是坐公共汽车从浦东到这里，然后搭车去田林的。我恍然大悟。比如你看我们开过的这条路，没有写字楼，没有酒店，什么都没有，只有公共汽车站，站在这里拦车的多半都是刚下公共汽车的，再选择一条最短路经打车。在这里拦车的客户通常不会高于15元。”

“所以我说，态度决定一切！”我听十几个总裁讲过这句话，第一次听出租车司机这么说。

“要用科学的方法，统计学来做生意。天天等在地铁站口排队，怎么能赚到钱？每个月就赚500块钱怎么养活老婆孩子？这就是在谋杀啊！慢性谋杀你的全家。要用知识武装自己。学习知识可以把一个人变成聪明的人，一个聪明的人学习知识可以变成很聪明的人。一个很聪明的人学习知识，可以变成天才。”

“有一次一个人打车去火车站，问怎么走。他说这么这么走。我说慢，上高架，再这么这么走。他说，这就绕远了。我说，没关系，你经常走你有经验，你那么走50块，你按我的走法，等里程表50块了，我就翻表。你只给50快就好了，多的算我的。按你说的那么走要50分钟，我带你这么走只要25分钟。最后，按我的路走，多走了4公里，快了25分钟，我只收了50块。乘客很高兴，省了10元钱左右。这4公里对我来说就是1块多钱的油钱。我相当于用1元多钱买了25分钟。我刚才说了，我一小时的成本34.5块，我多合算啊！”

“在大众公司，一般一个司机3、4千，拿回家。做的好的大概5千左右。顶级的司机大概每月能有7000。全大众2万个司机，大概只有2-3个司机，万里挑一，每月能拿到8000以上。我就是这2-3个人中间的一个。而且很稳定，基本不会大的波动。”

太强了！到此为止，我越来越佩服这个出租车司机。

“我常常说我是一个快乐的车夫。有人说，你是因为赚的钱多，所以当然快乐。我对他们说，你们正好错了。是因为我有快乐、积极的心态，所以赚的钱多。”

说的多好啊！

“要懂得体味工作带给你的美。堵在人民广场的时候，很多司机抱怨，又堵车了！真是倒霉。千万不要这样，用心体会一下这个城市的美，外面有很多漂亮的女孩子经过，非常现代的高楼大厦，虽然买不起，但是却可以用欣赏的眼光去享受。开车去机场，看着两边的绿色，冬天是白色的，多美啊。再看看里程表，100多了，就更美了！每一样工作都有她美丽的地方，我们要懂得从工作中体会这种美丽。”

“我10年前是强生公司的总教练。8年前在公司作过三个不同部门的部门经理。后来我不干了，一个月就3、5千块，没意思。就主动来做司机。我愿意做一个快乐的车夫。哈哈哈哈。”

到了机场，我给他留了一张名片，说：“你有没有兴趣这个星期五，到我办公室，给微软的员工讲一讲你怎么开出租车的？你就当打着表，60公里一小时，你讲多久，我就付你多少钱。给我电话。”

我迫不及待的在飞机上记录下他这堂生动的MBA课。

1、彼得原理
　　　　每个组织都是由各种不同的职位、等级或阶层的排列所组成，每个人都隶属于其中的某个等级。彼得原理是美国学者劳伦斯·彼得在对组织中人员
晋升的相关现象研究后，得出一个结论：在各种组织中,雇员总是趋向于晋升到其不称职的地位。彼得原理有时也被称为向上爬的原理。 这种现象在现实生
活中无处不在：一名称职的教授被提升为大学校长后，却无法胜任；一个优秀的运动员被提升为主管体育的官员，而无所作为。对一个组织而言，一旦相当
部分人员被推到其不称职的级别，就会造成组织的人浮于事，效率低下，导致平庸者出人头地，发展停滞。因此，这就要求改变单纯的根据贡献决定晋升的
企业员工晋升机制，不能因某人在某个岗位上干得很出色，就推断此人一定能够胜任更高一级的职务。将一名职工晋升到一个无法很好发挥才能的岗位，不
仅不是对本人的奖励，反而使其无法很好发挥才能，也给企业带来损失。

　　　　2、酒与污水定律
　　　　酒与污水定律是指把一匙酒倒进一桶污水，得到的是一桶污水；如果把一匙污水倒进一桶酒，得到的还是一桶污水。在任何组织里，几乎都存在几
个难弄的人物，他们存在的目的似乎就是为了把事情搞糟。最糟糕的是，他们像果箱里的烂苹果，如果不及时处理，它会迅速传染，把果箱里其他苹果也
弄烂。 烂苹果的可怕之处，在于它那惊人的破坏力。一个正直能干的人进入一个混乱的部门可能会被吞没，而一个无德无才者能很快将一个高效的部门变
成一盘散沙。组织系统往往是脆弱的，是建立在相互理解、妥协和容忍的基础上的，很容易被侵害、被毒化。破坏者能力非凡的另一个重要原因在于，破
坏总比建设容易。一个能工巧匠花费时日精心制作的陶瓷器，一头驴子一秒钟就能毁坏掉。如果一个组织里有这样的一头驴子，即使拥有再多的能工巧匠
，也不会有多少像样的工作成果。如果你的组织里有这样的一头驴子，你应该马上把它清除掉，如果你无力这样做，就应该把它拴起来。

　　　　3、木桶定律
　　　　水桶定律是讲一只水桶能装多少水，这完全取决于它最短的那块木板。这就是说任何一个组织，可能面临的一个共同问题，即构成组织的各个部
分往往是优劣不齐的，而劣势部分往往决定整个组织的水平。水桶定律与酒与污水定律不同，后者讨论的是组织中的破坏力量，最短的木板却是组织中有
用的一个部分，只不过比其他部分差一些，你不能把它们当成烂苹果扔掉。强弱只是相对而言的，无法消除，问题在于你容忍这种弱点到什么程度，如果
严重到成为阻碍工作的瓶颈，你就不得不有所动作。

　　　　4、马太效应
　　
　　　　《新约·马太福音》中有这样一个故事：一个国王远行前，交给3个仆人每人一锭银子，吩咐道：你们去做生意，等我回来时，再来见我。国王
回来时，第一个仆人说：主人，你交给我的一锭银子，我已赚了10锭。于是，国王奖励他10座城邑。第二个仆人报告：主人，你给我的一锭银子，我已
赚了5锭。于是，国王奖励他5座城邑。第三仆人报告说：主人，你给我的1锭银子，我一直包在手帕里，怕丢失，一直没有拿出来。于是，国王命令将第
三个仆人的1锭银子赏给第一个仆人，说：凡是少的，就连他所有的，也要夺过来。凡是多的，还要给他，叫他多多益善，这就是马太效应，反应当今社
会中存在的一个普遍现象，即赢家通吃。对企业经营发展而言，马太效应告诉我们，要想在某一个领域保持优势，就必须在此领域迅速做大。当你成为
某个领域的领头羊时，即便投资回报率相同，你也能更轻易地获得比弱小的同行更大的收益。而若没有实力迅速在某个领域做大，就要不停地寻找新的
发展领域，才能保证获得较好的回报。

　　　　5、零和游戏原理
　　　　零和游戏是指一项游戏中，游戏者有输有赢，一方所赢正是另一方所输，游戏的总成绩永远为零，零和游戏原理之所以广受关注，主要是因为人
们在社会的方方面面都能发现与零和游戏类似的局面，胜利者的光荣后面往往隐藏着失败者的辛酸和苦涩。 20世纪，人类经历两次世界大战、经济高速
增长，科技进步、全球一体化以及日益严重的环境污染，零和游戏观念正逐渐被双赢观念所取代。人们开始认识到利已不一定要建立在损人的基础上。通
过有效合作皆大欢喜的结局是可能出现的。但从零和游戏走向双赢，要求各方面要有真诚合作的精神和勇气，在合作中不要小聪明，不要总想占别人的小
便宜，要遵守游戏规则，否则双赢的局面就不可能出现，最终吃亏的还是合作者自己。
       
　　　　6、华盛顿合作规律
　　　　华盛顿合作规律说的是一个人敷衍了事，两个人互相推诿，三个人则永无成事之日。多少有点类似于我们三个和尚的故事。人与人的合作，不是
人力的简单相加，而是要复杂和微妙得多。在这种合作中，假定每个人的能力都为1，那么，10个人的合作结果有时比10大得多，有时，甚至比1还要小。
因为人不是静止物，而更像方向各异的能量，相互推动时，自然事半功倍，相互抵触时，则一事无成。 我们传统的管理理论中，对合作研究得并不多，
最直观的反映就是，目前的大多数管理制度和行为都是致力于减少人力的无谓消耗，而非利用组织提高人的效能。换言之，不妨说管理的主要目的不是
让每个人做得更好，而是避免内耗过多。
　　
　　　　7、手表定理
　　　　手表定理是指一个人有一只表时，可以知道现在是几点钟，当他同时拥有两只表时，却无法确定。两只手表并不能告诉一个人更准确的时间，
反而会让看表的人失去对准确时间的信心。手表定理在企业经营管理方面，给我们一种非常直观的启发，就是对同一个人或同一个组织的管理，不能同
时采用两种不同的方法，不能同时设置两个不同的目标，甚至每一个人不能由两个人同时指挥，否则将使这个企业或这个人无所适从。手表定理所指的
另一层含义在于，每个人都不能同时选择两种不同的价值观，否则，你的行为将陷于混乱。
　　
　　　　8、不值得定律
　　　　不值得定律最直观的表述是：不值得做的的事情，就不值得做好。这个定律再简单不过了，重要性却时时被人们忽视遗忘。不值得定律反映人们
的一种心理，一个人如果从事的是一份自认为不值得做的事情，往往会保持冷嘲热讽，敷衍了事的态度，不仅成功率低，而且即使成功，也不觉得有多大
的成就感。 因此，对个人来说，应在多种可供选择的奋斗目标及价值观中挑选一种，然后为之奋斗。选择你所爱的，爱你所选择的，才可能激发我们的
斗志，也可以心安理得。而对一个企业或组织来说，则要很好地分析员工的性格特性，合理分配工作，如让成就欲较强的职工单独或牵头完成具有一定风
险和难度的工作，并在其完成时，给予及时的肯定和赞扬；让依附欲较强的职工，更多地参加到某个团体*同工作；让权力欲较强的职工，担任一个与之
能力相适应的主管。同时要加强员工对企业目标的认同感，让员工感觉到自己所做的工作是值得的，这样才能激发职工的热情。
　　
　　　　9、蘑菇管理
　　　　蘑菇管理是许多组织对待初出茅庐者的一种管理方法，初学者被置于阴暗的角落（不受重视的部门，或打杂跑腿的工作），浇上一头大粪（无端
的批评、指责、代人受过），任其自生自灭（得不到必要的指导和提携）。相信很多人都有过这样一段蘑菇的经历，这不一定是什么坏事，尤其是当一切
刚刚开始的时候，当几天蘑菇，能够消除我们很多不切实际的幻想，让我们更加接近现实，看问题也更加实际。一个组织，一般对新进的人员都是一视同
仁，从起薪到工作都不会有大的差别。无论你是多么优秀的人才，在刚开始的时候，都只能从最简单的事情做起，蘑菇的经历，对于成长中的年轻人来说，
就象蚕茧，是羽化前必须经历的一步。所以，如何高效率地走过生命的这一段，从中尽可能汲取经验，成熟起来，并树立良好的值得信赖的个人形象，是
每个刚入社会的年轻人必须面对的课题。
　　
　　　　10、奥卡姆剃刀定律
　　　　12世纪，英国奥卡姆的威廉主张唯名论，只承认确实存在的东西，认为那些空洞无物的普遍性概念都是无用的累赘，应当被无情地剃除。他主张
如无必要，勿增实体。这就是常说的奥卡姆剃刀。这把剃刀曾使很多人感到威胁，被认为是异端邪说，威廉本人也因此受到迫害。然而，并未损害这把刀
的锋利，相反，经过数百年的岁月，奥卡姆剃刀已被历史磨得越来越快，并早已超载原来狭窄的领域，而具有广泛、丰富、深刻的意义。　　奥卡姆剃刀
定律在企业管理中可进一步演化为简单与复杂定律：把事情变复杂很简单，把事情变简单很复杂。这个定律要求，我们在处理事情时，要把握事情的主要
实质，把握主流，解决最根本的问题，尤其要顺应自然，不要把事情人为地复杂化，这样才能把事情处理好。

歪说软件工程18 - 小精灵的意见 - [原创]
话说《指环王》里的弗罗多说：“不要征求小精灵的意见，因为它们将会既说Yes又说No”。
商业软件产品的许多用户有时也是既说Yes又说No，或者说既要那个又要这个。
先换个领域，倘若一个生产猪饲料的，猪显然不知道自己想吃什么该吃什么，即使是养猪的也未必都知道或能科学地知道，所以厂商有责任研制有
效的饲料产品，即告诉养猪的你的猪吃这些饲料就可以了。
软件产品用户虽然作为人是有积极主动性的，但大多数时候确实是不知道自己要的是什么的，所以作为厂商，应该是特定商业领域的专家，有责任并
有义务研发有效的软件产品。因为有长期的积累，所以不信口开河，因为有大量用户的验证，所以确实有效果。
不征求小精灵的意见，是因为有能力告诉它们可以这样，而它们大多数认为这样确实可以。

歪说软件工程17 - 横过深渊的一根绳子 - [原创]
话说尼采认为“人之所以伟大乃是他是一个桥梁，而不是一个目标”。尽管这座“桥梁”如“横过深渊的一根绳子”，“渡过是危险的，在路上是危险的，
回顾是危险的，在中途战栗和踌躇是危险的”，但人却必须越过它。
软件产品即使把周期拉长，也很难断定它是一个桥梁还是一个目标，但确实不管前进、还是后退、还是踌躇也都是危险的。
比如CRT显示器，几年前还几乎都是弧面的，没有平面的，而现在几乎没有人买弧面显示器甚至有人都知道什么是弧面显示器了。两种显示器，从基本
需求的角度来说，都能满足显示的需求，但竞争总是使更先进的功能变成常态，竞争导致优胜劣汰。
软件产品如果前进而没走对，可能危及即得的地位，而如果不前进或者后退就容易被竞争对手找茬，所以不管速度如何还是要前进，为了避免前进的
风险，我们求助于软件工程的一些过程管理方法。

歪说软件工程16 - 现场直剥 - [原创]
话说老Y住处楼下就是一个自由市场，好几次听到一个卖柚子的在吆喝：“梁平柚子，一元一个，现场直剥……”。“现场直剥”的意思是买了之后现场直接给
你剥开。
语言可以这样用吗，妙哉！随意摘录一句古文：“夫玄黄色杂，方圆体分，日月叠璧，以垂丽天之象；山川焕绮，以铺理地之形……”（刘勰，《文心雕龙》）。
真不知道这些辞藻是怎么被堆砌起来的，奇哉！
发明汉字的仓颉看到这些，估计也会问道：“汉字可以这么用吗？”。软件产品用户多了，有时收到用户的反馈，说怎么怎么操作后出了什么问题，程序员
心里想：“这个软件居然可以这么用？”
如果用户说了怎么操作，那要解决问题比较好办，如果用户没说，只说出的问题，就麻烦了。软件中有很多隐藏的假设，比如假设用户会这样操作、假设
用户这个地方会输什么内容，一旦这些隐藏的假设被“不守规矩”的用户触碰到，就可能导致问题。
但软件总不可能把什么都考虑到，就如仓颉不能限制卖柚子的也玩汉字谐音，程序员在软件没加约束时也不能限制用户不能那么操作，所以为了避免出问
题，解决方法之一就加尽可能多需要的功能约束，之二就是遵循“契约编程”的道理，在每个方法、每个函数做约束，以便出问题时能知道问题所在。
简单的方法是可以这样：由于每个方法、每个函数对传入的参数都会有一些假定，可以把已知的假定直接写成代码约束，比如用Assert来要求某某参数
不能为空，同时给出违反约束时的提示。

歪说软件工程15 - 超人鲁班 - [原创]

话说一个工地上，许多人在忙着修一座拱桥，其中一个老头，每天不紧不忙地凿着一块石头，凿得方不方、圆不圆、长不长、扁不扁，大家都以为别人认识他
，都没理他，他凿好后就扬长而去。桥快要竣工时，桥面中间出现了一个空隙，怎么努力也弄不来一个合适的石头，有人想起那个陌生老头凿的石头，把它
搬来，结果严丝合缝。那个老头就是鲁班。
古代的拱桥都不太长，鲁班不画工程图也能把它修好，但如果请他来修旧金山金门大桥，估计他也得先学好几何学和力学。软件工程也有很多学问，下文摘
抄Martin Fowler在《企业应用架构模式》中的一段话：
“即使你对极限编程[Beck XP]不感兴趣，你还是应该认真地思考三个方面的技术实践：持续集成[Flower CI]、测试驱动的开发[Back TDD]和重构
[Fowler Refactoring]。这些技术虽然不是万能的灵丹妙药，但它们能够帮助你在需要的时候更容易地改变你的系统。除非你比迄今为止我见过的人
更能干或更走运。”

歪说软件工程14 - 李宇春 - [原创]
话说李宇春成名后代言的广告不少，可以被轻轻地总结一下。
老Y所知的大概有三种：食品、手机、电脑，第一种显然是消耗品，手机基本上也已经成为消耗品，商业社会的魔力就是能把技术转化为商品并以时尚
的名义销售，消费者既消费实用又消费时尚，但产品会在购买后一年后价值降低到原来的一半或更低，电脑也是这样，所以也可以说是消耗品。
老Y一朋友，家里做批发生意，98年开始用管家婆软件，用到现在没做升级，当然店面和店员也没什么变化。许多商品软件都是耐用品，当然消耗品的
也多，比如售价<1000元的各种游戏，许多人买了用不久就会去买新的，而购买售价>1000元的商业软件大多数消费者还是很慎重的，因为使用后如需
更换还要付出额外的成本。
作为耐用品的商业软件，其广告代言人，从各种广告可以看出，大都选择老成持重的。

歪说软件工程13 - 树 - [原创]
    摘要：话说山上的树长得高低不齐，高大的树都有高大的主干，如果是千年老树，则主干更尤庞大；许多低矮的灌木则到处都是枝桠，看
    不出哪儿是主干。 软件的生长理应如能长高的树，而不是低矮灌木。树木从地底下长出来，先只有一片叶，一小枝，而后成两片叶，枝
    叶自己生长的同时，主干也不断生长。 而许多软件都生长成低矮灌木，因为主干没有生长，即生长的过程中没有不断积累并形成自己的技术基础。    （全文共205字）——点击此处阅读全文

歪说软件工程12 - 浪漫的事 - [原创]
话说IBM向开放源码社区贡献了一个Java集成开发环境“Eclipse”，这个原来没没什么名气的IDE，现在已经成为一统Java开发工具江山的开放平台，
IBM收购的Rational商业开发工具体系已经全部迁移到Eclipse中，Borland的Java开发工具体系也在逐渐迁移，做Java的Sun原来也做有自己的IDE，
现在基本上放弃自己做了。
“Eclipse”是日蚀的意思，不过这个项目现在确实有遮住“太阳”(Sun)光辉的趋势。中国人想象“月蚀”是天狗把月亮吃了，这是一件很浪漫的事情，
开放源码也是一件很浪漫的事情，“天下为公，各尽所能，各取所需”，不过，开发的东西要能确实可用、实用，而不只是一种玩具，却一点也不浪漫，
同样要一行行代码地编写，一行行代码地测试。
Eclipse的所有源代码都可以在其网站上下载到，下面是3.1版本一些不完全统计数据：
　  开发目录 708M；
　　目录个数 1.4万；
　　文件个数 5.2万；
　  Java源程序文件个数 3.5万，共199M，代码行数592万；
　　其中JUnit测试代码文件个数 1.3万，共40M，代码行数119万；
　  文档 *.htm 个数 0.36万，共45.9M；
　　文档*.ppt; *.doc; *.swf 个数 33个，共17.4M。

歪说软件工程11 - 池鱼 - [原创]
话说小池塘里只养了一种鱼，冬去春来，春来冬去，鱼儿不停地生殖繁衍，看着一群群小鱼儿长大，然后又会有新的一群，但尽管没有人捕捞，
鱼儿从来没有把小池塘填满过。
鱼妈妈会一边生小鱼，一边把自己的小孩吃掉。简单的自然生态自己维护着自己的平衡。
软件市场也是一个自然生态系统，微软再大，它也不会吃掉所有市场，自己长满整个池塘。

歪说软件工程10 - 红绿灯 - [原创]
话说比较早的时候街上的红绿灯很简单，一个方向红的时候一个方向绿，每隔60秒交替变化。这时用简单的定时模拟电路控制就可以了，而且
通过电阻电容的调整也能调整变化间隔。
后来觉得这样很不人性化，用户界面不好，让行人干等不好，应该加一个数字计时器，显示还剩下的需要等待秒数。这时用模拟电路的架构就不行了，
必须用数字电路，需求变化第一次导致架构变化。
许多路口，由于两个方向的流量不一样，导致需要两个方向的灯亮的时间不一样，比如一个90秒，一个30秒，这时要求红绿灯能进行设置。对数字电
路架构添加这种功能不是很难。
再后来，由于许多路口的流量变化很大，要求红绿灯能智能控制，于是安装了摄像头监控流量，与红绿灯一起跟监控中心联网……，就是所谓的智能交通。
需求总是变化的，其中许多是由竞争对手而不是用户驱动的；许多需求导致产品架构变化，代价通常是很大的。

歪说软件工程9 - 比基尼 - [原创]
    摘要：话说老Y从乡下来到迷人的夏威夷海滩，看到满眼的比基尼泳装，甚是不习惯，心里想到：“比基尼展示了令人感兴趣的部分，但却隐藏了关
    键的部分”。 许多竞争对手的产品在它们的技术白皮书中展示了许多技术特性，许多业界领先的观念得到了怎么样的贯彻与实现，甚是诱人，具体
    研究，有些果然如此，但不知道它是怎么做的，当然，这些就是被隐藏的关键，只有努力深入研究才能搞清楚。   

歪说软件工程8 - 鲨鱼与天蚕 - [原创]
话说海里的鲨鱼可以闻到1公里之外的血腥；陆上的雄天蚕能够感知到4公里外正在求偶的天蚕雄蛾的存在。
离圣诞还有很多天，街上已经布满圣诞的味道，到处可见圣诞小屋和圣诞树。几十天后的圣诞商机是固定，似乎不需要去预测，但软件行业变化多端，
1年以后的商机已经很难预测，更不用说多年以后。
听闻大公司为了保持竞争力，而投入研发力量现在做未来的预测产品，许多东西做出来时可能没有意义，但等有意义时，哪怕只有1％的产品是成功的，
它也能因为遥遥领先对手而占尽先机。

歪说软件工程7 - 安静的迪吧 - [原创]
    摘要：话说老Y在震耳欲聋的迪吧中与群魔乱舞，他突然停止下来，在声音震动的浪涛之中，突然感受到一种宁静，于是在旁边坐下来，开始静
    静底地享受，好像自己与整个世界都已沉寂下来。 人都是因冷才知热，因热才知冷。老Y喜欢技术，时常把自己置身技术的不同领域，感受到
    许许多多的嘈杂，同时也在宁静中明白。 不论过程整体的RUP、XP、UML，还是架构和编码的OO、SOA、AOP、IOC，都是为了解决一个问题，
    即分工合作的问题，即不同的部门、不同的人、不同的代码，都能尽可能把自己擅长的事情做好，而不需要太多地管别人是怎么做的，但又能
    低成本地实现有效的沟通与合作，自己已经做好的事情别人不需要重新做。   

歪说软件工程6 - 思想生产力 - [原创]
话说丫丫生物公司发明了一种稻谷种子，既适合在水田播种、又适合在旱地播种，而且不怕任何病虫害、产量远高于已有产品，所以一段时间后全球都种
这种稻谷了，但缺德的是，这种稻谷种子是做了技术处理断子绝孙的，收割后的稻谷不能用于做种子，所以都只能不断地从这个公司购买种子，所以它已
富可敌球。
当然，这是没有发生的可能。但，垄断“种子”销售的商业模式早已成熟，具体到信息产业就是有各种卖“标准”的公司，这些公司在商业价值链的顶端，对
标准有独占的权力，其它人要用都要获得授权。
“标准”通常伴随着某种概念，概念是思想的产物，在软硬件行业，一个有价值的概念通常都能迅速地转化为商品，不管是芯片还是软件还是书籍。比如我
们耳熟能详的“B2B”、“UML”、“中间件”、“极限编程”等等，都已经是某种产业链的基础。
基本上没有中国人原创的能成为生产力的概念，许多东西等中国人明白过来，别人已经赚了很大一把了，不过也有努力跟进也很赚钱的，比如金蝶的中间
件、阿里巴巴的B2B。
可能中国人太忙了，没有时间思想。在思想能够迅即转化为生产力的社会，谁占据先机谁就将处于商业生态圈食物链的顶端。

歪说软件工程5 - “小燕子”性感写真 - [原创]
    摘要：话说昨晚当地八卦电视台八卦节目播出一则消息，瞪着两只白痴空洞的牛眼到处晃荡曾经看似清纯可爱的“小燕子现在长大了，也拍起了写真集，
    穿着性感内衣，把白花花的皮肤展示给大众。不管她展示的是内衣还是自己，给大众展示性感的目的是达到了。 这不能说是进步或者随大流，只是
    自然的成长，作为一个演艺公共人物，取悦大众是她要做的工作，毕竟大众的审美取向是多样的，朴素可爱可以取悦一部分人，性感迷人也许可以取
    悦更多的人。 作为软件工程产品的软件其所有功能最终通过软件界面为用户所用，如果一个软件刚开始一直坚持朴素的界面风格，后来也开始表现
    得或性感或妖艳，这也不能说是错误或者退步，只是自然的成长，毕竟软件是给用户用的，尤其是用户多的大众软件，用户对软件的认可许多时候也
    依赖于用户对软件界面的直观感受和审美取向。   

歪说软件工程4 - 光彩守护员 - [原创]
话说老Y每天上班都路过一座大桥，注意到桥上总有工作人员值班，起初都以为是守桥的，但想想也不对，如果是守桥的应该是荷枪实弹的武警才对，
后来有一天看到工作人员穿了一个马甲，背后有几个字“光彩守护员”。
这年头可能不怕阶级敌人炸桥，就怕小偷小摸偷装扮桥的许多价值不菲的灯具，小偷拆不走桥，拆灯具则容易。不管是怎样，修一座大桥，能创造一些
职业甚至行业是事实。
软件工程经过多年发展也创造了许多职业甚至行业。比如专业软件工程咨询师，以及咨询公司，专业测试员，以及专业搞测试外包的公司，都有活得
上好的。这个世界变化快，如果总以己之见度人，容易范坐井观天的错。

歪说软件工程3 - 成人纸尿布 - [原创]
    摘要：话说杨利伟乘神州5号上天时不能用马桶，是用的类似成人纸尿布的设备。 小孩带尿布是因为撒尿是不自觉的，但大人用尿布，对于没有
    经过特殊训练的普通人来说，不知道会是什么样的感觉，估计会很不爽快。 软件工程中也经常有“使用纸尿布”的行为。有时因为软件发布期限
    所限，只能采用一个临时的解决方案把需要解决的问题解决，由不得程序员用更多时间去实施更爽快的解决方案；程序员有时会因为暂时想不出
    更好的方法而采用临时的解决方案；或者确实因为水平所限，只能采用别人会觉得很不痛快的解决方案。 这些都没什么，都很正常。最不爽的
    是，当更痛快的解决方案可以用时，仍然由于种种原因——比如懒得用、或不敢用、或习惯了用老方法等等——而继续保持“使用纸尿布”。   

歪说软件工程2 - “SoSo”主义 - [原创]
话说小两口A婚后财务由老婆打理，老婆每天给老公10元零花钱，并且经常询问老公花钱的情况。这种叫“精细管理”；
小两口B，老婆每个月给老公300元零花钱，并告诉老公可以随便花，但规定花完就没有了。这种叫“粗放管理”；
小两口C，老婆把自己和老公的工资一起全部放到一个抽屉里，大家都可以随便取、随便花，当然花完就没有了，没花完的做为积蓄。这种叫“信任管理”；
软件工程中的管理模式也大抵超不出以上三种或其组合。
英文中有个词叫“SoSo”，福建方言中有个词发音类似“Shǎo Shào”的词，意思都是“马马虎虎”，即“tiger-tiger-horse-horse”。中国人有四种：
新加坡人、香港人、台湾人、大陆人，大陆人大都喜欢“马马虎虎”，或者说许多时候都只能马马虎虎、难得糊涂，或者说大都是“SoSo”主义者。
软件工程却希望做到像上文所述第一种的“精细管理”，这时就会与大陆人的“SoSo”主义冲突，故大陆软件公司搞软件工程成功很困难。
但是，其实“SoSo”主义是“和谐社会”的基础。

歪说软件工程1 - 科学沦为艺术 - [原创]
    摘要：话说某大学生美眉在妓院找了一个操作电脑的工作，以后她要不沦为妓女，要不总被认为是妓女。
     当软件工程作为科学遭遇实践，它要不沦为艺术，要不总被认为是艺术。 科学与艺术的相同在于都是人生产的；
     科学与艺术的区别在于，科学操纵人，而人操纵艺术。 当软件工程不是去操纵人，而是由人来操纵，结果就是软件工程还是管理的艺术。
     当科学沦为艺术或被认为是艺术，要不该怎么样就怎么样，要不原来怎么样以后还怎么样。  

如何让所有的涉众目标一致
1，文档：
因为一个工程，所有的涉众不是同时介入的。这就导致了
对于工程的认识就不同。而要帮助后加入的成员很快的进入角色，
就必须有提纲性的文档作为引导。并且所有的描述语言都是所能够
领会的，比如uml就是一个很好的选择。
2，授课：
严肃的说不是授课，而是交流经验。广开言论，而后达成共识。
3，明确的核心骨架和规范
高层业务用例，高层测试用例，核心类构成，主要流程。这些都决定了
系统的主脉络。

如何让团队成员保持激情
1，阶段性的成果
   让每个员工感受到阶段性的成果，是大家心血的结晶，而且是大家
   辛苦努力的结果。不是停留于语言上，而是让每个人真切的感受到
   确实是这样。并且对结果都是有十足的信心。
2，挑战性的工作
   在单调的工作中，寻找挑战性，寻找亮点。让每个人在团队中体现出
   个性，让每个人感受到她是不可获缺的。
3，时刻的进步
   对每个成员进行合理的规划，在工作的同时，提高每个人在自己领域的进步
   尽可能的和她的职业规划一致。时刻感受到她在进步。
4，实时的支持和鼓励
   风险和困难到处都是，此时，要有强有力的支持和鼓励以及帮助。要尽可能的
   寻找资源来帮助她，而不是将压力全部推给她。
5，成果的喜悦和物质的关怀
   我们成果了，职业生涯画了很好的一笔，精神享受的同时，将大家的打车费，加班费
   ，奖金等立刻兑现。走 去high吧 哥们。

如何让团队有凝聚力和自由的交流空间
1，成果分享
   在体现个人价值的同时，成果是大家分享的。当然 给予分享的人，她的个人魅力的提升就是一种收获。
   将这种价值观贯穿整个团队。鼓励大家分享。
2，有个安静的交流环境和小黑板
   如果有coffe更好不过。这里是灵感的来源地，解决问题的天堂。
3，有价值的培训和交流
   不说为项目做准备，就是提高个人能力和交流彼此思想。此时我们抛开目前的项目。

猪!你的鼻子有两个孔,感冒时的你还挂着鼻涕牛牛.
猪!你有着黑漆漆的眼,望呀望呀望也看不到边.
猪!你的耳朵是那么大,呼扇呼扇也听不到我在骂你傻.
猪!你的尾巴是卷又卷,原来跑跑跳跳还离不开它
哦~~~

猪头猪脑猪身猪尾(yi)巴
从来不挑食的乖娃娃
每天睡到日晒三杆后
从不刷牙从不打架

猪!你的肚子是那么鼓,一看就知道受不了生活的苦
猪!你的皮肤是那么白,上辈子一定投在那富贵人家
哦~~~

传说你的祖先有八钉耙,算命先生说他命中犯桃花
见到漂亮姑娘就嘻嘻哈哈
不会脸红不会害怕

猪头猪脑猪身猪尾(yi)巴
从来不挑食的乖娃娃
每天睡到日晒三杆后
从不刷牙从不打架哦~~~
传说你的祖先有八钉耙,算命先生说他命中犯桃花
见到漂亮姑娘就嘻嘻哈哈
不会脸红不会害怕
你很象她

泡馍---老刘家泡馍（北广济街内）
　　水盆羊肉----老白家（北广济街内）、老李家（方新村路东农行南边）
　　小炒----西羊市中段的“天下第一碗”；
　　杂羔汤----（建设西路旅馆村内）
　　烤肉----里木烤肉（麻家十子西50米）
　　肉夹馍----秦豫肉夹馍（柏树林南口）
　　孜然炒肉夹馍----（洒金桥十子东南角）
　　腊牛肉夹馍---- 北梢门红码头老旦隔壁“李老四夹馍”，他家的杂肝汤也不错
　　水盆大肉----老宋家（柏树林十子西南角）
　　葫芦头----铁蛋葫芦头（柏树林十子西北角）
　　蒸碗----（建西街东口向西100米路南）
　　煎饼----顶顶香煎饼屋（龙首村十子向南50米路西）
　　酱大骨头---骨头庄（吉祥村十子向东100米路北）
　　麻辣粉----牵人（粉巷）
　　火锅----竹园 （和平路）
　　蒜蘸面----绿蚂蚁对面
　　牛肉面----马虎面（西七路）
　　腊汁肉揪面片----建设西路西头路南第一家
　　羊肉面----建设西路西头路南“陕北老二面庄”
　　高新的老王面
　　小雁塔门口的羊肉面
　　建国路的梆梆面
　　尚勤路的歧山面
　　长乐路的牛肉拉面
　　高新路北段“一诺面庄”的秦香面
　　麻辣鱼----建国路中段路西“安平麻辣鱼”
　　麻辣烫-----七星椒（周家围墙）
　　火锅-----小天鹅（南二环）
　　牛肉面----一分利（鼓楼）
　　沙锅----穆萨 （大皮院 ）
　　烤肉----（桥子口往西400米）
　　炒海瓜子————胖嫂（东新街夜市，最近检查12点以后出摊）
　　米线----玄风桥“红油米线”
　　马厂子的〔大盘鸡〕
　　兴庆路东隆的楼下〔今日平价酒楼〕的炒菜不错，
　　西大街桥梓口车站路南小巷里有一家〔卤汁凉粉〕
　　大雁塔正面的路东有一家〔肉夹馍〕和〔丸子汤〕
　　长乐西路轻工东半公里〔秦百年〕火锅－－要吃蹄花的
　　交大北沙坡里有一个，〔九龙海天大酒楼〕（刚开的分店在纬十街西北角），夜市上有一个〔重庆嫩江鱼〕，小巷里有一家四种麻辣
　　南二环“川渝人家”的菜也不错。
　　粉带（2块）。黄甫庄口有一家〔卤汁鸡〕（5角）
　　西五路西段路南第一个小巷进去有一个〔塘坝鱼大排档〕（20元）
　　建设路东口路南（三二三医院东邻）〔塘坝鱼〕
　　东门里南〔渭南时晨包子〕
　　南稍门永宁村里有一家〔烤羊肉〕，现割现秤现穿现卖现烤现吃
　　北郊自强路有一家烤羊排
　　原东郊三厂旁边有一家“囊坑肉”，也属羊排一种（此店已搬家，待我侦察后再通知）
　　东新街————牛肉丸子烩菜，好吃量也足，只出夜市，隔个几天就要去吃一回，味道地道
　　北郊 龙首南路里“东利沙锅 ”
　　而且最好吃的是最便宜的三鲜沙锅
　　柳巷口的牛肉面，最近已经般到端履门
　　劳动南路啊，老机场里面有一家跳水鱼，非常好吃的
　　西北大学北门，西侧的红焖王（红焖羊肉非常棒）
　　北广济街的泡馍是老米家。
　　
　　东郊韩森寨经二路北口李老四牛肉夹馍，
　　南郊吉祥村十字社科院对面老蒲城风味小吃，里面的八宝辣子和老豆腐很好。
　　小肥羊的火锅羊肉鲜美（最近听说他们为了保鲜在肉里放了对人体有害的防腐剂）可以缓缓再吃
　　海底捞服务态度一流
　　南二环添一顺味道不错，价格相对有点高
　　老成都 喜欢吃辣的朋友可以常去坐坐
　　东来顺也不错
　　文豪杂粮食府去一次，感受感受看看就行了，自己吃饭千万不要去
　　西厢子庙街有一个“大清花”饺子馆，饺子不错，菜也不错，满族人开的，老板很会做生意，去吃过几次，真的很不错。
　　最便宜、好吃的海鲜在边家村十子南100米---大通渔港
    新民街的通济中坊发现一家冒菜（虞记），

餐馆名                        口味      环境     服务       人均消费                
1.  贾三灌汤包子         20           6            9                ￥15                
2. 樊记腊汁肉店          26           9            11              ￥ 8                  
3. 海底捞火锅城          22           16          30              ￥ 35                
4.竹园村火锅               24           18          16              ￥ 44                
5. 红红酸菜炒米          21           8            9                ￥ 11                
6. 同盛祥                      18           13          9                ￥ 27                 
7.老孙家饭庄                17           9             7                ￥ 33                
8 西安饭庄                     20           19           15              ￥ 61                
9永明岐山面                 22           16           14              ￥ 12                
10. 小六汤包                 20           14           13              ￥ 15               
11. 德发长饺子             13           13           10              ￥ 45               
12.牵人麻辣粉              25           10           12              ￥ 7                 
13.春发生饭店             24            16          14               ￥ 25                
14. 小苏塘坝鱼            19             9            11              ￥ 27            
15. 御品轩面包店        27           16           17              ￥ 13              
16 老孙家中国西部民 18           15            13             ￥ 38               
17. 大香港鲍翅酒楼    24            24            24              ￥ 134             
18. 老兰家烤肉             20            8                9              ￥ 17              
19.雅泰来                      12            12             12             ￥ 33              
20.必胜客                      16             18            17             ￥ 56              
21.千家粗粮王               7              7               8               ￥ 21               
22. 坊上人清真饭庄      21            17             14              ￥ 36               
23. 平娃烤肉店              15            4               4                ￥ 18               
24. 高飞比萨                 18            22            16               ￥ 44              
25.  春发生泡馍馆        16           11              8               ￥ 25               
26. 好利来蛋糕世界      12            13             11             ￥ 19                
27. 国力仁和川菜           26           19             18               ￥ 56               
28. 萨拉伯尔                   18             26             22             ￥ 127             
29. 川渝人家                   16             15            12             ￥  64                  
30. 上海人家                   13             18             17             ￥ 72              
31. 文豪杂粮食府            17            20              15             ￥ 51              
32. 东来顺饭庄                 25           1 7             15            ￥ 45                
33. 好伦哥                         7              15              8             ￥ 39                  
34. 东东包                         12             7               7               ￥ 10                 
35. 朱军鱼庄                    17             7                 8             ￥ 33                
36. 清真老金家水盆羊肉  17            9               0              ￥ 34                 
37. 德克士炸鸡                  6              7               8              ￥ 25                   
38. 粤珍轩海鲜酒楼         16            22             19             ￥ 61                  
39. 江海肥牛大酒店                                                                                    
40. 秦朝瓦罐                      14           12             12              ￥ 53                 
41. 金汉斯南美烧烤    
42. 老味家饭                       20           16             13             ￥ 35                  
43. 豪牛士烤肉                   7             11              11            ￥ 58                  
44. 元太祖     
45. 郭老大大盘鸡               13            6               8               ￥ 30                  
46. 海云台                          12             19             16              ￥ 45                  
47. 老树咖啡                      4                1 3            13              ￥ 30                  
48. 桥梓口贾永信              18              6               6                ￥ 20                     
49. 永和豆浆     
50. 安旗    
51. 荣歌红焖王餐庄            19             12              14              ￥34               
52. 程记米线店    
53. 毛公湘菜馆                    18              10             11               ￥46                  
54. 捷尔泰凉皮    
55. 肯尼罗杰斯餐厅             2                13              10              ￥ 41              
56. 回坊人家    
57. 三皇三家     
58. 米旗蛋糕     
59. 奥斯汀西餐酒廊    
60. 无名食屋     
61. 明都回转寿司                  2               6                  8                ￥ 46                
62. 惠里     
63. 谭鱼头火锅     
64. 清真老四烤肉    
65. 解放路饺子馆               14                11               10                 ￥ 40              
66. 云南过桥米线酒楼     2
67. 西安烤鸭店                   17                14                11                 ￥ 49             
68. 苏浙汇酒店                   18                20                20                   ￥ 51           
69. 永丰歧山面                   17                6                  10                  ￥ 12            
70. 高山青    
71. 秦豫肉夹馍    
72. 小唐人自助    
73. 小肥羊火锅    
74. 麦当劳    
75. 顶顶香煎饼屋    
76. 郭老六大盘鸡    
77. 阿瓦山寨    
78. 爱特糕饼曼维咖啡店    
79. 蛐蛐火锅    
80. 格兰明珠     
81. 野玫瑰大酒店     
82. 新闻大厦美食城    
83. 艺园餐厅    
84. 酷啦啦     
85. 名典咖啡语茶    
86. 吉林农家饭庄    
87. 阿林鲍鱼    
88. 一诺面庄   
89. 常宁宫休闲山庄    
90. 黄鹤楼金花饭店    
91. 安德坊    
92. 民生大酒店食村     
93. 桃李村饭店    
94. 罗胖大排档    
95. 唐乐宫                          9                    19                       23              ￥145  
96. 全聚德烤鸭店   
97. 国花酒家老店    
98. 紫荆花大酒店    
99. 崔记biangbiang面馆    
100. 一分利面庄   

import java.io.*;
import java.util.*;
import java.util.zip.ZipOutputStream;
import java.util.zip.ZipEntry;
import java.util.zip.ZipFile;

public class FileMgr {
  public FileMgr() {
  }
 /**
   * 压缩文件
   * @param srcfile File[]  需要压缩的文件列表
   * @param zipfile File    压缩后的文件
   */
  public static void ZipFiles(java.io.File[] srcfile, java.io.File zipfile) {
    byte[] buf = new byte[1024];
    try {
      // Create the ZIP file
      ZipOutputStream out = new ZipOutputStream(new FileOutputStream(zipfile));
      // Compress the files
      for (int i = 0; i < srcfile.length; i++) {
        FileInputStream in = new FileInputStream(srcfile[i]);
        // Add ZIP entry to output stream.
        out.putNextEntry(new ZipEntry(srcfile[i].getName()));
        // Transfer bytes from the file to the ZIP file
        int len;
        while ( (len = in.read(buf)) > 0) {
          out.write(buf, 0, len);
        }
        // Complete the entry
        out.closeEntry();
        in.close();
      }
      // Complete the ZIP file
      out.close();
    }
    catch (IOException e) {
      e.printStackTrace();
    }
  }

  /**
   * 解压缩
   * @param zipfile File 需要解压缩的文件
   * @param descDir String  解压后的目标目录
   */
  public static void UnZipFiles(java.io.File zipfile, String descDir) {
    try {
      // Open the ZIP file
      ZipFile zf = new ZipFile(zipfile);
      for (Enumeration entries = zf.entries(); entries.hasMoreElements(); ) {
        // Get the entry name
        ZipEntry entry = ( (ZipEntry) entries.nextElement());
        String zipEntryName = entry.getName();
        InputStream in = zf.getInputStream(entry);
       // System.out.println(zipEntryName);
        OutputStream out = new FileOutputStream(descDir + zipEntryName);
        byte[] buf1 = new byte[1024];
        int len;
        while ( (len = in.read(buf1)) > 0) {
          out.write(buf1, 0, len);
        }
        // Close the file and stream
        in.close();
        out.close();
      }
    }
    catch (IOException e) {
      e.printStackTrace();
    }
  }

}

作为中国最底层的程序员，我苦 我乐 。
让他人去疯狂的压榨吧，让自以为是的pm,sa们继续他们自以为
的美梦和想象吧
有句话是 孤芳自赏 也许他们就是
我在默默无闻的为中国的软件事业出力
我从来都是那头勤种的耕牛
我问心无愧
无愧于我的朋友和我心爱的每个人（包括你）

曾经的我也是驰骋于
腥风血雨
曾经的我带领我的兄弟们
踩平一个个project
没有华丽的辞藻
只有好用的软件
结交了很多朋友
培养了诸多se

虽然有sa的本本
我却一直拿自己当
－－－－－－－－程序员
现在 将来
我将永远的和
兄弟们
同食野菜
共享富贵
我
就是一个牛一样的程序员

我有很多的好朋友
我和老婆过着幸福的
掉渣的生活
我将有个可爱的孩子
我的亲人目前还都健康幸福
我很知足 上苍给我的
惜福 惜福 惜福

构架浅析

李宝剑 libaojian@sina.com

   从广义方面来理解构架，在自然世界中到处都是。作为一个好的构架概念最终会形成模式。这里笔者仅从软件工程的领域将自己的一些浅薄认识进行分析整理，以求获取通用的可控制其风险的构架模式。

   从静态视角分析，构架涉及了公司，部门，团队，涉众等。从动态视角分析，构架涉及了产品创造过程以及围绕此过程发生的各种事件。从软件技术的视角分析，构架涉及了需求，设计，程序，用例等。不同视角看到不同的构架，这些构架彼此相互联系，相互制约。

   对于一个构架的组成，我暂称其为元素，元素会有关系，关系包括了控制，协作，支持等。

   从以上分析，你的头脑里应该会有一个模糊的构架view展现。

   我们的目标是借助诸多构架支持完成某些构架的实现，在这个过程中，会发生一些阻碍事情进展的情况。那好，事情就变的有目的了，我们的目的就是解决这些阻碍，对症下药，尽大可能的解决这些问题，权衡利弊，使最终的利益最大化。

   构架可抽取，可形成模式，而具体到一个项目构架模式就变成了构架实例，有了动作动态这个元素来打破了构架的一些常规。作为项目的控制者需要合理的处理和控制常规的可预见的风险和突发的风险。在不同的场景中，构架中的元素所担任的角色就不同，其属性和行为也会动态的进行变化。例如你在公司构架下是一个员工，在部门构架下是一个设计师，在项目构架中是一个设计组长，在涉众中是一名设计人员，在过程中是一名团队成员，在需求构架中是一个需求的翻译者，在设计构架中你就是大师，等等。

   分析抽取了初始的构架模型如下

   下面我将根据初始的构架模型，进行具体的项目分析。我将从目前的项目进行此项目架构以及支持和约束此项目架构的其他架构的分析，找出仅可能多的问题和解决方案，形成一定的模式，避免重蹈覆辙。

   项目背景

       公司近期在电子政务方面，会面临大量的政务信息的交互。 在此背景下，开发代号为ABC的数据交换平台。因为某研究所已经有若干成熟的设计，将和此研究所合作进行开发。公司派3，4人进驻研究所， 同研究所的研究生团队组成新的团队，共同开发。

   构架列表

n         公司构架（公司领导 政务部门领导  开发领导）

n         团队构架（公司监督 项目指导 项目管理 技术管理 公司员工 研究所学生）

n         研究所构架（导师 学生（博士研究生 硕士研究生））

n         涉众构架（公司 研究所 用户）

n         项目构架（高层用例构架 组成人员）

n         需求构架（用例架构）

n         设计构架（系统架构）

n         实现构架（类架构）

n         过程构架（周期，里程碑）

n         技术构架

   总体构架关系

下面一排都是外部约束和支持项目构架的若干构架。上面一排是项目过程中内部所要协调的构架。下面就支持架构的目标和责任以及未能达到目标的状况进行分析。

公司构架

    公司对于此项目的责任应该是约束，监督，支持。从目前的状况来看，项目组所感受的的只是约束和监督，未能明显的感觉支持。对于监督的力度不够也就是过程的监督仅停留于常规的周报等纸面内容，掩盖了事实的真相。

问题

就是监督不力，不予支持。结果是上下信息不畅，项目进展困难。这种严重的等级信息传递，造成了链条式的信息沟通，因为某一个环节的缺失，就会造成监督盲区和支持盲区。

参考模式

解决方案

从公司对于此项目的构架组成包括了五级，董事长，副总，政务部总，政务部开发负责，政务部项目监督员。那问题显然出在政务部总和政务部开发负责这个点（元素）上。解决问题将从此深入。借用我党常用的什么下乡活动的策略，并且支持鼓励员工的合理建议，广开言论。

研究所构架

    研究所的目的不言而预，教学为主，培养学生目的很明显。对于项目的进展做出了很大的努力，而问题也随着进展暴露的越来越突出。优势，人力多。

问题

1，  经验不足

2，  流动性大

3，  责任心不足

4，  需花费培养成本

解决方案

    传 帮 带 ，这就要求团队组成的格局需要按照这种方式进行重新规划。将比较优秀的团队成员作为产品组的领军。人才浪费也是一个缺憾，未能人尽其用。通过一段时间的观察和磨合，仔细分析每个组员的特点，进行团队合理的人员分配。真正的实现1＋1》3。

团队构架

    不管是从传统的软件过程来讲还是从rup的项目管理过程分析。团队的组成缺失很大，也很不科学。一句话：一哄而上。

 问题

1.       项目管理者位置、职权不突出，没有独立的协调、组织、调配权力；

2.       团队组成人员结构不合理，往往不能按照科学的职能需要配置项目开发人员；

3.       团队中职能交错混乱，管理模式不确定，存在严重的职能重叠浪费和缺失不齐的矛盾现象；

4.       团队精神不明确，项目目标不一致。

解决方案

   在公司构架的基础上，明确项目管理者的地位和作用；按照类比或经验的管理模式，组建所需要的研发人员团队，明确团队精神和唯一奋斗目标.。

涉众构架

    没有用户的参与。涉众不完全。听不到不同的意见（或者不同的意见仅局限于内部），会形成一叶障目。

 问题

解决方案

    作好充分的项目前期调研，广泛收集用户（或业主）信息，建立项目用户跟踪回访制度，最好由原软件开发负责人牵头。

需求构架

    需求来源太狭小。

 问题

    导致产品规划不太合理，盲目的靠近什么红头文件。连技术细节都盲目靠近。

解决方案

    从其他的政务系统入手，结合其他的类似产品，进行产品规划和需求获取。

设计构架

    概要设计阶段因为产品族的规划不到位，造成了某些概念不统一。详细设计阶段问题依旧，并且对于整体感未能有人把握。

 问题

1.       设计目标不明确，设计范围模糊，造成设计概念含混不清；

2.       设计阶段划分不清，设计深度很难把握。

3.       设计成果的校核、审查、确定系统不健全，没有准确的把关人员。

解决方案

   明确设计阶段，提前作好设计沟通协调工作，给定项目设计内容，设立专人设计组，健全设计成果的审查把关系统。

技术构架

    技术风险

 问题

    无总体感

解决方案

    架构师，在那里。如果没有合适人选，就要从团队中培养。

实现构架

    类结构比较合理，但是因为总体无人驾驭，可能造成百花齐放。

 问题

    许多公用类未尽其用，并且对于程序中效能都是没有把握。

解决方案

    代码框架的确定和培训。

过程构架

    过程中的缺憾主要是周期和里程校验，以及过程中的审查。

 问题

    不及时 力度不够

解决方案

    项目管理方面的资料很多，我这里就不罗索了。

如果你有一千个苹果，有十个箱子，那么现在我要把一千个苹果放进十个箱子里面，
放了完之后，不管谁跟我要多少苹果（包括1000以内的哟），我都可以整箱整箱给
他，这个问题有解吗？

我的思路。
我从1开始推理的。如果你需要1个，必然有1个箱子装一个。
需要两个，要么给一个箱子装2个，要么再装一个的箱子。感觉
还是装2个为一箱比较好。那么需要3个时候，就1＋2了，那么你需要4个怎么办。
是装一个4个呢，还是装一个或者2个呢。为了省箱子，我装4个。
此时，我发现了规律，1，2，4。那么下一个是8，再下去就是16了，接着32。
。。。。。。。
如果有100个，到32的时候，下一个就是64了，总数超过100了。思路改为
100－（1＋2＋4＋8＋16＋32）＝37。最后一个箱子装37个。
当要求的苹果数在1＋2＋4＋8＋16＋32＝63 和100之间的时候，将算法推诿
给前面即可。就是先拿37个，剩下的从以前的箱子拼凑。
至此，推理完毕。

java实现代码


/**
 * <p>Title: </p>
 * <p>Description: </p>
 * <p>Copyright: Copyright (c) 2005</p>
 * <p>Company: </p>
 * @author not attributable
 * @version 1.0
 */

public class Box {
  private int limit;
  private int code;
  private int applenum;

  public Box(int code,int applenum,int limit) {
     this.limit = limit;
     this.code  = code;
     this.applenum = applenum;

  }
  public int getApplenum() {
    return applenum;
  }
  public int getCode() {
    return code;
  }
  public int getLimit() {
    return limit;
  }
  public void setLimit(int limit) {
    this.limit = limit;
  }
  public void setCode(int code) {
    this.code = code;
  }
  public void setApplenum(int applenum) {
    this.applenum = applenum;
  }

}

/**
 * <p>Title: </p>
 * <p>Description: </p>
 * <p>Copyright: Copyright (c) 2005</p>
 * <p>Company: </p>
 * @author not attributable
 * @version 1.0
 */

public class Apple {
  public Apple() {
  }
  final private int max=100;   // 苹果总数
  static int   xqs = 99;       // 你需要的苹果数
  private java.util.Vector Boxvec = new java.util.Vector(); // 箱子和箱子里的苹果
  private int ai =0;
  private int k = 1;
  public static void main(String args[])
  {
    Apple apple = new Apple();
    apple.InBox(1);
    System.out.println("共需装"+apple.GetBoxVec().size()+"箱");
    for (int i=0;i<apple.GetBoxVec().size();i++)
    {
      Box box = (Box)apple.GetBoxVec().get(i);
      System.out.println("第 ‘"+box.getCode()+"’ 箱装'"+box.getApplenum()+"' ");
    }
    apple.GetApple(xqs,apple.GetBoxVec());
  }

  public void GetApple(int x,java.util.Vector vec)
  {
    if (x==1)
    {
     System.out.println("拿第一箱玩去，就1个");
    }
    else
    {
      if (x != 0) {
        int key = 0;
        for (int i = 0; i < vec.size() - 1; i++) {
          Box xbox = (Box) vec.get(i);
          Box ybox = (Box) vec.get(i + 1);
          if (x > xbox.getLimit() && x <= ybox.getLimit()) {
            key = i + 2;
            System.out.println("拿第" + ybox.getCode() + "箱给他，共" +
                               ybox.getApplenum() + "个");
            GetApple(x - ybox.getApplenum(), vec);
          }
        }
      }
      else
        System.out.println("完成");
    }

  }

  public void InBox(int i)
  {
    if ((i+i)>=max)
    {
      Box box = new Box(k,max-ai,max);
      Boxvec.add(box);
    }
    else
    {
      Box box = new Box(k,i,i+ai);
      k++;
      Boxvec.add(box);
      ai = ai + i;
      InBox(i+i);
    }
  }
  public java.util.Vector GetBoxVec()
  {
    return Boxvec;
  }

}