用 Safari 11+、Firefox 70+ 浏览效果最佳
我的文章 我的评论 我的书评 我的知乎*
书单 书讯 书评
需求知识体系 特性 用例 统一用例方法 用户故事 需求工具
业务建模 UML OOD
敏捷知识体系 敏捷方法 敏捷问答 敏捷工具 敏捷评论 敏捷资源
业务模式 需求模式 架构模式 设计模式 大道至简:实话设计模式 Web 应用架构模式
.NET Java JS 笔记
Amazon* ITPub* Martin Fowler* 教程
需求分析需求模型非功能需求业务需求分析
SpringJSF
> 读书 > 书评 > > 读书 > 书评 >
在线/81 登录/0

软件架构:组织原则与模式

阅读数:20.8K
基本原版影印版中文版

[ref]软件架构师 50% 的工作是沟通,20% 是做计划,剩下的才是技术。—— Philippe Kruchten, IBM Rational Fellow 软件项目、产品乃至企业的成功都源于成功的组织文化!—— 张恂,独立软件工程顾问[/ref] 2002 年出于好奇心,我尝试翻译了一本名叫《软件架构:组织原则与模式》的书,终于尝到了翻译的滋味:译好一本书真的很难! [h2new]内容简介[/h2new] 本书主要描述软件架构与软件组织之间的相互关系,依次介绍了作者根据多年管理经验和研究总结出的软件架构组织的 VRAPS 5 项原则 —— 构想(Vision)、节奏(Rhythm)、预见(Anticipation)、协作( Partnering)和简化(Simplification),并通过案例分析、模式和反模式展示了如何运用这一模型。本书的主要读者为软件企业的管理人员、开发人员和软件产品的客户等,也可作为大学计算机专业的本科生、研究生和教师的参考用书。
[url=http://www.china-pub.com/computers/common/Catalog.asp?IDD=7547&type=6]前言[/url] [url=http://www.china-pub.com/computers/common/Catalog.asp?IDD=7547&type=1]目录[/url]
[sub2=寄语 /] David M. Dikel 我想把这一成果献给我的妻子 Margaret 和孩子 Aaron、Ilana,父母 Joyce Quintana 与 Samuel S. Dikel(已故),以及我的导师 Satguru Sivaya Subramuniyaswami。我深深地感激 Margaret 给予我的鼓励,以及她作为一位编辑和音乐专家所作出的重要贡献,还要感谢 Aaron 和 Ilana,他们根据我的写作进度调整了自己的工作,以使我们能一起度过珍贵的时光。 David Kane 把这本书献给 Jordi,感谢她在整个创作过程中给予我的鼓励和耐心。我还想把这本书献给我的父母 Bill 和 Diane,是他们帮助我找到了自己的道路。 James R. Wilson 此书献给我杰出的妻子 Carolyn A. Wilson 博士,以及我的孩子们 Nathaniel 和 Avery。他们关注、支持了这次跨越了几个夏天和许多周末的写作历程,而这些时间原本应属于曲棍球、公园漫步以及其他重要的家庭娱乐。Care,Nate,Avery —— 谢谢你,是你们托起了我生命中的翅膀。 [sub2=致谢 /] 在此我们要感谢许多个人和组织,没有他们的帮助此书是不可能完成的。 下列人士作为顾问和合作者协助我们明确了研究目标的范围,定义了研究规程,开发了 VRAPS 模型并且评估了研究结果。我们向 Bill Loftus 和 Steve Ornburn 表达特别的谢意。作为我们的研究合作伙伴,他们的见识、想法和创新对我们的工作产生了深远的影响。 Jeremy Allaire, David Chao, Ron Grace J.J. Allaire, Francios Coallier, Kuan-Tse Huang Robert M. Beckman(已故), Patricia Cornwell, Bill Loftus Grady Booch, John den Otter, Ruth Malan Babara Bowers, Glenn Dillard, Joe Maranzano David Bristow, John Foreman, Jean Mayrand Linda Brown, John Garman, Susan Mohrman Marcia Carlyn, Connie Gersick, Geoffrey Moore Lynn-Robert Carter, Ramses Girgis, Jim Moore Robert Charette, Tom Goodall, Burgess Oliver Steve Ornburn, Bill Saunders, George C. Wilson Mike Pait, Bob Savely, Jim Withey Rick Peebles, Simeon Simeonov, Smith T. Wood Stan Rifkin, Mike Sonneman, John Woodfin 我们也非常感谢下列模式社群中的专家以合著者、顾问或指导的身份使我们了解了模式,形成了我们的初始成果: Brad Appleton, Neil Harrison, Don Olson Mike Beedle, Christy Hermanson, Bill Opdyke Charles Crowley, Raphael Malveaux, Linda Rising David Delano, Tom Mowbray 以下个人通过评价 VRAPS 原则和相关模式,参加研究或提供关于本书的反馈,帮助我们完成了这项工作: John Artim, Terry James, Tim Niesen Glen Adams, Ralph Johnson, Bill Opdyke Steve Berczuk, Mary Kane, Eric Price Adam Berrey, Tony Kram, Bob Rizzo Dana Breedemeyer, Susan Lilly, Ralph Roland Ben Cantlon, Mike Lombardi, Adam Satcowitz Steve Cichinski, Doug Lowe, Jordana Schmier David Coyle, John Jund, Michael Smith Gitika Dalla, Brian Lyons, Ken Song Karen DeChino, Raphael Malveaux, Patrick Steranka Martine Devos, Priya Marsonia, George Stern Margaret Dikel, Charles McKay, Charles Teague Steve Drucker, Jim Moore, Carol Terry Steven Fraser, Tom Mowbray, Sarah Tilman Steven Green, April Morris, Kim Walker-Borst Neil Harrison, Sadhunathan Nadesan, Dave Watts 除了以上人员外,我们还要感谢下列资助或参与了构成本书基础的案例研究和基准工作的组织机构及其业务部门: Allaire Corporation Andersen Consulting AT&T Bell Canada Defense Advanced Research Projects Agency (DARPA) Defense Information Systems Agency (DISA) Electronic Data Systems Hewlett-Packard Lucent Technologies National Aeronautics and Space Administration (NASA) Nortel Networks PECO Energy Texas Instruments U.S. Air Force Reuse Center U.S. Air Force Space and Warning Systems Center U.S. Army Communications-Electronic Command U.S. Navy Air Warfare Center U.S. Navy Surface Warfare Center 最后,我们同样要感谢 Prentice Hall 公司的主办人员和积极支持者,包括高级编辑 Paul Petralia 及其同事 Justin Somma、Ann Trump Daniels、Jeffrey Pepper 和 Judith Brief,以及高级技术评审 Jeff Barr 和 Linda Rising。我们也感谢我们目前所在公司 SRA 国际和 Cyberserv 给予的鼓励与支持。 我们得益于多年来在写作此书的旅程中所经历的各种富有成效的商务、职业和知识关系。希望该成果对软件工程的实践是一项有价值的贡献。在撰写此书的过程中,我们每个人也都逐步成长为架构师、工程师、主管和高级经理,对拥有这些良机我们深感荣幸。 与其它制造业一样,软件的生产也需要一流的生产设备、流水线和高素质的生产者与管理者;而作为高度智慧与知识的结晶,软件的生产又有着其独有的内在规律。

跨入 21 世纪,蓬勃发展的中国民族软件业正面临着前所未有的机遇和挑战。虽然在龙头企业的带领下中国软件业短短几年之内获得了长足进步,实力大增,但是国内软件产业的整体发展水平与美国、欧洲、印度等国家和地区相比仍明显落后,尤其在生产方式、过程控制、组织管理等领域差距更大。多年以来,与其它成熟行业如建筑、制造业相比,国内的软件生产和项目开发一直缺乏有效的工程化管理。

究其原因,译者认为根源在于不健全、不规范的市场环境造成软件产业链的资源分布不均衡。在急功近利、片面追求效益的行业风气影响下,国内软件工程的教育、技术和管理水平严重滞后并与软件生产实践相脱节,导致民族软件业长期在低水平上徘徊。与国外高度发达的软件工业化生产相比,我们的软件生产企业大部分还停留在手工作坊时代。这一瓶颈问题如不能得到根本解决,无疑将严重制约民族软件业健康和持续地发展。

可喜的是,近两年来,许多软件企业和有识之士逐步认识到掌握软件生产规律、提升软件工程管理水平的重要性与迫切性。软件架构( Architecture )和框架( Framework )、 CMM 、统一软件过程( Unified Software Process )、 UML 、软件模式( Pattern )与反模式( Antipattern )、构件式开发( Component-Based Development )等先进的软件工程理论和方法开始被接受,其普及与应用正方兴未艾。在落后了国外 3-5 年甚至更长时间之后,人们终于意识到原来还可以这样做软件。

译者从事面向对象技术和软件工程咨询与管理工作多年,有幸接触了各类规模的软件生产企业,也结识了不少业界朋友。译者在与他们的交流切磋中了解到,中国软件企业面临的主要内部问题是管理问题,而不是技术问题,其关键是当代先进的软件生产技术如何与现代化的企业管理方法有机结合,这已经成为很多人的共识。

Ivar Jacobson 大师在其里程碑著作《软件重用》( Software Reuse ) [Jacobson97] 中指出,影响软件产品或项目成败的主要因素包括架构、过程和组织三个方面。其中,软件架构是决定软件产品内在质量的核心因素,合理的开发过程与高效的组织管理则是软件架构乃至软件产品、产品线成功的重要保障。

本书中所说的软件架构及其组织原则的适用范围既包括单一产品架构,也包括产品家族或产品线上多个产品共享的架构;这里所谓的 “ 组织 ” 既包括一个项目组也包括一个部门、一个企业甚至有多个合作伙伴的联盟。本书的原则无论对于国内只做工程项目或单一产品的企业,还是拥有一个或多个产品线的组织都有指导或借鉴意义。

同样以架构为中心,《软件重用》提出了面向重用的软件工程业务( RSEB )的概念,而本书则重点介绍与软件架构互动的组织管理原则,笔墨侧重于技术和人文管理的结合部分,译者认为这是此书的一大特色。

在国内我们一般只听说过程序员、高级程序员、系统分析员的认证考试,但很少听说软件架构师这样一个非常重要却易被人忽视的岗位。本书恰恰是专为软件架构师和软件企业的管理者(如高层经理、技术总监、产品经理、事业部经理、部门经理和项目经理等)写的,适合的读者还包括各类开发人员(实施者)、软件产品的客户等。

本书结构严谨,依次介绍了作者依据多年管理实践和研究经验总结出的软件架构组织的 VRAPS 5 项原则(模型),即构想( Vision )、节奏( Rhythm )、预见( Anticipation )、协作( Partnering )与简化( Simplification )。针对每项原则,每个主要章节都讨论了度量准则( criteria )与指导实施的模式和反模式。

本书的价值在于体现了组织管理原则与软件生产技术的有机结合,用高度概括的 VRAPS 5 项原则(含 15 个衡量准则)、 16 种模式和 17 种反模式的形式,把宝贵的软件架构组织管理的真知灼见和经验教训系统地奉献给读者。

软件模式即解决软件领域常见问题的最佳方法,而反模式则是针对特定问题应该避免的错误做法,相应地就有软件分析、设计、实现和管理等各个方面的(反)模式。建立并全面有效地利用好模式知识库,是借鉴国外软件业成熟经验、重用其先进思想方法的一条捷径,可以大大加快提升国内软件企业工程管理和技术水平的过程。不久之前机械工业出版社华章公司曾经推出过一本软件设计模式的经典之作(《设计模式 —— 可复用面向对象软件的基础》, ISBN 7-111-07575-7 ) [Gamma94] ,而本书很可能是国内第一本正式的有关软件管理模式的译著。

本书实例丰富,尤其详细分析了美国 Allaire 公司(其 ColdFusion 开发平台在国内有不少用户)、苹果公司、微软公司、著名的电信制造业巨人加拿大 Nortel 公司( Northern Telecom )以及美国国防部课题研究的一些案例。本书还深入阐述了构想、受益人( Stakeholder )、迭代递增式开发( Incremental Iterative Development )等许多国内读者不甚理解的重要概念。相信通过阅读此书,读者一定会加深对这些先进软件工程思想和方法的认识。

原书的三位作者并非业界权威或名流。国内的管理者对于书中所介绍的某些概念和经验教训也许会有似曾相识的感觉,甚至可能认为这 “ 没什么了不起的,平时我们就是这么做的嘛 ” 。但是,能够把这些实践经验系统完整地记录下来并有序地组织成模式,从而将其升华为管理原则和方法论,这种职业精神和创造是难能可贵的。

相信此书的翻译出版,对促进国内软件从业人员掌握现代化软件生产与管理的内在规律和技术大有裨益,一定能引起广泛的共鸣。

非常感谢机械工业出版社华章公司的编辑们向我推荐了这样一本好书,同时也感谢我的家人、同事和朋友们(特别是郭永林和邵荣)给予我一贯的鼓励和支持,能使我顺利地完成这次翻译创作。因时间仓促和水平局限,难免存在一些疏漏和差错,恳请各位读者批评指正。

张恂

2002 年 2 月于上海
张恂 译
Dikel、Kane 和 Wilson 为软件架构师、项目经理、IT 部门经理们写了一本非常有用的书。这不是一本关于软件架构工具和技术的书,而是探讨了因在软件开发中有否重视架构而导致的诸多组织和社会方面的影响。 该书作者围绕一个称为 VRAPS(代表了构想、节奏、预见、协作和简化)的模型(注:这不是一个 UML 模型)来组织他们的想法。针对这些紧密联系的 5 项原则中的每一条原则,作者都运用组织模式(即成功的做法)、反模式(即确实无效的做法)和准则的形式陈述了相应的建议,以帮助实践者衡量实施 VRAPS 模型的效果。 以下是对这 5 项原则的简要概括。 构想 “构想是未来价值到架构约束的映射,通过判断架构的结构与目标明晰、迫切、一致和灵活的程度来衡量。” 建立一个架构的构想可以促进更好地定义架构努力的范围,在内部和外部的受益人之间设定合理的期望水平,还能够帮助早期发现期望不统一,并使通常潜藏的架构知识对其用户可见。 节奏 “节奏是一个架构团体内部以及它与客户和供应者之间反复出现的、可预测的工件交换活动。” 节奏关系到生命周期、其周期和迭代,它们的可见性与可预测性,以及组织如何随时间演进架构,各种各样的构件又如何呈现并集成。节奏涉及时间安排,还包括一次发布的内容及其质量。它要处理受益人之间的同步,还有再评估。 预见 “预见是指建立和实现架构的人员根据变化的技术、竞争和客户需求预测、验证和调整架构的程度。” 什么是架构师最困难的目标?如何在高技术混沌的背景下平衡长期构想与当前需求?如何避免走过量“滴血”的刀刃之下的险恶之路,又如何避免隧道构想?这里你可以发现各个原则如何开始相互影响:例如,一个健康的节奏往往会强化构想的定期复审和再评估。 协作 “协作是指架构受益人保持明确、合作的角色并将其所提供和获得的价值最大化的程度。” 不要什么事都自己做——应该建立内外的合作型组织。要使关键受益人的最终价值而不是局部的发明创造和开发的数量最大化。应该根据 Barry Boehm 等人所倡导的“双赢”(Win-Win)策略,确保在各种受益人之间达成明确和强制性的契约。 简化 “简化是指对所作用的架构和组织环境都进行巧妙的澄清与最小化。” 架构将被持续使用,但使用它是有成本的,因此必须减少架构的复杂度。然而,没有一点冗余,使问题不过于一般化也可能导致过度简化的解决方案。架构师必须理解[u]关键最小需求[/u],并把它们做成架构的核心元素。演进架构的总体业务原由(Business Case)也应保持明确。 [sub2=VRAPS 与 RUP /] 毫无疑问,该书的所有这些原则、准则和(反)模式与我本人在过去 20 年软件开发领域中的亲身体验和所见所闻相吻合。我不禁把该模型与 RUP 进行对比,看看 RUP 指南与 VRAPS 的符合程度。 构想 构想在 RUP 的“软件架构描述文档”中被明确地表述,它必须依赖于整个项目的“构想文档”。在 RUP 细化阶段与架构相关的许多活动都与该构想有关。 节奏 RUP 有三层“速度”。初始开发周期通过细化阶段引入了一个明确的架构焦点。后续的演化周期允许再次经历细化阶段以便演进、细化和简化架构。每个周期都可分解成若干次迭代,它们提供了全组织的同步点,从而聚焦于产品的一次发布,首先导致架构基线的产生,然后演化成一个逐步更为完整、质量不断提升的产品。在每次迭代中,定期建立则同时强化了对价值的专注和具体问题的完结。 协作预见简化大部分在 RUP 的有关构件式开发、架构复审和架构设计的各种活动和指导方针中体现。同样地,这些原则也得到了 RUP 基础的迭代本质的支持,使得这些问题在每个周期中至少有一次被摆上桌面的机会。 总之,我发现《软件架构:组织原则与模式》对于学习和实践 RUP 的人士来说是一本很好的辅助读物。这本书实用易读,强调了开发软件架构的社会性。架构并非只是用 3 个,5 个,或 7 个视图建立正确的 UML 模型——它还涉及到人。 正如我过去常常告诫我所参与的一个航空交通管制项目的架构团队: 一名架构师工作内容的 50% 是沟通 —— 对内与其他团队,客户、供应商以及公司的其他部门沟通; 20% 是做计划; 而剩下的部分才是技术工作。 Philippe Kruchten(前 Rational Unified Process 产品主管) IBM Rational Fellow 原文链接: http://www.therationaledge.com/content/feb_02/r_softarch_pk.jsp
感谢 Trigon 的评论! [ref][url=http://www.cnblogs.com/Trigon/archive/2007/10/04/914268.html,u]Trigon Chatterley:无题国庆(2007-10-4)[/url] ... 无聊归无聊,无聊总得忙些事情。于是,这几天再次拿起《PofEAA》,看的速度大不如前了,一天就只看那么几页,还好,每次看都有点收获。感觉大师的书些的比较严谨,啥主意和想法都凭证据,啥都是都讲究优劣对比、权衡。从这些就可以看出一个人的水平和书的质量,挑书,自然也要挑选这类的书。个人感觉,这类书对我影响最深。 在细看《PofEAA》的同时,还顺便浏览了张询的《软件架构:组织原则与模式》的前面几十页的内容。张询,给我印象最深的是评《UML三大硬伤》,分析问题有深度,是我比较崇拜的人。因为自己对英文比较感冒,自然而然要看这些人翻译的书,心里比较塌实。看了架构和组织的关系,自然想到自己所在的公司。自己感觉这个方面是公司的重病。个人感觉公司的产品很零散,所有产品可以说是堆积起来,而不是架构起来。一个已有11年的企业,既然每次开发都要从头做起,不得不说是一个悲哀。重复开发,人员流动太大等等许多问题都早早暴露出来。我们作为最底层的员工,只能用眼睛看待一切。 ... [/ref] 原文链接:http://blog.csdn.net/xiammy/archive/2007/04/25/1583597.aspx

之所以推荐此书,是这本书让我真正了解什么叫开卷有益!我打开这本书的时候是凌晨,但是我打开的时候,就放弃了睡觉的念头。虽然最后还是困得睡着了,但是第二天一天时间都全新扑在这本书上面。

不过我必须提醒的是,这本书我买下的时候,并没有感觉有多么有用。也就是说,如果你没有这方面的工作经验的话,看这本书会感觉不知所云,或者不能深刻体会作者写作的意图。因此,如果你没有参与架构平台性产品的话,建议你不要轻易选择读这本书。

如果你已经是软件架构师,建议你读一下这本书。如果你在推广技术平台时候遇到困惑,这本书能给你启示。事实上,这本书能够帮助你,让你了解到应该关注技术之外的东西,而且提供了很多处理这类事情的模式和反模式。

但此书并不是一本讲解如何进行软件技术架构的书籍。其提到的模式更不是我们软件设计模式中的类似模式的概念。

此书讲述的是产品线架构上的架构师和高级经理之间的组织原则及处理模式。作者认为:架构师从技术看平台,但是容易忽视组织对架构的影响。而高级经理又很容易被技术表现蒙蔽,忽视架构对组织的影响。而本书,就是希望将两者集合起来,使得双方一起保障架构和组织的成功。

针对此,本书提出了 VRAPS 参考模型。并在每种模型中,提供了一些模式和反模式,使之能与实际应用联系起来。下面简单介绍一下 VRAPS 模型。

1. 构想(Vision),构想描述了架构的为来,提供了架构成功使用的环境和动机。

2. 节奏(Rhythm),节奏原则使得软件架构在跨越组织边界的情况下开发和使用成为可能。

3. 预见(Anticipation),为了使对软件产品线的长期投资能产生回报,组织应能够预见变化并对变化做出反应。

4. 协作(Partnering),协作也是软件架构成功的关键之一,因为这么多不同团体的参与者对架构的开发、实现和使用都是很重要的。

5. 简化(Simplicfication),简化软件架构的原则概念上看似简单,而实践中它要求对价值非常坚定地关注,以及对架构所生存的组织的理解和支持。架构是必须了解架构最小的基本特征。

最后,再次补充一下我推荐这本书的目的。我认为这是作为架构师必须学习的一课。因此在 我的博客中 特意推荐。主要也是向那些和我同样在架构师学习过程中遇到困惑的人共享我的经验。

(感谢小明的推荐!)
2004 年 2 月 16 日

一直以来软件开发团队对技术十分崇拜,但是为何有很多好的技术人员的团队,最终项目还是失败了?探究原因可以说很多很多,过去特别强调了很多管理的原因,可是这些问题是如何引进的,如何解决的,读完了这本书后,也许可以找到答案。

这是一本注重管理和软件技术结合的书,它特别提到了软件架构的概念:一个系统的基础组织。而作为软件组织来说,也是这个基础组织的一部分,而这本书就是从这个角度来阐述软件的开发所应该遵循的基本原则,涉及到需求的架构,设计的架构以及实施的架构等方方面面。这是阅读本书的一个关键。

在软件研发中往往会发现资金、人力和时间不充足,造成软件产品质量往往不尽如人意。而本书通过描述了VRAPS(构想,节奏,预见,协作,简化)模型来说明在软件开发中由于组织原因而带来的各种问题和相应的应对准则,并根据这些准则和模式(反模式)完善相应的软件组织的软件开发过程。但是在阅读这本书时,我影响最为深刻的是这本书所描述的模式(开发中常见问题的解决方法)和反模式(开发中的陷阱),发现在我所知的现实的软件开发中到处有它们的痕迹。由于篇幅有限,以我了解到的在 A6 项目中开发的一些事例来简单的描述 VRAPS 模型的几个模式。

A6 项目是 A 公司开发的一个高端通信设备,A 公司的技术实力具有很强的保证,但是在整个研究开发中还是遇到了很多问题。

A 公司把产品开发完以后,推向市场,客户开始不断要求新增功能,此时产品买的越多,不同的客户所需要新增的功能也越多。开发由于市场的压力,不断地满足客户的各种要求,最终由于公司的人力限制,已经无法生产出质量较高的功能,并且把整个产品的设计架构打乱了,这就是构想原则中所介绍的潮流追随者反模式。当看完这本书后知道了可以利用前端符合模式来使产品朝正确的、新的方向发展。首先要评估产品新增功能给产品的稳定性带来的影响,另外还要评估组织架构是否适合做这个新功能,从成本和质量上进行综合考虑,只有两者均满足条件我们才能做。

同时由于 A 公司是一个新兴的公司,人力资源相对是很重要的,每个技术人员的离开都有可能给项目带来功能实现空缺的严重后果,并且由于项目进度的原因,开发人员没有积累很多技术文档,以致整个项目的一些功能无法完整地开发下去。幸好所做的通讯产品采用了模块化的方式,彼此没有更多的影响,而且是采用命令行的人机界面,可以屏蔽一些功能,但是很多客户需要的功能,由于人力资源方面的原因无法完成。书中提供了一个很好的模式,就是轮转模式,结合帮教制模式阶段性地轮流交换构件开发的所有权。可能很多人的第一反应是这不符合相应的开发组织的状况,可是在实施指南中,这个模式提供了很多很好的建议,比如尊重开发人员的个人发展呈螺旋式上升的要求,这样经过工作的轮转,既保证了他们进入技术专业难度或责任更大的领域,又保证了不因一个员工的离开而造成整个团队的项目无法开展。这特别适合 10 人左右的快速开发团队。

以上是对构想原则的两个模式的理解,解释一下,构想原则就是“未来价值到结构约束的映射,通过判断架构的结构与目标明晰、迫切、一致和灵活的程度来衡量”。

在开发中最重要的三个元素是:速度、内容和质量,而节奏要素就是让三者的效益都发挥出来。

在 A6 项目中,该公司起初把所有的精力都放在认为一定可以打开市场的产品功能上,可是当做好以后推向市场,发现市场真正最需要的并不是这块功能,而是另外一个底层的业务功能。这可能就是接近珠峰反模式,实质是没有把握住内容。书中提出的解决办法是要对团队的节奏进行把握,利用迭代的方式推出不同的新功能抓住市场的机会,如果在实施过程中关键特性打乱了整体开发节奏(比如客户对某个功能需要过于匆忙),可能就是一个危险的信号,如果有产品质量的问题,就需要重新规划。

构想了一个产品,也对产品的开发节奏进行了规划,但是如何能确认整个产品开发是否得以顺利地进行?VRAPS 模型中的预见原则:预测、验证和调整给了一个很好的参考。在实际开发过程中,也可以发现很多类似的模式在现实中发生。A公司在做A6产品的时候,完成了开发以后,投入市场,有很多不同的试用客户需要各种功能,可是他们没有建立一些事先判断的机制,而是仅仅为了眼前的订单,去实现这些功能。结果是用户越多,提出的要求也越多,所需要实现的功能则更多,结果相应的开发人员更为疲劳,产品的架构也慢慢混乱,导致产品的质量开始产生问题。但是如果不按照客户的要求进行开发,很有可能失去订单,如何办?在这本书中我发现遗漏的部分反模式竟然和这种情况是一致的,它提出了一个解决的办法就是评估用户群,和他们一起确定最重要的需求,利用规范的制度确保重要需求不被遗漏,而其中识别最小需求是非常重要的。

现代商业软件作为一个由人制作的复杂产品,主要依靠许多人的智力来共同完成,而人和人之间如何协作才能更好地完成一个任务是个关键。过去我们常自嘲道:“一个中国人是条龙,三个中国人是条虫”。软件工程正是特别强调协作的重要性, 因此 VRAPS 模型也把协作作为软件开发管理模型的一个主要方面。很多国内的软件项目经理容易忽视这些行为和管理方式方法上的问题,毕竟很多人是从技术起家。在开发中,时常也会遇到很多协作方面的问题, VRAPS 模型的很多模式就像影子一样在我眼前展现。比如个人时间这个反模式,A 公司在开发的时候也遇到过。两个产品使用同一套软件,其中 A6 产品在测试中发现了问题,开发人员应进行纠错和修改,但是两个产品经理事先没有进行沟通,结果就可能产生两种情况:1)开发人员对此毫不在意,谁也不愿去修改,因为开发人员认为他/她可能浪费了额外的时间;2)开发人员擅自去修改,但是事后没有做记录,结果一旦出现了问题让人无法定位错误。在日常开发中,开发人员的工作往往是很忙碌的,无法去考虑的更多。于是,就产生了个人时间反模式。针对这个问题,书中提出了两个方面的措施,一是制定计划奖励工作人员在这方面的工作贡献,另外就是强调了良好的组织纪律和判断力,也就是说在按照原有流程走的同时,两个产品的开发机制对同一共享模块应该有个共同的质量判断标准和问题解决办法。

