軟體架構師應該知道的97件事

.基思·佈雷思韋特（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 hora）
索引 196