《软件架构师应该知道的97件事》 一览

    客户需求重于个人简历 2
　　尼廷•博万卡（Nitin Borwankar）
　　简化根本复杂性，消除偶发复杂性 4
　　尼尔•福特（Neal Ford）
　　关键问题可能不是出在技术上 6
　　马克•兰姆（Mark Ramm）
　　以沟通为中心，坚持简明清晰的表达方式和开明的领导风格 8
　　马克•理查兹（Mark Richards）
　　架构决定性能 10
　　兰迪•斯塔福德（Randy Stafford）
　　分析客户需求背后的意义 12
　　埃纳尔•兰德雷（Einar Landre）
　　起立发言 14
　　乌迪•大汉（Udi Dahan）
　　故障终究会发生 16
　　迈克尔•尼加德（Michael Nygard）
　　我们常常忽略了自己在谈判 18
　　迈克尔•尼加德（Michael Nygard）
　　量化需求 20
　　基思•布雷思韦特（Keith Braithwaite）
　　一行代码比五百行架构说明更有价值 22
　　艾利森•兰德尔（Allison Randal）
　　不存在放之四海皆准的解决方案 24
　　兰迪•斯塔福德（Randy Stafford）
　　提前关注性能问题 26
　　丽贝卡•帕森斯（Rebecca Parsons）
　　架构设计要平衡兼顾多方需求 28
　　兰迪•斯塔福德（Randy Stafford）
　　草率提交任务是不负责任的行为 30
　　尼克拉斯•尼尔森（Niclas Nilsson）
　　不要在一棵树上吊死 32
　　基思•布雷思韦特（Keith Braithwaite）
　　业务目标至上 34
　　戴夫•缪尔黑德（Dave Muirhead）
　　先确保解决方案简单可用，再考虑通用性和复用性 36
　　凯佛林•亨尼（Kevlin Henney）
　　架构师应该亲力亲为 38
　　约翰•戴维斯（John Davies）
　　持续集成 40
　　大卫•巴特利（David Bartlett）
　　避免进度调整失误 42
　　诺曼•卡诺瓦利（Norman Carnovale）
　　取舍的艺术 44
　　马克•理查兹（Mark Richards）
　　打造数据库堡垒 46
　　丹•恰克（Dan Chak）
　　重视不确定性 48
　　凯佛林•亨尼（Kevlin Henney）
　　不要轻易放过不起眼的问题 50
　　戴夫•奎克（Dave Quick）
　　让大家学会复用 52
　　杰里米•迈耶（Jeremy Meyer）
　　架构里没有大写的“I” 54
　　戴夫•奎克（Dave Quick）
　　使用“一千英尺高”的视图 56
　　埃里克•多伦伯格（Erik Doernenburg）
　　先尝试后决策 58
　　埃里克•多伦伯格（Erik Doernenburg）
　　掌握业务领域知识 60
　　马克•理查兹（Mark Richards）
　　程序设计是一种设计 62
　　埃纳尔•兰德雷（Einar Landre）
　　让开发人员自己做主 64
　　菲利普•尼尔森（Philip Nelson）
　　时间改变一切 66
　　菲利普•尼尔森（Philip Nelson）
　　设立软件架构专业为时尚早 68
　　巴里•霍金斯（Barry Hawkins）
　　控制项目规模 70
　　大卫•奎克（Dave Quick）
　　架构师不是演员，是管家 72
　　巴里•霍金斯（Barry Hawkins）
　　软件架构的道德责任 74
　　迈克尔•尼加德（Michael Nygard）
　　摩天大厦不可伸缩 76
　　迈克尔•尼加德（Michael Nygard）
　　混合开发的时代已经来临 78
　　爱德华•加森（Edward Garson）
　　性能至上 80
　　克雷格•罗素（Craig Russell）
　　留意架构图里的空白区域 82
　　迈克尔•尼加德（Michael Nygard）
　　学习软件专业的行话 84
　　马克•理查兹（Mark Richards）
　　具体情境决定一切 86
　　爱德华•加森（Edward Garson）
　　侏儒、精灵、巫师和国王 88
　　埃文•考夫斯基（Evan Cofsky）
　　向建筑师学习 90
　　基思•布雷思韦特（Keith Braithwaite）
　　避免重复 92
　　尼克拉斯•尼尔森（Niclas Nilsson）
　　欢迎来到现实世界 94
　　格雷戈尔•侯珀（Gregor Hohpe）
　　仔细观察，别试图控制一切 96
　　格雷戈尔•侯珀（Gregor Hohpe）
　　架构师好比两面神 98
　　大卫•巴特利（David Bartlett）
　　架构师当聚焦于边界和接口 100
　　埃纳尔•兰德雷（Einar Landre）
　　助力开发团队 102
　　蒂莫西•海伊（Timothy High）
　　记录决策理由 104
　　蒂莫西•海伊（Timothy High）
　　挑战假设尤其是你自己的 106
　　蒂莫西•海伊（Timothy High）
　　分享知识和经验 108
　　保罗•W•霍默（Paul W. Homer）
　　模式病 110
　　查德•拉•瓦因（Chad La Vigne）
　　不要滥用架构隐喻 112
　　戴维•英格（David Ing）
　　关注应用程序的支持和维护 114
　　门西蒂西•卡斯珀（Mncedisi Kasper）
　　有舍才有得 116
　　比尔•德•霍拉（Bill de hÓra）
　　先考虑原则、公理和类比再考虑个人意见和口味 118
　　迈克尔•哈默（Michael Harmer）
　　从“可行走骨架”开始开发应用 120
　　克林特•尚克（Clint Shank）
　　数据是核心 122
　　保罗•W•霍默（Paul W. Homer）
　　确保简单问题有简单的解 124
　　查德•拉•瓦因（Chad La Vigne）
　　架构师首先是开发人员 126
　　迈克•布朗（Mike Brown）
　　根据投资回报率（ROI）进行决策 128
　　乔治•马拉米迪斯（George Malamidis）
　　一切软件系统都是遗留系统 130
　　戴夫•安德森（Dave Anderson）
　　起码要有两个可选的解决方案 132
　　蒂莫西•海伊（Timothy High）
　　理解变化的影响 134
　　道格•克劳福德（Doug Crawford）
　　你不能不了解硬件 136
　　卡迈尔•威克拉玛纳亚克（Kamal Wickramanayake）
　　现在走捷径，将来付利息 138
　　斯科特•麦克菲（Scot Mcphee）
　　不要追求“完美”，“足够好”就行 140
　　格雷格•纽伯格（Greg Nyberg）
　　小心“好主意” 142
　　格雷格•纽伯格（Greg Nyberg）
　　内容为王 144
　　朱宾•沃迪亚（Zubin Wadia）
　　对商业方，架构师要避免愤世嫉俗 146
　　查德•拉•瓦因（Chad La Vigne）
　　拉伸关键维度，发现设计中的不足 148
　　斯蒂芬•琼斯（Stephen Jones）
　　架构师要以自己的编程能力为依托 150
　　迈克•布朗（Mike Brown）
　　命名要恰如其分 152
　　萨姆•加德纳（Sam Gardiner）
　　稳定的问题才能产生高质量的解决方案 154
　　萨姆•加德纳（Sam Gardiner）
　　天道酬勤 156
　　布赖恩•哈特（Brian Hart）
　　对决策负责 158
　　周异（Yi Zhou）
　　弃聪明，求质朴 160
　　埃本•休伊特（Eben Hewitt）
　　精心选择有效技术，绝不轻易抛弃 162
　　查德•拉•瓦因（Chad La Vigne）
　　客户的客户才是你的客户！ 164
　　埃本•休伊特（Eben Hewitt）
　　事物发展总会出人意料 166
　　彼得•吉拉德莫斯（Peter Gillard-Moss）
　　选择彼此间可协调工作的框架 168
　　埃里克•霍索恩（Eric Hawthorne）
　　着重强调项目的商业价值 170
　　周异（Yi Zhou）
　　不仅仅只控制代码，也要控制数据 172
　　查德•拉•瓦因（Chad La Vigne）
　　偿还技术债务 174
　　伯克哈特•赫夫纳盖尔（Burkhardt Hufnagel）
　　不要急于求解 176
　　埃本•休伊特（Eben Hewitt）
　　打造上手（Zuhanden）的系统 178
　　基思•布雷思韦特（Keith Braithwaite）
　　找到并留住富有激情的问题解决者 180
　　查德•拉•瓦因（Chad La Vigne）
　　软件并非真实的存在 182
　　查德•拉•瓦因（Chad La Vigne）
　　学习新语言 184
　　伯克哈特•赫夫纳盖尔（Burkhardt Hufnagel）
　　没有永不过时的解决方案 186
　　理查德•蒙森-哈费尔（Richard Monson-Haefel）
　　用户接受度问题 188
　　诺曼•卡诺瓦利（Norman Carnovale）
　　清汤的重要启示 190
　　埃本•休伊特（Eben Hewitt）
　　对最终用户而言，界面就是系统 192
　　维纳亚克•赫格德（Vinayak Hegde）
　　优秀软件不是构建出来的，而是培育起来的 194
　　比尔•德•霍拉（Bill de hÓra）
　　索引 196