小时候读书时,老师经常说“读书应先从薄读到厚,再从厚读到薄”,做软件也是这样的一个过程。在 VRAPS 模型中最后一个原则就是简化,而在开发过程中的确时刻会遇到把事情做到很复杂的情况。以 A6 产品为例,一开始开发了很多特性,但是推向市场后发现很多东西客户并不需要,而客户需要的却提供的并不全,结果把很多开发的时间浪费在做不必要的事情上,这就是榕树反模式说描述的一种现象。对于这个反模式的解决方案就是做一个最小的架构特性功能集合,把它们区分优先级进行发布,以符合市场的实际状况。

VRAPS 模型本身有一套自己的判断准则(准则下有不同的模式和反模式进行补充验证)和框架。总体上,我认为构想决定了产品的一个原型也就是需求,而节奏指明了开发是需要一定的时间点的,我们不能老是贪图快,预见是在开发产品的计划上对问题和风险的预测,协作是指我们要利用好团队的沟通机制去开发产品,简化就是说我们开发产品的时候要尽量从最小化开始慢慢添加,慢慢细化和丰富。

总之,VRAPS 模型是指导开发软件架构的一些原则和方式方法,它比起其他的参考模型来可能具有更好的实用性和可操作性,因为它是通过分析和观察实践中的问题及其解决方法,而归纳得到的一般软件开发组织都应该遵循的一些基本准则。我们在建立、完善软件过程的同时也应该参考这些准则。

