软件架构师应该知道的97件事

软件架构师是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 ， 等等。
[align=left] [/align]



[align=left] [/align]
[align=left]下面内容摘自该书的标题，并给出了必要的补充说明， 由本书译者SeanBV（他的CSDN博客）整理，推荐给大家。[/align]
[align=left] [/align]
[align=left]1． 客户需求重于个人简历 （ Nitin Borwankar ）[/align]
[align=left]客户需求至上。为了自己的简历更炫而采用新技术是沽名钓誉，往往事与愿违。[/align]
[align=left] [/align]
[align=left]2． 简化根本复杂性 ，消除偶发复杂性 （ Neal Ford ）[/align]
[align=left]分析问题好比拨云见月、水落石出。[/align]
[align=left] [/align]
[align=left]3． 关键问题可能不是出在技术上 （ Mark Ramm ）[/align]
[align=left]团队同心，其利断金。[/align]
[align=left] [/align]
[align=left]4． 以沟通为中心，坚持简明清晰的表达方式和开明的领导风格 （ Mark Richards ）[/align]
[align=left]沟通应当言简意赅、详略得当，别拖泥 带水。[/align]
[align=left] [/align]
[align=left]5． 架构决定性能 （ Randy Stafford ）[/align]
[align=left]种瓜得瓜，种豆得豆，架构设计也是一 样道理。[/align]
[align=left] [/align]
[align=left]6． 分析客户需求背后的意义 （ Einar Landre ）[/align]
[align=left]抽丝剥茧，洞见症结。不要被表面需求 迷惑。[/align]
[align=left] [/align]
[align=left]7． 起立发言 （ Udi Dahan ）[/align]
[align=left]起立发言效果更好。[/align]
[align=left] [/align]
[align=left]8． 故障终究会发生 （ Michael Nygard ）[/align]
[align=left]应该提前设计预防措施，限制故障。[/align]
[align=left] [/align]
[align=left]9． 我们常常忽略了自己在谈判 （ Michael Nygard ）[/align]
[align=left]工程师应该适时转换角色，学习谈判的 技巧。[/align]
[align=left] [/align]
[align=left]10． 量化需求 （ Keith Braithwaite ）[/align]
[align=left]没有规矩，不成方圆。[/align]
[align=left] [/align]
[align=left]11． 一行代码比五百行架构说明更有价值 （ Allison Randal ）[/align]
[align=left]可工作的代码才是目标，设计只是达成 目标手段。[/align]
[align=left] [/align]
[align=left]12． 不存在放之四海皆准的解决方案 （ Randy Stafford ）[/align]
[align=left]软件世界没有万能钥匙。[/align]
[align=left] [/align]
[align=left]13． 提前关注性能问题 （ Rebecca Parsons ）[/align]
尽早展开性能测试。

[align=left] [/align]
[align=left]14． 架构设计要平衡兼顾多方需求 （ Randy Stafford ）[/align]
平衡兼顾项目的技术需求和相关各方的业务需求。

[align=left] [/align]
[align=left]15． 草率提交任务是不负责任的行为 （ Niclas Nilsson ）[/align]
要设法杜绝开发人员草率提交任务的念头。

[align=left] [/align]
[align=left]16． 不要在一棵树上吊死 （ Keith Braithwaite ）[/align]
为客户提供多样化的解决方案。

[align=left] [/align]
[align=left]17． 业务目标至上 （ Dave Muirhead ）[/align]
技术决策不能脱离业务目标和现实条件的约束。

[align=left] [/align]
[align=left]18． 先确保解决方案简单可用，再考虑通用性和复用性 （ Kevlin Henney ）[/align]
[align=left] [/align]
[align=left]19． 架构师应该亲历亲为 （ John Davies ）[/align]
身先士卒才能赢得同事的信任。

[align=left] [/align]
[align=left]20． 持续集成 （ David Bartlett ）[/align]
[align=left][/align]
[align=left]21． 避免进度调整失误 （ Norman Carnovale ）[/align]
不惜一切代价拒绝调整项目进度的要求。

[align=left] [/align]
[align=left]22． 取舍的艺术 （ Mark Richards ）[/align]
架构不可能满足所有需求。

[align=left] [/align]
[align=left]23． 打造数据库堡垒 （ Dan Chak ）[/align]
一开始就要定义好数据模型。

[align=left] [/align]
[align=left]24． 重视不确定性 （ Kevlin Henney ）[/align]
推迟决策，建设性地利用不确定性。

[align=left] [/align]
[align=left]25． 不要轻易放过不起眼的问题 （ Dave Quick ）[/align]
别忘了温水煮青蛙的故事。

[align=left] [/align]
[align=left]26． 让大家学会复用 （ Jeremy Meyer ）[/align]
重复利用已有资源，首先要改变大家的观念。

[align=left] [/align]
[align=left]27． 架构里没有大写的“I ” （ Dave Quick ）[/align]
变让自己变成自大狂。

