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

这篇文章引自于阿里巴巴大牛的一份电子邮件，详细如下
软件架构师是 IT 行业里独一无二的职业，既要精通软件开发技术，又要掌握业务知识，还要周旋于公司不同部门之间，协调各种予盾。做到这些绝非易事。

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 ）
防止沟通不畅和误解 。
93 ． 没有永不过时的解决方案（ Richard
Monson-Haefel ）
94 ． 用户接受度问题（ Norman
Carnovale ）
减轻用户接受度问题带来的风险。
95 ． 清汤的重要启示 （ Eben
Hewitt ）
软件架构设计需要不断的精炼浓缩。
96 ． 对最终用户而言，界面就是系统 （ Vinayak
Hegde ）
97 ． 优秀软件不是构建出来的，而是培育起来的（ Bill
de h óra ）