下面內(nèi)容摘自該書的標題，并給出了必要的補充說明，由本書譯者SeanBV（他的CSDN博客）整理，推薦給大家。
1． 客戶需求重于個人簡歷 （ Nitin Borwankar ）
客戶需求至上。為了自己的簡歷更炫而采用新技術(shù)是沽名釣譽，往往事與愿違。
2． 簡化根本復(fù)雜性 ，消除偶發(fā)復(fù)雜性 （ Neal Ford ）
分析問題好比撥云見月、水落石出。
3． 關(guān)鍵問題可能不是出在技術(shù)上 （ Mark Ramm ）
團隊同心，其利斷金。
4． 以溝通為中心，堅持簡明清晰的表達方式和開明的領(lǐng)導(dǎo)風(fēng)格 （ Mark Richards ）
溝通應(yīng)當言簡意賅、詳略得當，別拖泥 帶水。
5． 架構(gòu)決定性能 （ Randy Stafford ）
種瓜得瓜，種豆得豆，架構(gòu)設(shè)計也是一 樣道理。
6． 分析客戶需求背后的意義 （ Einar Landre ）
抽絲剝繭，洞見癥結(jié)。不要被表面需求 迷惑。
7． 起立發(fā)言 （ Udi Dahan ）
起立發(fā)言效果更好。
8． 故障終究會發(fā)生 （ Michael Nygard ）
應(yīng)該提前設(shè)計預(yù)防措施，限制故障。
9． 我們常常忽略了自己在談判 （ Michael Nygard ）
工程師應(yīng)該適時轉(zhuǎn)換角色，學(xué)習(xí)談判的 技巧。
10． 量化需求 （ Keith Braithwaite ）
沒有規(guī)矩，不成方圓。
11． 一行代碼比五百行架構(gòu)說明更有價值 （ Allison Randal ）
可工作的代碼才是目標，設(shè)計只是達成 目標手段。
12． 不存在放之四海皆準的解決方案 （ Randy Stafford ）
軟件世界沒有萬能鑰匙。
13． 提前關(guān)注性能問題 （ Rebecca Parsons ）
盡早展開性能測試。
14． 架構(gòu)設(shè)計要平衡兼顧多方需求 （ Randy Stafford ）
平衡兼顧項目的技術(shù)需求和相關(guān)各方的業(yè)務(wù)需求。
15． 草率提交任務(wù)是不負責(zé)任的行為 （ Niclas Nilsson ）
要設(shè)法杜絕開發(fā)人員草率提交任務(wù)的念頭。
16． 不要在一棵樹上吊死 （ Keith Braithwaite ）
為客戶提供多樣化的解決方案。
17． 業(yè)務(wù)目標至上 （ Dave Muirhead ）
技術(shù)決策不能脫離業(yè)務(wù)目標和現(xiàn)實條件的約束。
18． 先確保解決方案簡單可用，再考慮通用性和復(fù)用性 （ Kevlin Henney ）
19． 架構(gòu)師應(yīng)該親歷親為 （ John Davies ）
身先士卒才能贏得同事的信任。
20． 持續(xù)集成 （ David Bartlett ）
21． 避免進度調(diào)整失誤 （ Norman Carnovale ）
不惜一切代價拒絕調(diào)整項目進度的要求。
22． 取舍的藝術(shù) （ Mark Richards ）
架構(gòu)不可能滿足所有需求。
23． 打造數(shù)據(jù)庫堡壘 （ Dan Chak ）
一開始就要定義好數(shù)據(jù)模型。
24． 重視不確定性 （ Kevlin Henney ）
推遲決策，建設(shè)性地利用不確定性。
25． 不要輕易放過不起眼的問題 （ Dave Quick ）
別忘了溫水煮青蛙的故事。
26． 讓大家學(xué)會復(fù)用 （ Jeremy Meyer ）
重復(fù)利用已有資源，首先要改變大家的觀念。
27． 架構(gòu)里沒有大寫的“I ” （ Dave Quick ）
變讓自己變成自大狂。
28． 使用“ 一千英尺高” 的視圖 （ Erik Doernenburg ）
選擇合適的架構(gòu)視圖。
29． 先嘗試后決策 （ Erik Doernenburg ）
30． 掌握業(yè)務(wù)領(lǐng)域知識 （ Mark Richards ）
31． 程序設(shè)計是一種設(shè)計 （ Einar Landre ）
軟件開發(fā)也分成設(shè)計和生產(chǎn)兩個階段。
32． 讓開發(fā)人員自己做主 （ Philip Nelson ）
33． 時間改變一切 （ Philip Nelson ）
選擇值得投入精力的工作，別跟以前的工作過不去。
34． 設(shè)立軟件架構(gòu)專業(yè)為時尚早 （ Barry Hawkins ）
35． 控制項目規(guī)模 （ Dave Quick ）
36． 架構(gòu)師不是演員，是管家 （ Barry Hawkins ）
別忘了你的工作責(zé)任。
37． 軟件架構(gòu)的道德責(zé)任 （ Michael Nygard ）
架構(gòu)師的決定會影響許多人，務(wù)必慎重。
38． 摩天大廈不可伸縮 （ Michael Nygard ）
但軟件可以。
39． 混合開發(fā)的時代已經(jīng)來臨 （ Edward Garson ）
40． 性能至上 （Craig Russell ）
41． 留意架構(gòu)圖里的空白區(qū)域 （ Michael Nygard ）
空白區(qū)域“充滿”了各種軟件和“硬件”。
42． 學(xué)習(xí)軟件專業(yè)的行話 （ Mark Richards ）
同行之間講行話方便交流。
43． 具體情境決定一切 （ Edward Garson ）
44． 侏儒、精靈、巫師和國王 （ Evan Cofsky ）
開發(fā)團隊不應(yīng)該同質(zhì)化。
45． 向建筑師學(xué)習(xí) （ Keith Braithwaite ）
借鑒建筑行業(yè)的經(jīng)驗。
46． 避免重復(fù) （ Niclas Nilsson ）
47． 歡迎來到現(xiàn)實世界 （ Gregor Hohpe ）
現(xiàn)實世界比軟件世界復(fù)雜。
48． 仔細觀察，別試圖控制一切 （ Gregor Hohpe ）
49． 架構(gòu)師好比兩面神 （ David Bartlett ）
架構(gòu)師應(yīng)該像兩面神一樣，眼觀六路、耳聽八方。
50． 架構(gòu)師應(yīng)關(guān)注邊界和接口 （ Einar Landre ）
尋找自然的邊界，分而治之。
51． 助力開發(fā)團隊 （ Timothy High ）
優(yōu)秀團隊是成功的保障，要盡量助力開發(fā)團隊。
52． 記錄決策理由 （ Timothy High ）
記錄架構(gòu)決策背后的理由，具有極高的投資回報價值。
53． 挑戰(zhàn)假設(shè), 尤其是你自己的 （ Timothy High ）
臆斷是事情搞砸的主要根源。務(wù)必要確保軟件基石堅實可靠。
54． 分享知識和經(jīng)驗 （ Paul W. Homer ）
幫助周圍的人不斷改善，他們也會幫助我們發(fā)揮出全部的潛力。
55． 模式病 （ Chad La Vigne ）
不要讓一展設(shè)計模式功力的欲望，遮蔽了務(wù)實的真知。
56． 不要濫用架構(gòu)隱喻 （ David Ing ）
不要耽溺于系統(tǒng)隱喻之中，反讓它拖了后腿。
57． 關(guān)注應(yīng)用程序的支持和維護 （ Mncedisi Kasper ）
應(yīng)用程序的支持和維護，永遠都不應(yīng)該是事后才考慮的事情。
58． 有舍才有得 （ Bill de hÓra ）
珍惜需要權(quán)衡的時機，遠勝毫無約束和限制。
59． 原則、公理和類比勝于個人意見和口味 （ Michael Harmer ）
60． 從“ 可行走骨架” 開始開發(fā)應(yīng)用 （ Clint Shank ）
從“ 可行走骨架” 開始，增量培育系統(tǒng)成長 。
61． 數(shù)據(jù)是核心（ Paul W. Homer ）
從“數(shù)據(jù)是核心”這個角度去認識系統(tǒng)，能大大降低理解復(fù)雜度 。
62． 確保簡單問題有簡單的解 （Chad La Vigne ）
63． 架構(gòu)師首先是開發(fā)人員 （Mike Brown ）
碰到麻煩時，架構(gòu)師可不能只會干吹煙圈卻束手無策。
64． 根據(jù)投資回報率（ROI ）進行決策（ George Malamidis ）
65． 一切軟件系統(tǒng)都是遺留系統(tǒng)（ Dave Anderson ）
軟件很快便會過時，修改維護無可避免。
66． 起碼要有兩個可選解決方案（ Timothy High ）
67． 理解變化的影響 （ Doug Crawford ）
清楚認識變化類型及其影響。
68． 你不能不了解硬件（ Kamal Wickramanayake ）
硬件容量規(guī)劃，是和軟件架構(gòu)同等重要的事情。
69． 現(xiàn)在走捷徑，將來需付息（ Scot Mcphee ）
及時還清技術(shù)債務(wù)。
70． 不要追求“完美”，“足夠好”就行（ Greg Nyberg ）
避免過度設(shè)計。
71． 小心“好主意” （ Greg Nyberg ）
72． 內(nèi)容為王 （ Zubin Wadia ）
73． 對商業(yè)方，架構(gòu)師要避免憤世嫉俗（ Chad La Vigne ）
74． 拉伸關(guān)鍵維度，發(fā)現(xiàn)設(shè)計中的不足（ Stephen Jones ）
75． 架構(gòu)師要以自己的編程能力為依托（ Mike Brown ）
76． 命名要恰如其分（ Sam Gardiner ）
弄清楚要做的究竟是什么。
77． 穩(wěn)定的問題可以獲得高質(zhì)量的解決方案（ Sam Gardiner ）
78． 天道酬勤（ Brian Hart ）
真正做好那些看似簡單的任務(wù)，堅守承諾。
79． 對決策負責(zé)（ Yi Zhou ）
80． 棄聰明，求質(zhì)樸（ Eben Hewitt ）
81． 精心選擇有效技術(shù)，絕不輕易拋棄（ Chad La Vigne ）
82． 客戶的客戶才是你的客戶?。?nbsp;Eben Hewitt ）
83． 事物發(fā)展總會出人意料 （ Peter Gillard-Moss ）
設(shè)計是在不斷變化的世界中持續(xù)進行探索試驗的過程。
84． 選擇彼此間能和諧共處的框架 （ Eric Hawthorne ）
當心“無所不能”型的框架。
85． 著重強調(diào)項目的商業(yè)價值（ Yi Zhou ）
86． 不僅僅只控制代碼，也要控制數(shù)據(jù) （ Chad La Vigne ）
87． 償還技術(shù)債務(wù) （ Burkhardt Hufnagel ）
在速度和架構(gòu)間進行權(quán)衡，保持平衡。
88． 不要急于求解（ Eben Hewitt ）
首先看看是否可以改變問題。
89． 打造稱手的系統(tǒng)（ Keith Braithwaite ）
90． 找到并留住富有激情的問題解決者 （ Chad La Vigne ）
91． 軟件并非真實的存在 （ Chad La Vigne ）
虛擬世界中的軟件是柔韌可變的。
92． 學(xué)習(xí)新語言 （ Burkhardt Hufnagel ）
防止溝通不暢和誤解 。
93． 沒有永不過時的解決方案（ Richard Monson-Haefel ）
94． 用戶接受度問題（ Norman Carnovale ）
減輕用戶接受度問題帶來的風(fēng)險。
95． 清湯的重要啟示 （ Eben Hewitt ）
軟件架構(gòu)設(shè)計需要不斷的精煉濃縮。
96． 對最終用戶而言，界面就是系統(tǒng) （ Vinayak Hegde ）
97． 優(yōu)秀軟件不是構(gòu)建出來的，而是培育起來的（ Bill de hÓra ）
聯(lián)系客服