2002 年 10 月
[ref]“这本书,我买了后,翻了几页,很失望,不像你在前言说得那么好吧?我是看着书名和你的前言才决定买的。我开始以为将软件架构,好像是讲组织结构吧?请原谅我的直言,我挺想和有经验的人探讨一下的。可能我还没读懂。希望能推荐几本书。” [/ref] 你好,首先感谢你对我的信任!你不必后悔失望,这其实是一本非常独特、难得的有价值的书 —— 国内第 1 本有关软件架构和组织模式的译著! 软件架构(Architecture)是一个软件企业的生命线。该书最直接的对象是架构师(Architect)。它讲的是软件架构而不是组织结构。当然,它讲的不是具体采用什么技术(如 J2EE、.Net 或模式)来设计架构,这可能让一些想学具体技术细节的程序员失望。实际上该书讲的是架构设计和开发中的组织原则和组织模式,有时候这些原则比具体的技术还更重要!它告诉架构师、项目经理或产品经理如何带领一个架构团队设计出一个强健可靠、能持久成功的产品线(product line)架构。 这里的“组织”和你所说的“组织结构”的含义是不同的。组织模式不同于分析、设计或实现模式,它是一种“技术管理”模式,意思就是我们在软件开发中,不能仅仅考虑技术因素,还要考虑人、团队和组织的因素以及它们与技术的互动,采取了正确的实践方法,这样才能实现使架构简化、预见性好、目标一致、协作有效和步调统一的目标 —— VRAPS 原则。 为什么国内外许多由技术精英主导的项目最后都失败了呢?很大一部分原因,就是因为他们忽视、忽略了组织方面(人和技术的管理)的因素。该书并不单纯地讲企业管理(如 MBA 课程),也不单纯地讲技术(如开发方法论、语言、平台),它涉及的是技术和人文结合的部分,告诉我们如何在架构开发的过程中避免各种人为因素形成的技术和组织管理上的陷阱。 我建议你先浏览两个附录,了解一下这本书的主要内容 —— 16 个模式、17 个反模式和 15 条准则,然后先看第 8 章,该章从技术和管理结合的角度介绍了 Allaire 公司是如何设计出 ColdFusion 产品线并取得成功的。在我译此书的时候,Allaire 已经并入 Macromedia 公司,而如今 Macromedia 已被 Adobe 公司收购,后两家公司尤其著名,为我们中国程序员所熟知,不用我多说了。 另一个贯穿全书的案例就是通讯网络界著名的 北方电讯公司 (“北电”)。这本书正是来源于 1995 年原作者在美国国防部赞助下对北电的大型软件架构成功经验的调查研究。这不禁令人联想起 80 年代末 - 90 年代初美国军方软件企业对软件过程的调查研究,其经验总结的成果就是 —— CMM。过程、架构、组织 是软件企业成功的 3 个最主要方面。VRAPS 模型对于软件架构的指导意义可能并不亚于 CMM 对软件过程改进的重要作用。事实上,在很多情况下,掌握并实施一些简单的原则和成熟的实践方法,要比大规模实施 CMM 有效得多。 有人说,这本书只适合研究人员和学者看。错了!恰恰相反,这是一本非常实用的工具书和企业工作指南,讲的全是从实践得来(通过正规的数据收集、分析)的正反面经验,完全不是理论说教,该书收录的大量模式、实践方法(practice)和准则应该是每一个软件开发者、管理者都可以借鉴的。从该书可以看出,国外早已对组织模式、软件架构、产品线、软件重用及相关领域研究、实践得非常深入了,而且取得了丰硕的成果,而对这些领域的了解、认识、掌握和应用,国内产业界似乎才刚刚开始! 从这个意义上说,该书比《人月神话》、《人件》等名著具有更高的实践指导价值,因为 10 年、20 年之后,人们早已经不仅仅停留在对一些现象、规律和观点的分析评述,而是在这些先进思想和理论的指引下从事了多年大量的实践,取得了丰富的经验和教训,并且针对许多问题提炼、总结出了大量切实有效的解决方案(Solutions —— 实践方法和模式)。认真学习并掌握好这些原则和模式,是实现个人和企业跨越式发展的有效捷径!该书的引进和出版,恰好符合培养软件企业所企盼的技术和管理结合的全面复合型人才、形成良好的软件企业开发文化的目标。 软件开发是一项社会活动,而目前国内很多程序员,包括一些企业的高层管理者,都误认为软件开发只要技术强就可以搞定。所以,除了软件架构师、设计师之外,该书也非常适合希望进一步提升自己的“技术管理”水平和综合素质,有朝一日成为软件架构师、软件设计师的初级程序员,以及软件项目经理和 IT 高级主管们阅读。 相信在软件企业中从事过 1-2 年以上软件开发的人,也会像我一样,对书中大量的案例产生似曾相识、幡然醒悟的感觉。其实我们一直都不知道自己天天在犯着同样的错误!我当初也觉得这本书不起眼,直到读了第 2 遍,才逐渐发现它的特殊价值和意义。读此书的感觉就像含着橄榄,越嚼越有味道。希望你能静下心来,细细品味,相信你一定会对这次的选择感到高兴。 如果你希望了解具体的架构开发技术,Chinapub(互动出版网)上的许多软件架构系列图书很不错。在这里欢迎各位感兴趣的读者和网友一起参与讨论,提出宝贵意见!
[ref]"本书的三位作者做了一项很好的工作 —— 强调了软件架构师工作的双重性:同时处理社会和技术两个方面的复杂性。通过娴熟地运用模式和反模式来组织建议,他们把架构师的技术性工作与其周围易产生破坏作用的社会问题关联了起来。" —— Alistair Cockburn, Humans and Technology,畅销书《Surviving Object-Oriented Project》的作者 “Dikel、Kane 和 Wilson 的这部著作,对于希望改进软件产品开发的实施人员以及负责管理复杂软件工程活动的高级经理们而言,是一本出色的工具书和指南。” —— Jeff Barr,Vertex Development 总裁[/ref] 除非你理解软件架构将如何与你的组织互动,并且知道应采取哪些措施,否则即便是最合理的软件架构也会很快瓦解,或导致更多令人不快的意外。 无论对软件架构师、软件工程师还是 IT 高级经理,本书独特的以解决方法为重点的写作方法都是极有价值的。 跨越价值链、产品线或企业以实现和管理软件架构的任务可能异常困难。本书首次提供了关于建立实现当前和未来最迫切目标的软件架构的完整指南。本书介绍了: 如何建立经理、管理人员和开发人员信赖的一个产品线架构框架和构想; 如何实现能够预见、预测到变更并易于适应新业务需求的软件架构; 如何处理促进或破坏企业级软件架构的组织问题。 本书作者,一个优秀架构师的团队,将向您说明如何设计出敏捷的、富有长久生命力的软件架构。本书突破性地提出了针对软件架构的 VRAPS 模型(构想、节奏、预见、协作和简化),并通过真实案例分析、模式与反模式展示了如何运用这一模型。 [sub2=关于作者 /] DAVID M. DIKEL SRA 国际公司高级专家,致力于大型软件架构的设计和管理。 DAVID KANE SRA 国际公司技术部主任,专业从事 Web 应用和软件架构方面的工作。 JAMES R. WILSON Cyberserv 公司 CTO,负责管理软件产品线架构和 Web 应用。 [sub2=第 2 章 /] 图 2-2:左下角的“产品客户”应为“构件提供者”。 图 2-6:“挑远”应为“挑选”。 [sub2=第 4 章 /] 图 4-7:“从而获得显著进”后缺“展”字。 4.3.2 节第一句:开头去掉“展”字。 图 4-10:“短期”应为“短路”。 P.61:第 3 行右部“新建代码导致立”应为“新代码导致建立”。 [sub2=第 5 章 /] P.74:“原理”部分第 3 行左部“早期用户可就能”应为“早期用户可能就”。 [sub2=第 6 章 /] P.97:倒数第 5 行“更加有学的作用”应为“更加有效的作用”。 图 6-13:ALEX 和 DIANE 下的标记应为“上一个项目的同事”;“上同一农教堂”应为“上同一所教堂”。 [sub2=第 7 章 /] P.118:第 2 段“公元前 1200 年”应为“公元 1200 年”;“[VanHecden00]”应为“[VanHelden00]”。 P.121:第 5 段左部从“更识别和去除克隆”中去掉“更”字。 P.125:“相关反模式与模式”的右部“防榕树反模式”应为“防治榕树反模式”。 P.129:7.3.3 节第 2 段第 1 句“要有一个监控控架构”应为“要有一个人监控架构”;倒数第 3 段左部“无法适全当前的架构”应为“无法适合当前的架构”,“工作量太太了”应为“工作量太大了”。 P.130:第 2 段“导致更大的风经”应为“导致更大的风险”;“没有之间现”应为“没有实现”;“用户会新自接手架的维护”应为“用户会亲自接手架构的维护”;“相关反模式与模式”中“(模式的最好方式)”应为“模式的最好方式”(去掉一对括号)。 [sub2=第 8 章 /] P.140:倒数第 4 行“几个若干”应为“若干”。 [sub2=第 9 章 /] 图 9-1:第 3 步应为“确定数据采集方法并收集数据”。 [sub2=附录 B /] 第 1 句:“如此的一种统一”应为“如此统一”。 第 4 行左部:应为“不投入时间或资源来简化”。 P.173 中部:从“了解你的受益人:积极听取协作他们的意见”中去掉“协作”。 Cofessions of a Sofware Architect (Bowman)

Software Architecture: Organizational Principles and Patterns (Dikel, Kane, Wilson)

Software Architect Bootcamp (Malveau, Mowbray)

Architecting with RM-ODP (Putman)

Design of Sofware Architecture (Scheer)

Software Architecture: An Introduction to the Profession (Sewell, Sewell)

<帮助> <添加新评论> <全部评论> 共 3 个主题 3 条评论 (VRAPSBook)
(1) Amazon 上关于 VRAPS 的书评 3
(张恂 743 字 0 回复 C2007-5-11 10:05:13 LID:3)
(2) Amazon 上关于 VRAPS 的书评 2
(张恂 1440 字 0 回复 C2007-5-11 10:03:25 LID:2)
(3) Amazon 上关于 VRAPS 的书评 1
(张恂 1668 字 0 回复 E2007-5-11 10:04:25 LID:1)

首页 | 使用指南 | 站点地图 | 版权声明 | 联系方法 | © 2005-2020 张恂 版权所有. 沪ICP备15017521号-2