这书是“开源”的,全书的英文原稿在这:http://97things.oreilly.com/wiki/index.php/97_Things_Every_Software_Architect_Should_Know_-_The_Book 软件架构师是IT 行业里独一无二的职业,既要精通软件开发技术,又要掌握业务知识,还要周旋于公司不同部门之间,协调各种予盾。做到这些绝非易事, 博文视点 即将翻译出版的新书《软件架构师应该知道的97 件事》(97 Things Every Software Architect Should Know )探讨的就是这个主题。 本书的编辑Richard Monson-Haefel 是畅销书《 Enterprise JavaBeans 》和《 Java 消息服务 》的作者。Richard 邀请五十多位杰出的软件架构师分享工作经验和观点,帮助读者少走弯路。其中不乏大家熟悉的名字: 《 卓有成效的程序员 》的作者Neal Ford,《 企业集成模式 》的作者Gregor Hohpe, Servlets 和JSP 专家组和W3C RDF工作组技术专家Bill de hÓra, 《 Web 应用程序快速开发 : 使用TurboGears 》的作者Mark Ramm,《 Release It! 》的作者Michael Nygard,《 软件开发沉思录》的作者之一Rebecca Parsons 博士,活跃于Perl 社区的女架构师Allison Randal ,《 Java SOA Cookbook 》的作者 Eben Hewitt , 等等。 下面内容摘自该书的标题,并给出了必要的补充说明, 由本书译者SeanBV(他的CSDN博客)整理,推荐给大家。 1. 客户需求重于个人简历 ( Nitin Borwankar ) 客户需求至上。为了自己的简历更炫而采用新技术是沽名钓誉,往往事与愿违。 2. 简化根本复杂性 ,消除偶发复杂性 ( Neal Ford ) 分析问题好比拨云见月、水落石出。 3. 关键问题可能不是出在技术上 ( Mark Ramm ) 团队同心,其利断金。 4. 以沟通为中心,坚持简明清晰的表达方式和开明的领导风格 ( Mark Richards ) 沟通应当言简意赅、详略得当,别拖泥 带水。 5. 架构决定性能 ( Randy Stafford ) 种瓜得瓜,种豆得豆,架构设计也是一 样道理。 6. 分析客户需求背后的意义 ( Einar Landre ) 抽丝剥茧,洞见症结。不要被表面需求 迷惑。 7. 起立发言 ( Udi Dahan ) 起立发言效果更好。 8. 故障终究会发生 ( Michael Nygard ) 应该提前设计预防措施,限制故障。 9. 我们常常忽略了自己在谈判 ( Michael Nygard ) 工程师应该适时转换角色,学习谈判的 技巧。 10.量化需求 ( Keith Braithwaite ) 没有规矩,不成方圆。 11.一行代码比五百行架构说明更有价值 ( Allison Randal ) 可工作的代码才是目标,设计只是达成 目标手段。 12.不存在放之四海皆准的解决方案 ( Randy Stafford ) 软件世界没有万能钥匙。 13.提前关注性能问题 ( Rebecca Parsons ) 尽早展开性能测试。 14.架构设计要平衡兼顾多方需求 ( Randy Stafford ) 平衡兼顾项目的技术需求和相关各方的业务需求。 15.草率提交任务是不负责任的行为 ( Niclas Nilsson ) 要设法杜绝开发人员草率提交任务的念头。 16.不要在一棵树上吊死 ( Keith Braithwaite ) 为客户提供多样化的解决方案。 17.业务目标至上 ( Dave Muirhead ) 技术决策不能脱离业务目标和现实条件的约束。 18.先确保解决方案简单可用,再考虑通用性和复用性 ( Kevlin Henney ) 19.架构师应该亲历亲为 ( John Davies ) 身先士卒才能赢得同事的信任。 20.持续集成 ( David Bartlett ) 21.避免进度调整失误 ( Norman Carnovale ) 不惜一切代价拒绝调整项目进度的要求。 22.取舍的艺术 ( Mark Richards ) 架构不可能满足所有需求。 23.打造数据库堡垒 ( Dan Chak ) 一开始就要定义好数据模型。 24.重视不确定性 ( Kevlin Henney ) 推迟决策,建设性地利用不确定性。 25.不要轻易放过不起眼的问题 ( Dave Quick ) 别忘了温水煮青蛙的故事。 26.让大家学会复用 ( Jeremy Meyer ) 重复利用已有资源,首先要改变大家的观念。 27.架构里没有大写的“I ” ( Dave Quick ) 变让自己变成自大狂。 28.使用“ 一千英尺高” 的视图 ( Erik Doernenburg ) 选择合适的架构视图。 29.先尝试后决策 ( Erik Doernenburg ) 30.掌握业务领域知识 ( Mark Richards ) 31.程序设计是一种设计 ( Einar Landre ) 软件开发也分成设计和生产两个阶段。 32.让开发人员自己做主 ( Philip Nelson ) 33.时间改变一切 ( Philip Nelson ) 选择值得投入精力的工作,别跟以前的工作过不去。 34.设立软件架构专业为时尚早 ( Barry Hawkins ) 35.控制项目规模 ( Dave Quick ) 36.架构师不是演员,是管家 ( Barry Hawkins ) 别忘了你的工作责任。 37.软件架构的道德责任 ( Michael Nygard ) 架构师的决定会影响许多人,务必慎重。 38.摩天大厦不可伸缩 ( Michael Nygard ) 但软件可以。 39.混合开发的时代已经来临 ( Edward Garson ) 40.性能至上 (Craig Russell ) 41.留意架构图里的空白区域 ( Michael Nygard ) 空白区域“充满”了各种软件和“硬件”。 42.学习软件专业的行话 ( Mark Richards ) 同行之间讲行话方便交流。 43.具体情境决定一切 ( Edward Garson ) 44.侏儒、精灵、巫师和国王 ( Evan Cofsky ) 开发团队不应该同质化。 45.向建筑师学习 ( Keith Braithwaite ) 借鉴建筑行业的经验。 46.避免重复 ( Niclas Nilsson ) 47.欢迎来到现实世界 ( Gregor Hohpe ) 现实世界比软件世界复杂。 48.仔细观察,别试图控制一切 ( Gregor Hohpe ) 49.架构师好比两面神 ( David Bartlett ) 架构师应该像两面神一样,眼观六路、耳听八方。 50.架构师应关注边界和接口 ( Einar Landre ) 寻找自然的边界,分而治之。 51.助力开发团队 ( Timothy High ) 优秀团队是成功的保障,要尽量助力开发团队。 52.记录决策理由 ( Timothy High ) 记录架构决策背后的理由,具有极高的投资回报价值。 53.挑战假设, 尤其是你自己的 ( Timothy High ) 臆断是事情搞砸的主要根源。务必要确保软件基石坚实可靠。 54.分享知识和经验 ( Paul W. Homer ) 帮助周围的人不断改善,他们也会帮助我们发挥出全部的潜力。 55.模式病 ( Chad La Vigne ) 不要让一展设计模式功力的欲望,遮蔽了务实的真知。 56.不要滥用架构隐喻 ( David Ing ) 不要耽溺于系统隐喻之中,反让它拖了后腿。 57.关注应用程序的支持和维护 ( Mncedisi Kasper ) 应用程序的支持和维护,永远都不应该是事后才考虑的事情。 58.有舍才有得 ( Bill de hÓra ) 珍惜需要权衡的时机,远胜毫无约束和限制。 59.原则、公理和类比胜于个人意见和口味 ( Michael Harmer ) 60.从“ 可行走骨架” 开始开发应用 ( Clint Shank ) 从“ 可行走骨架” 开始,增量培育系统成长 。 61.数据是核心( Paul W. Homer ) 从“数据是核心”这个角度去认识系统,能大大降低理解复杂度 。 62.确保简单问题有简单的解 (Chad La Vigne ) 63.架构师首先是开发人员 (Mike Brown ) 碰到麻烦时,架构师可不能只会干吹烟圈却束手无策。 64.根据投资回报率(ROI )进行决策( George Malamidis ) 65.一切软件系统都是遗留系统( Dave Anderson ) 软件很快便会过时,修改维护无可避免。 66.起码要有两个可选解决方案( Timothy High ) 67.理解变化的影响 ( Doug Crawford ) 清楚认识变化类型及其影响。 68.你不能不了解硬件( Kamal Wickramanayake ) 硬件容量规划,是和软件架构同等重要的事情。 69.现在走捷径,将来需付息( Scot Mcphee ) 及时还清技术债务。 70.不要追求“完美”,“足够好”就行( Greg Nyberg ) 避免过度设计。 71.小心“好主意” ( Greg Nyberg ) 72.内容为王 ( Zubin Wadia ) 73.对商业方,架构师要避免愤世嫉俗( Chad La Vigne ) 74.拉伸关键维度,发现设计中的不足( Stephen Jones ) 75.架构师要以自己的编程能力为依托( Mike Brown ) 76.命名要恰如其分( Sam Gardiner ) 弄清楚要做的究竟是什么。 77.稳定的问题可以获得高质量的解决方案( Sam Gardiner ) 78.天道酬勤( Brian Hart ) 真正做好那些看似简单的任务,坚守承诺。 79.对决策负责( Yi Zhou ) 80.弃聪明,求质朴( Eben Hewitt ) 81.精心选择有效技术,绝不轻易抛弃( Chad La Vigne ) 82.客户的客户才是你的客户!( Eben Hewitt ) 83.事物发展总会出人意料 ( Peter Gillard-Moss ) 设计是在不断变化的世界中持续进行探索试验的过程。 84.选择彼此间能和谐共处的框架 ( Eric Hawthorne ) 当心“无所不能”型的框架。 85.着重强调项目的商业价值( Yi Zhou ) 86.不仅仅只控制代码,也要控制数据 ( Chad La Vigne ) 87.偿还技术债务 ( Burkhardt Hufnagel ) 在速度和架构间进行权衡,保持平衡。 88.不要急于求解( Eben Hewitt ) 首先看看是否可以改变问题。 89.打造称手的系统( Keith Braithwaite ) 90.找到并留住富有激情的问题解决者 ( Chad La Vigne ) 91.软件并非真实的存在 ( Chad La Vigne ) 虚拟世界中的软件是柔韧可变的。 92.学习新语言 ( Burkhardt Hufnagel ) 防止沟通不畅和误解 。 没有永不过时的解决方案( Richard Monson-Haefel ) 94.用户接受度问题( Norman Carnovale ) 减轻用户接受度问题带来的风险。 95.清汤的重要启示 ( Eben Hewitt ) 软件架构设计需要不断的精炼浓缩。 96.对最终用户而言,界面就是系统 ( Vinayak Hegde ) 97.优秀软件不是构建出来的,而是培育起来的( Bill de hÓra ) (bvbook) |