软件架构师应该知道的97件事
转自：http://news.csdn.net/a/20100429/218192.html
下面内容摘自该书的标题，并给出了必要的补充说明，由本书译者SeanBV（他的CSDN博客）整理，推荐给大家。
1．客户需求重于个人简历（NitinBorwankar）
客户需求至上。为了自己的简历更炫而采用新技术是沽名钓誉，往往事与愿违。
2．简化根本复杂性，消除偶发复杂性（NealFord）
分析问题好比拨云见月、水落石出。
3．关键问题可能不是出在技术上（MarkRamm）
团队同心，其利断金。
4．以沟通为中心，坚持简明清晰的表达方式和开明的领导风格（MarkRichards）
沟通应当言简意赅、详略得当，别拖泥带水。
5．架构决定性能（RandyStafford）
种瓜得瓜，种豆得豆，架构设计也是一样道理。
6．分析客户需求背后的意义（EinarLandre）
抽丝剥茧，洞见症结。不要被表面需求迷惑。
7．起立发言（UdiDahan）
起立发言效果更好。
8．故障终究会发生（MichaelNygard）
应该提前设计预防措施，限制故障。
9．我们常常忽略了自己在谈判（MichaelNygard）
工程师应该适时转换角色，学习谈判的技巧。
10．量化需求（KeithBraithwaite）
没有规矩，不成方圆。
11．一行代码比五百行架构说明更有价值（AllisonRandal）
可工作的代码才是目标，设计只是达成目标手段。
12．不存在放之四海皆准的解决方案（RandyStafford）
软件世界没有通用钥匙。
13．提前关注性能问题（RebeccaParsons）
尽早展开性能测试。
14．架构设计要平衡兼顾多方需求（RandyStafford）
平衡兼顾项目的技术需求和相关各方的业务需求。
15．草率提交任务是不负责任的行为（NiclasNilsson）
要设法杜绝开发人员草率提交任务的念头。
16．不要在一棵树上吊死（KeithBraithwaite）
为客户提供多样化的解决方案。
17．业务目标至上（DaveMuirhead）
技术决策不能脱离业务目标和现实条件的约束。
18．先确保解决方案简单可用，再考虑通用性和复用性（KevlinHenney）
19．架构师应该亲历亲为（JohnDavies）
身先士卒才能赢得同事的信任。
20．持续集成（DavidBartlett）
21．避免进度调整失误（NormanCarnovale）
不惜一切代价拒绝调整项目进度的要求。
22．取舍的艺术（MarkRichards）
架构不可能满足所有需求。
23．打造数据库堡垒（DanChak）
一开始就要定义好数据模型。
24．重视不确定性（KevlinHenney）
推迟决策，建设性地利用不确定性。
25．不要轻易放过不起眼的问题（DaveQuick）
别忘了温水煮青蛙的故事。
26．让大家学会复用（JeremyMeyer）
重复利用已有资源，首先要改变大家的观念。
27．架构里没有大写的“I”（DaveQuick）
变让自己变成自大狂。
28．使用“一千英尺高”的视图（ErikDoernenburg）
选择合适的架构视图。
29．先尝试后决策（ErikDoernenburg）
30．掌握业务领域知识（MarkRichards）
31．程序设计是一种设计（EinarLandre）
软件开发也分成设计和生产两个阶段。
32．让开发人员自己做主（PhilipNelson）
33．时间改变一切（PhilipNelson）
选择值得投入精力的工作，别跟以前的工作过不去。
34．设立软件架构专业为时尚早（BarryHawkins）
35．控制项目规模（DaveQuick）
36．架构师不是演员，是管家（BarryHawkins）
别忘了你的工作责任。
37．软件架构的道德责任（MichaelNygard）
架构师的决定会影响许多人，务必慎重。
38．摩天大厦不可伸缩（MichaelNygard）
但软件可以。
39．混合开发的时代已经来临（EdwardGarson）
40．性能至上（CraigRussell）
41．留意架构图里的空白区域（MichaelNygard）
空白区域“充满”了各种软件和“硬件”。
42．学习软件专业的行话（MarkRichards）
同行之间讲行话方便交流。
43．具体情境决定一切（EdwardGarson）
44．侏儒、精灵、巫师和国王（EvanCofsky）
开发团队不应该同质化。
45．向建筑师学习（KeithBraithwaite）
借鉴建筑行业的经验。
46．避免重复（NiclasNilsson）
47．欢迎来到现实世界（GregorHohpe）
现实世界比软件世界复杂。
48．仔细观察，别试图控制一切（GregorHohpe）
49．架构师好比两面神（DavidBartlett）
架构师应该像两面神一样，眼观六路、耳听八方。
50．架构师应关注边界和接口（EinarLandre）
寻找自然的边界，分而治之。
51．助力开发团队（TimothyHigh）
优秀团队是成功的保障，要尽量助力开发团队。
52．记录决策理由（TimothyHigh）
记录架构决策背后的理由，具有极高的投资回报价值。
53．挑战假设,尤其是你自己的（TimothyHigh）
臆断是事情搞砸的主要根源。务必要确保软件基石坚实可靠。
54．分享知识和经验（PaulW.Homer）
帮助周围的人不断改善，他们也会帮助我们发挥出全部的潜力。
55．模式病（ChadLaVigne）
不要让一展设计模式功力的欲望，遮蔽了务实的真知。
56．不要滥用架构隐喻（DavidIng）
不要耽溺于系统隐喻之中，反让它拖了后腿。
57．关注应用程序的支持和维护（MncedisiKasper）
应用程序的支持和维护，永远都不应该是事后才考虑的事情。
58．有舍才有得（BilldehÓra）
珍惜需要权衡的时机，远胜毫无约束和限制。
59．原则、公理和类比胜于个人意见和口味（MichaelHarmer）
60．从“可行走骨架”开始开发应用（ClintShank）
从“可行走骨架”开始，增量培育系统成长。
61．数据是核心（PaulW.Homer）
从“数据是核心”这个角度去认识系统，能大大降低理解复杂度。
62．确保简单问题有简单的解（ChadLaVigne）
63．架构师首先是开发人员（MikeBrown）
碰到麻烦时，架构师可不能只会干吹烟圈却束手无策。
64．根据投资回报率（ROI）进行决策（GeorgeMalamidis）
65．一切软件系统都是遗留系统（DaveAnderson）
软件很快便会过时，修改维护无可避免。
66．起码要有两个可选解决方案（TimothyHigh）
67．理解变化的影响（DougCrawford）
清楚认识变化类型及其影响。
68．你不能不了解硬件（KamalWickramanayake）
硬件容量规划，是和软件架构同等重要的事情。
69．现在走捷径，将来需付息（ScotMcphee）
及时还清技术债务。
70．不要追求“完美”，“足够好”就行（GregNyberg）
避免过度设计。
71．小心“好主意”（GregNyberg）
72．内容为王（ZubinWadia）
73．对商业方，架构师要避免愤世嫉俗（ChadLaVigne）
74．拉伸关键维度，发现设计中的不足（StephenJones）
75．架构师要以自己的编程能力为依托（MikeBrown）
76．命名要恰如其分（SamGardiner）
弄清楚要做的究竟是什么。
77．稳定的问题可以获得高质量的解决方案（SamGardiner）
78．天道酬勤（BrianHart）
真正做好那些看似简单的任务，坚守承诺。
79．对决策负责（YiZhou）
80．弃聪明，求质朴（EbenHewitt）
81．精心选择有效技术，绝不轻易抛弃（ChadLaVigne）
82．客户的客户才是你的客户！（EbenHewitt）
83．事物发展总会出人意料（PeterGillard-Moss）
设计是在不断变化的世界中持续进行探索试验的过程。
84．选择彼此间能和谐共处的框架（EricHawthorne）
当心“无所不能”型的框架。
85．着重强调项目的商业价值（YiZhou）
86．不仅仅只控制代码，也要控制数据（ChadLaVigne）
87．偿还技术债务（BurkhardtHufnagel）
在速度和架构间进行权衡，保持平衡。
88．不要急于求解（EbenHewitt）
首先看看是否可以改变问题。
89．打造称手的系统（KeithBraithwaite）
90．找到并留住富有激情的问题解决者（ChadLaVigne）
91．软件并非真实的存在（ChadLaVigne）
虚拟世界中的软件是柔韧可变的。
92．学习新语言（BurkhardtHufnagel）
防止沟通不畅和误解。
93．没有永不过时的解决方案（RichardMonson-Haefel）
94．用户接受度问题（NormanCarnovale）
减轻用户接受度问题带来的风险。
95．清汤的重要启示（EbenHewitt）
软件架构设计需要不断的精炼浓缩。
96．对最终用户而言，界面就是系统（VinayakHegde）
97．优秀软件不是构建出来的，而是培育起来的（BilldehÓra）