1、開發人員應該解決問題，而不是解迷取樂。
2、關鍵問題可能不是出在技術上：
- 不要把對話當成對抗
- 不要帶成情緒與人溝通
- 嘗試通過溝通設定共同目標
3、以溝通為中心，堅持簡明清晰的表達方式和開明的領導風格。
- 讓開發人員參與架構的制訂過程，這樣他們才會買你的帳！
4、架構才是影響應用效能和延展性的決定因素，績效參數是無法簡單地通過更換軟體，或者“調優”底層軟體架構來改善的。
5、分析客戶需求背後的意義
- 架構師可以通過詢問客戶，分析客戶要求的功能和需求的真正意義，定位真正的問題，從而提出比客戶的建議更好、成本更底的解決方案。
6、讓溝通事半功倍，起立發言是簡單、有效方法！
7、故障終究會發生。
8、量化需求
- 比如：必須在1500毫秒響應使用者的輸入。在正常負載（定義如下....）的情況下，平均回應時間必須控制在750~1250毫秒之間。由於使用者無法識別500毫秒以內的響應，所以我們必須將回應時間降低到這個範圍之下。
9、一行代碼比五百行架構說明更有價值
- 如果你親自參與開發，應該珍視自己花在寫代碼上的時間，千萬別聽信這會分散架構師精力的說法。參與項目所付出的努力，既能拓展你的宏觀視野，也能豐富你的微觀視界。
10、提前關注效能問題。
11、草率提交任務是不負責任的行為。
12、營運目標至上、掌握業務領域知識
- 架構師必須通過溝通協調，即保護軟體架構，又堅持營運目標，即允許開發人員制定微觀（技術）決策，又設法避免他們參與制定業務決策。如果技術決策脫離了營運目標目標和現實條件的約束，則無異於用寶貴的稀缺資源進行高風險的投機。
13、先確保解決方案簡單可用，再考慮通用性和複用性。
- 許多用來實現基礎設施的代碼，包括組件架構、類庫、基礎服務，普遍存在一個問題，它們的設計一味強調通用性而不考慮具體應用，導致出現許多令人困惑的可選項和不確定因素，這些功能常常不是因為被閑置，就是被誤用，甚至毫無價值。
14、架構師應該親力親為
- 對技術缺乏全面理解的架構師，充其量只是個專案經理。
- 架構師完全可以要求團隊成員的協助，讓團隊成員充分參與制訂解決方案，同時引導討論方向，找出正確的方案。
- 架構師應該儘早參與項目，與團隊成員並肩工作，而不是坐在象牙塔裡發號施令。
15、持續整合
16、避免進度調整失誤
- 加快進度不一定會降低成本，要考慮交付品質和後期造成的影響，可以嘗試去掉一些不重要的功能，留待後續版本發布。
17、取捨的藝術
- 世界上不存十全十美的設計，既具有高效能，又具有高可用性；既高度安全，又高度抽象；
18、不要輕易放過不起眼的問題
- 自已的盲點自己難以查覺，忠言雖然逆耳，卻是你最寶貴的財富。
- 組織團隊一起來想辦法管理風險。
19、讓大家學會複用
- 大家知道它們的存在
- 大家知道如何使用它們
- 大家認識到利用已有的資源好過自己動手
20、架構裡沒有大寫的"I"
- 自我反省，做人問題。
- 重視團隊合作，架構屬於團隊，不是你一個人的。你負責導航，大家一起划槳。雙方缺一不可，但相比之下，你更離不開他們的協助。
- 做技術的，保持謙虛是最基本的素質！
21、先嘗試後決策
- 盡量延遲決定的時間，最後即便不做決策，決策也會自己呈現。
- 對同一個問題嘗試兩種或兩種以上的解決方案，比直接決策然後動手實現的工作量要大。
22、程式設計是一種設計
23、控制項目規模
24、架構師不是演員，是管家。
- 紮實掌握技術和業務領域知識，以嚴謹的領導風格贏得團隊的尊重。
25、混合開發的時代已經來臨
26、效能至上
27、學習軟體專業的行話
- 比如架構和設計模式可以分成四大類，企業架構模式、應用架構模式、整合模式和設計模式。
28、具體情境決定一切
- 架構決策只有在情境需要時，才能犧牲盡量簡單的原則。
29、侏儒、精靈、巫師和國王
- 軟體架構師好比國王，應該熟悉各種人的性格特點，招聘不同性格的人加入自己的團隊，英明的國王知道怎樣用目標來激勵不同的種族，率領大家並肩作戰完成任務。
30、避免重複
31、仔細觀察，別試圖控制一切
32、架構師當聚焦於邊界和介面
33、助力Team Dev
- 確保開發人員擁有他們所需的工具
- 確保開發人員擁有他們所需的技能
- 只要不違背軟體設計的總體目標，就讓開發人員自己做出決策。
- 保護好開發人員，不要讓他們捲入到不那麼重要的工作中。
34、記錄決策理由
- 不要為了寫文檔而寫。
- 懂得《取捨的藝術》，定義軟體架構，就是要在品質屬性、成本、時間以及其它各種因素之間，做出正確的權衡。
35、分享知識和經驗
36、模式病
- 使用模式解決適用的問題才是最重要的，禁止在項目中硬塞不必要的模式。
37、關注應用程式的支援和維護
- 應用程式超過80%的生命週期都是在維護上
- 理解開發人員和技術服務人員確實具有不同的技能
- 在項目中儘可能早地引入支援負責人
- 將支援負責人作為團隊的核心成員之一
- 讓支援負責人蔘與規劃應用程式的支援
38、有舍才有得
- 接受某種約束或放棄某個特性，可帶來更好的架構，這種架構在構建和營運上都會更加簡單，而且成本底。
39、先考慮原則、公理和類比，再考慮個人意見和口味。
40、資料是核心
41、不僅僅控制碼，也要控制資料。
- 原始碼控制和持續整合，是管理應用程式構建過程和部署過程的優秀工具。資料方案和資料內容通常會隨著原始碼變化而變化，它們也是這一過程的重要組成部分，因此也需要對之進行類似的控制。
- 靈活運用“資料庫指令碼”解決問題。
42、確保簡單問題有簡單的解
- 對於簡單的問題，不要採用複雜的解決方案。軟體設計者都是聰明人，但是出於炫技心理，很容易陷入“殺雞用牛刀”的誤區。
- 對應第一條“開發人員應該解決問題，而不是解迷取樂。”
43、架構師首先是開發人員
- 作為架構師，主要目標應該是建立可行、可維護的解決方案，當然，也一定要能解決當前的問題。
44、根據投資報酬率(ROI)進行決策
45、一切軟體系統都是遺留系統
- 即使系統十分前沿，採用了最新的技術開發而成，但對於接手的下一個而言，它也會是遺留系統。
- 設計最佳化的架構基礎，考慮如下幾個問題：清晰性、可測性、正確性、可跟蹤
- 可以參考一些優秀的開源項目
46、起碼要有兩個可選的解決方案
47、理解變化影響
- 優秀的架構師能夠深刻理解變化帶來的影響，這種影響不僅限於彼此隔離的軟體模組之間，而且包括人與人之間，以及系統與系統之間。
- 變化有多種不同表現形式：功能需求的變化、可擴充性需求的演化、系統的介面被修改、團隊人員流動等。
- 常用方法減輕變化的影響：運行小規模的增量漸層、構建可重複啟動並執行測試案例、讓測試案例更易編寫、跟蹤好依賴關係、系統性的行動，根據反饋資訊作出進一步反應、自動化重複的任務。
48、你不能不瞭解硬體
49、現在走捷徑，將來付利息。
50、不追求“完美”，“足夠好”就行
- 在設計和實現上追求完美，會導致過度設計和模糊混亂的解決方案，最終使系統難以維護。應用程式開發不是選美大賽，因此，停止吹毛求疵的做法，不要再浪費時間追求盡善盡美。
51、小心“好主意”
- 那種誘人的、不用想都知道的、外表無辜、以為不可能會產生傷害的那種“好”主意。通常在項目進展到一半而似乎一切看起來都挻好——形勢和進度都在循序漸進，初步測試進展順利，落地日期看起來可靠無誤——的時候，項目團隊中有人會冒出這些想法。務必小心那些“好主意”，它可能會殺死你的項目。
52、內容為王
53、對商業方，架構師要避免憤世嫉俗。
54、架構師要以自己的編程能力為依託
55、穩定的問題才能產生高品質的解決方案
- 只要問題是穩定的，你就可以建立出一個擁有穩定設計的系統。穩定的設計可以讓你集中精力，打造出高品質的應用程式。
56、天道酬勤
57、棄聰明，求質樸。
58、對決策負責
- 重要的架構決策應該以書面形式記錄下來，它們必須經過校核證實，並可被追溯。
- 必須和執行該決策及會直接或間接受其影響的人進行過溝通，達成共識。
59、精心選擇有效技術，絕不輕易拋棄。
60、客戶的客戶才是你的客戶！
61、事物發展總會出人意料
- 設計是一個不斷髮現的過程，發現問題並解決問題。
- 沒有永不到期的解決方案。
62、著重強調項目的商業價值
- 形成價值陳述
- 建立量化的度量標準
- 回過頭來關聯傳統商業的衡量方式
- 知道該在哪裡停止
- 尋找恰當的時機
63、償還技術債務
- 花合適時間“一次做對”！
- 取巧走“捷徑”，爭取儘快推出修改後以產品。
64、打造上手的系統
- 使用者體驗很重要
- 對終端使用者而言，介面就是系統！
65、找到並留住富有激情的問題解決者
- 我們所要找的，是那種具備解決問題的能力和激情的開發人員，都善於攻克各種難題的人才。
- 提防批評過度，它可能會扼殺開發人員的創造力，降底生產力。
- 好的開發人員都非常聰明，他們知道自己並非一無是處，如果你對其工作吹毛求疵，將會降低他們對你的尊重！
- 以正確的方式經營Team Dev，其重要性不言而喻。
66、學習新語言
- 想要理解客戶或者想讓客戶理解你的語言，必須學習客戶所在行業領域的語言，這樣才能做到有效溝通。
67、優秀軟體不是構建出來的，而是培育起來的。
- 設計儘可能小的系統，協助成功交付，並推動它向宏偉的遠景目標不斷演化。注意，不要把這種演化式方法和削減需求、規範混亂和生產廢品這樣的做法混淆在一起。
