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

软件架构师应该知道的97件事
97 Things Every Software Architect Should Know

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 ）
1. Don't put your resume ahead of the requirements   by Nitin Borwankar
2. Simplify essential complexity; diminish accidental complexity  by Neal Ford
3. Chances are your biggest problem isn't technical   by Mark Ramm
4. Communication is King; Clarity and Leadership its humble servants  by Mark Richards
5. Architecting is about balancing   by Randy Stafford
6. Seek the value in requested capabilities  by Einar Landre
7. Stand Up!   by Udi Dahan
8. Skyscrapers aren't scalable by Micheal Nygard
9. You're negotiating more often than you think. by Michael Nygard
10. Quantify  by Keith Braithwaite
11. One line of working code is worth 500 of specification by Allison Randal
12. There is no one-size-fits-all solution  by Randy Stafford
13. It's never too early to think about performance by Rebecca Parsons
14. Application architecture determines application performance  by Randy Stafford
15. Commit-and-run is a crime.   by Niclas Nilsson
16. There Can be More than One  by Keith Braithwaite
17. Business Drives   by Dave Muirhead
18. Simplicity before generality, use before reuse  by Kevlin Henney
19. Architects must be hands on  by John Davies
20. Continuously Integrate  by Dave Bartlett
21. Avoid Scheduling Failures by Norman Carnovale  
22. Architectural Tradeoffs  by Mark Richards
23. Database as a Fortress  by  Dan Chak
24. Use uncertainty as a driver  by Kevlin Henney
25. Scope is the enemy of success  by Dave Quick
26. Reuse is about people and education, not just architecture  by Jeremy Meyer
27. There is no 'I' in architecture   by Dave Quick
28. Get the 1000ft view  by Erik Doernenburg
29. Try before choosing  by Erik Doernenburg
30. Understand The Business Domain  by Mark Richards
31. Programming is an act of design  by Einar Landre
32. Time changes everything  by Philip Nelson
33. Give developers autonomy  by Philip Nelson
34. Value stewardship over showmanship  by Barry Hawkins
35. Warning, problems in mirror may be larger than they appear by Dave Quick
36. The title of software architect has only lower-case 'a's; deal with it  by Barry Hawkins
37. Software architecture has ethical consequences  by Michael Nygard
38. Everything will ultimately fail  by Michael Nygard
39. Context is King  by Edward Garson
40. It's all about performance   by  Craig L Russell
41. Engineer in the white spaces  by Michael Nygard
42. Talk the Talk by Mark Richards
43. Heterogeneity Wins  by Edward Garson
44. Dwarves, Elves, Wizards, and Kings  by Evan Cofsky
45. Learn from Architects of Buildings  by Keith Braithwaite
46. Fight repetition by Niclas Nilsson
47. Welcome to the Real World by Gregor Hohpe
48. Don't Control, but Observe by Gregor Hohpe
49. Janus the Architect by Dave Bartlett
50. Architects focus is on the boundaries and interfaces  by Einar Landre
51. Challenge assumptions - especially your own by  Timothy High
52. Record your rationale  by Timothy High
53. Empower developers  by Timothy High
54. It is all about the data  by Paul W. Homer
55. Control the data, not just the code   by Chad LaVigne
56. Don't Stretch The Architecture Metaphors by David Ing
57. Focus on Application Support and Maintenance by Mncedisi Kasper
58. Prepare to pick two by Bill de hOra
59. Prefer principles, axioms and analogies to opinion and taste  by Michael Harmer
60. Start with a Walking Skeleton by Clint Shank
61. Share your knowledge and experiencesby Paul W. Homer
62. Make sure the simple stuff is simple   by Chad LaVigne
63. If you design it, you should be able to code it. by Mike Brown
64. The ROI variable by George Malamidis
65. Your system is legacy, design for it.  by Dave Anderson
66. If there is only one solution, get a second opinion  by  Timothy High
67. Understand the impact of change by  Doug Crawford  
68. You have to understand Hardware too by  Kamal Wickramanayake
69. Shortcuts now are paid back with interest later  by  Scot Mcphee
70. "Perfect" is the Enemy of "Good Enough"   by  Greg Nyberg
71. Avoid "Good Ideas" by  Greg Nyberg
72. Great content creates great systems  by  Zubin Wadia
73. The Business Vs. The Angry Architect by Chad LaVigne
74. Stretch key dimensions to see what breaks by  Stephen Jones
75. Before anything, an architect is a developer  by  Mike Brown
76. A rose by any other name will end up as a cabbage   by  Sam Gardiner
77. Stable problems get high quality solutions  by  Sam Gardiner
78. It Takes Diligence by Brian Hart
79. Take responsibility for your decisions  by  Yi Zhou
80. Don’t Be a Problem Solver  by  Eben Hewitt
81. Choose your weapons carefully, relinquish them reluctantly by Chad LaVigne
82. Your Customer is Not Your Customer  by  Eben Hewitt
83. It will never look like that  by Peter Gillard-Moss
84. Choose Frameworks that play well with others  by  Eric Hawthorne
85. Make a strong business case  by  Yi Zhou
86. Pattern Pathology  by  Chad LaVigne
87. Learn a new language by  Burk Hufnagel
88. Don't Be Clever  by Eben Hewitt
89. Build Systems to be Zuhanden by Keith Braithwaite
90. Find and retain passionate problem solvers by Chad LaVigne
91. Software doesn’t really exist by  Chad LaVigne
92. Pay down your technical debt by  Burk Hufnagel
93. You can't future-proof solutions   by Richard Monson-Haefel
94. The User Acceptance Problem by Norman Carnovale
95. The Importance of Consommé  by  Eben Hewitt
96. For the end-user, the interface is the system   by Vinayak Hegde
97. Great software is not built, it is grown    by  Bill de hora