[align=left] [/align]
[align=left]28． 使用“ 一千英尺高” 的视图 （ Erik Doernenburg ）[/align]
选择合适的架构视图。

[align=left] [/align]
[align=left]29． 先尝试后决策 （ Erik Doernenburg ）[/align]
[align=left] [/align]
[align=left]30． 掌握业务领域知识 （ Mark Richards ）[/align]
[align=left] [/align]
[align=left]31． 程序设计是一种设计 （ Einar Landre ）[/align]
软件开发也分成设计和生产两个阶段。

[align=left] [/align]
[align=left]32． 让开发人员自己做主 （ Philip Nelson ）[/align]
[align=left][/align]
[align=left]33． 时间改变一切 （ Philip Nelson ）[/align]
选择值得投入精力的工作，别跟以前的工作过不去。

[align=left] [/align]
[align=left]34． 设立软件架构专业为时尚早 （ Barry Hawkins ）[/align]
[align=left][/align]
[align=left]35． 控制项目规模 （ Dave Quick ）[/align]
[align=left][/align]
[align=left]36． 架构师不是演员，是管家 （ Barry Hawkins ）[/align]
别忘了你的工作责任。

[align=left] [/align]
[align=left]37． 软件架构的道德责任 （ Michael Nygard ）[/align]
架构师的决定会影响许多人，务必慎重。

[align=left] [/align]
[align=left]38． 摩天大厦不可伸缩 （ Michael Nygard ）[/align]
但软件可以。

[align=left] [/align]
[align=left]39． 混合开发的时代已经来临 （ Edward Garson ）[/align]
[align=left] [/align]
[align=left]40． 性能至上 （Craig Russell ）[/align]
[align=left][/align]
[align=left]41． 留意架构图里的空白区域 （ Michael Nygard ）[/align]
空白区域“充满”了各种软件和“硬件”。

[align=left] [/align]
[align=left]42． 学习软件专业的行话 （ Mark Richards ）[/align]
同行之间讲行话方便交流。

[align=left] [/align]
[align=left]43． 具体情境决定一切 （ Edward Garson ）[/align]
[align=left] [/align]
[align=left]44． 侏儒、精灵、巫师和国王 （ Evan Cofsky ）[/align]
开发团队不应该同质化。

[align=left] [/align]
[align=left]45． 向建筑师学习 （ Keith Braithwaite ）[/align]
借鉴建筑行业的经验。

[align=left] [/align]
[align=left]46． 避免重复 （ Niclas Nilsson ）[/align]
[align=left] [/align]
[align=left]47． 欢迎来到现实世界 （ Gregor Hohpe ）[/align]
现实世界比软件世界复杂。

[align=left] [/align]
[align=left]48． 仔细观察，别试图控制一切 （ Gregor Hohpe ）[/align]
[align=left] [/align]
[align=left]49． 架构师好比两面神 （ David Bartlett ）[/align]
架构师应该像两面神一样，眼观六路、耳听八方。

[align=left] [/align]
[align=left]50． 架构师应关注边界和接口 （ Einar Landre ）[/align]
寻找自然的边界，分而治之。

[align=left] [/align]
[align=left]51． 助力开发团队 （ Timothy High ）[/align]
优秀团队是成功的保障，要尽量助力开发团队。

[align=left] [/align]
[align=left]52． 记录决策理由 （ Timothy High ）[/align]
记录架构决策背后的理由，具有极高的投资回报价值。

[align=left] [/align]
[align=left]53． 挑战假设, 尤其是你自己的 （ Timothy High ）[/align]
臆断是事情搞砸的主要根源。务必要确保软件基石坚实可靠。

[align=left] [/align]
[align=left]54． 分享知识和经验 （ Paul W. Homer ）[/align]
帮助周围的人不断改善，他们也会帮助我们发挥出全部的潜力。

[align=left] [/align]
[align=left]55． 模式病 （ Chad La Vigne ）[/align]
不要让一展设计模式功力的欲望，遮蔽了务实的真知。

[align=left] [/align]
[align=left]56． 不要滥用架构隐喻 （ David Ing ）[/align]
不要耽溺于系统隐喻之中，反让它拖了后腿。

[align=left] [/align]
[align=left]57． 关注应用程序的支持和维护 （ Mncedisi Kasper ）[/align]
应用程序的支持和维护，永远都不应该是事后才考虑的事情。

[align=left] [/align]
[align=left]58． 有舍才有得 （ Bill de hÓra ）[/align]
珍惜需要权衡的时机，远胜毫无约束和限制。

[align=left] [/align]
[align=left]59． 原则、公理和类比胜于个人意见和口味 （ Michael Harmer ）[/align]
[align=left] [/align]
[align=left]60． 从“ 可行走骨架” 开始开发应用 （ Clint Shank ）[/align]
从“ 可行走骨架” 开始，增量培育系统成长 。


[align=left] [/align]
[align=left]61． 数据是核心（ Paul W. Homer ）[/align]
从“数据是核心”这个角度去认识系统，能大大降低理解复杂度 。


