前言
客戶需求重於個人簡曆
簡化根本復雜性，消除偶發復雜性
關鍵問題可能不是齣在技術上
以溝通為中心，堅持簡明清晰的錶達方式和開明的領導風格
架構決定性能
分析客戶需求背後的意義
起立發言
故障終究會發生
我們常常忽略瞭自己在談判
量化需求
一行代碼比五百行架構說明更有價值
不存在放之四海皆準的解決方案
提前關注性能問題
架構設計要平衡兼顧多方需求
草率提交任務是不負責任的行為
不要在一棵樹上吊死
業務目標至上
先確保解決方案簡單可用，再考慮通用性和復用性
架構師應該親力親為
持續集成
避免進度調整失誤
取捨的藝術
打造數據庫堡壘
重視不確定性
不要輕易放過不起眼的問題
讓大傢學會復用
架構裏沒有大寫的“i”
使用“一韆英尺高”的視圖
先嘗試後決策
掌握業務領域知識
程序設計是一種設計
讓開發人員自己做主
時間改變一切
設立軟件架構專業為時尚早
控製項目規模
架構師不是演員，是管傢
軟件架構的道德責任
摩天大廈不可伸縮
混閤開發的時代已經來臨
性能至上
留意架構圖裏的空白區域
學習軟件專業的行話
具體情境決定一切
侏儒、精靈、巫師和國王
嚮建築師學習
避免重復
歡迎來到現實世界
仔細觀察，彆試圖控製一切
架構師好比兩麵神
架構師當聚焦於邊界和接口
助力開發團隊
記錄決策理由
挑戰假設尤其是你自己的
分享知識和經驗
模式病
不要濫用架構隱喻
關注應用程序的支持和維護
有捨纔有得
先考慮原則、公理和類比再考慮個人意見和口味
從“可行走骨架”開始開發應用
數據是核心
確保簡單問題有簡單的解
架構師首先是開發人員
根據投資迴報率（roi）進行決策
一切軟件係統都是遺留係統
起碼要有兩個可選的解決方案
理解變化的影響
你不能不瞭解硬件
現在走捷徑，將來付利息
不要追求“完美”，“足夠好”就行
小心“好主意”
內容為王
對商業方，架構師要避免憤世嫉俗
拉伸關鍵維度，發現設計中的不足
架構師要以自己的編程能力為依托
命名要恰如其分
穩定的問題纔能産生高質量的解決方案
天道酬勤
對決策負責
棄聰明，求質樸
精心選擇有效技術，絕不輕易拋棄
客戶的客戶纔是你的客戶！
事物發展總會齣人意料
選擇彼此間可協調工作的框架
著重強調項目的商業價值
不僅僅隻控製代碼，也要控製數據
償還技術債務
不要急於求解
打造上手（zuhanden）的係統
找到並留住富有激情的問題解決者
軟件並非真實的存在
學習新語言
沒有永不過時的解決方案
用戶接受度問題
清湯的重要啓示
對*終用戶而言，界麵就是係統
優秀軟件不是構建齣來的，而是培育起來的
索引
· · · · · · (收起)