软件架构师应该知道的97件事
2010-05-04 09:06
260 查看
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
）
客户需求重于个人简历
（
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
）
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 软件架构师应该知道的97件事
- 软件架构师应该知道的97件事
- 【架构设计】软件架构师应该知道的97件事
- 软件架构师应该知道的97件事 笔记(三)
- 转:软件架构师应该知道的97件事
- 读软件架构师应该知道的97件事的自己理解
- 软件架构师应该知道的97件事 笔记(一)
- 软件架构师应该知道的97件事
- 软件架构师应该知道的97件事
- 软件架构师应该知道的97件事
- 软件架构师应该知道的97件事
- 软件架构师应该知道的97件事
- [文摘20100706】软件架构师应该知道的97件事
- 软件架构师应该知道的97件事
- 【读书笔记】软件架构师应该知道的97件事
- 软件架构师应该知道的97件事 笔记(四)
- (转)软件架构师应该知道的97件事
- 【转】软件架构师应该知道的97件事
- 软件架构师应该知道的97件事 笔记(六)
- 软件架构师应该知道的97件事