[align=left] [/align]
[align=left]62． 确保简单问题有简单的解 （Chad La Vigne ）[/align]
[align=left][/align]
[align=left]63． 架构师首先是开发人员 （Mike Brown ）[/align]
碰到麻烦时，架构师可不能只会干吹烟圈却束手无策。

[align=left] [/align]
[align=left]64． 根据投资回报率（ROI ）进行决策（ George Malamidis ）[/align]
[align=left] [/align]
[align=left]65． 一切软件系统都是遗留系统（ Dave Anderson ）[/align]
软件很快便会过时，修改维护无可避免。

[align=left] [/align]
[align=left]66． 起码要有两个可选解决方案（ Timothy High ）[/align]
[align=left] [/align]
[align=left]67． 理解变化的影响 （ Doug Crawford ）[/align]
清楚认识变化类型及其影响。

[align=left] [/align]
[align=left]68． 你不能不了解硬件（ Kamal Wickramanayake ）[/align]
硬件容量规划，是和软件架构同等重要的事情。

[align=left] [/align]
[align=left]69． 现在走捷径，将来需付息（ Scot Mcphee ）[/align]
及时还清技术债务。

[align=left] [/align]
[align=left]70． 不要追求“完美”，“足够好”就行（ Greg Nyberg ）[/align]
避免过度设计。

[align=left] [/align]
[align=left]71． 小心“好主意” （ Greg Nyberg ）[/align]
[align=left] [/align]
[align=left]72． 内容为王 （ Zubin Wadia ）[/align]
[align=left] [/align]
[align=left]73． 对商业方，架构师要避免愤世嫉俗（ Chad La Vigne ）[/align]
[align=left] [/align]
[align=left]74． 拉伸关键维度，发现设计中的不足（ Stephen Jones ）[/align]
[align=left] [/align]
[align=left]75． 架构师要以自己的编程能力为依托（ Mike Brown ）[/align]
[align=left] [/align]
[align=left]76． 命名要恰如其分（ Sam Gardiner ）[/align]
弄清楚要做的究竟是什么。

[align=left] [/align]
[align=left]77． 稳定的问题可以获得高质量的解决方案（ Sam Gardiner ）[/align]
[align=left] [/align]
[align=left]78． 天道酬勤（ Brian Hart ）[/align]
真正做好那些看似简单的任务，坚守承诺。

[align=left] [/align]
[align=left]79． 对决策负责（ Yi Zhou ）[/align]
[align=left] [/align]
[align=left]80． 弃聪明，求质朴（ Eben Hewitt ）[/align]
[align=left] [/align]
[align=left]81． 精心选择有效技术，绝不轻易抛弃（ Chad La Vigne ）[/align]
[align=left] [/align]
[align=left]82． 客户的客户才是你的客户！（ Eben Hewitt ）[/align]
[align=left] [/align]
[align=left]83． 事物发展总会出人意料 （ Peter Gillard-Moss ）[/align]
设计是在不断变化的世界中持续进行探索试验的过程。

[align=left] [/align]
[align=left]84． 选择彼此间能和谐共处的框架 （ Eric Hawthorne ）[/align]
当心“无所不能”型的框架。

[align=left] [/align]
[align=left]85． 着重强调项目的商业价值（ Yi Zhou ）[/align]
[align=left] [/align]
[align=left]86． 不仅仅只控制代码，也要控制数据 （ Chad La Vigne ）[/align]
[align=left][/align]
[align=left]87． 偿还技术债务 （ Burkhardt Hufnagel ）[/align]
在速度和架构间进行权衡，保持平衡。

[align=left] [/align]
[align=left]88． 不要急于求解（ Eben Hewitt ）[/align]
首先看看是否可以改变问题。

[align=left] [/align]
[align=left]89． 打造称手的系统（ Keith Braithwaite ）[/align]
[align=left] [/align]
[align=left]90． 找到并留住富有激情的问题解决者 （ Chad La Vigne ）[/align]
[align=left] [/align]
[align=left]91． 软件并非真实的存在 （ Chad La Vigne ）[/align]
虚拟世界中的软件是柔韧可变的。

[align=left] [/align]
[align=left]92． 学习新语言 （ Burkhardt Hufnagel ）[/align]
防止沟通不畅和误解 。


[align=left] [/align]
[align=left]93． 没有永不过时的解决方案（ Richard Monson-Haefel ）[/align]
[align=left] [/align]
[align=left]94． 用户接受度问题（ Norman Carnovale ）[/align]
减轻用户接受度问题带来的风险。

[align=left] [/align]
[align=left]95． 清汤的重要启示 （ Eben Hewitt ）[/align]
软件架构设计需要不断的精炼浓缩。

[align=left] [/align]
[align=left]96． 对最终用户而言，界面就是系统 （ Vinayak Hegde ）[/align]
[align=left] [/align]
[align=left]97． 优秀软件不是构建出来的，而是培育起来的（ Bill de hÓra ）[/align]