架構師是一種神秘的職位，據說每個架構師都有密不可傳的方法，當然我們不信，更多的是只可意會不可言傳。就是說了我們也不會懂，因為還每到「火候」。所能做的就是，當我們到這種火候的時候我們能想起來曾經有過架構師這麼說過，然後我們就可以更自信的向前大步走....
1、客戶需求重於個人簡歷
積累一批滿意的客戶，選擇切合實際的技術解決他們的難題，讓他們樂於推薦你才是最好的履歷。
2、簡化根本複雜性，消除偶發複雜性
根本複雜性指的是與生俱來的、無法避免的困難。比如，協調全國的空中交通就是乙個「天生的」複雜問題，必須實時跟蹤每架飛機的位置。
偶發複雜性：是人們解決根本複雜性的過程中衍生的。
架構師的責任在於解決問題的根本複雜性，同時避免引入偶發複雜性。
怎麼做？盡量選擇源自實際專案的框架，警惕那些象牙塔裡面的產品。
3、關鍵問題可能不是出在技術上
簡單的專案也會翻船，而且這不是個別情況。大多數專案是人完成的，人才是專案成敗與否的基礎。
如果團隊裡有人工作方式不正確，拖專案後腿怎麼辦？有一種非常古老但很完善的技術可以幫助你解決問題。它可能是人類歷史上最重要的技術創新，這就是對話。
有幾個簡單的對話技巧可以顯著改善對話效果：
不要把對話當成對抗。
不要帶著情緒與人溝通。
嘗試通過溝通設定共同的目標。
4、以溝通為中心，堅持簡明清晰的表達方式和開明的領導風格
溝通必須簡明清晰，沒有人願意閱讀冗長的架構決策文件，架構師言簡意賅的表達觀點是專案成功的必要條件。
架構師往往忽略了自己也是領導者。作為領導者我們必須獲得同伴的尊敬才能順利開展工作。所有的成員都希望有明確的溝通和開明的領導。只能這樣才能改善溝通效果，建立團結健康的工作環境。
5、架構決定效能
大家似乎理解，事實並未如此，有些架構師認為簡單的更換底層架構就足以解決應用的效能問題，他們很可能輕信了「經測試產品效能超出競爭對手25%」，比如從4ms到3ms，這1ms放在乙個效能極低的架構裡幾乎可以忽略不計。
歸根結底，所有產品和架構必須遵循分布式計算和物理學的基本原理：執行應用和產品的計算機效能有限，通過物理連線和邏輯協議實現的通訊必然有延時。因此，應該承認架構才是影響應用效能和可伸縮性的決定因素。效能引數是無法簡單的通過更換軟體，或者「調優」底層軟體架構來改善的，我們必須在架構的設計和重新設計上投入更多的精力。
6、分析客戶需求背後的意義
顧客和終端使用者通常提出的所謂需求，只是他們心目中可行的解決方案，並不是問題唯一的解決途徑，當了解顧客的需求背後的意義，我們可以為顧客解決真正的問題並可能降低難度。
7、起立發言
許多架構師都是從技術崗位上成長起來的，他們擅長和機器打交道，然而架構師更需要與人打交道，無論勸說開發人員接受具體的設計模式，還是向管理層解釋購買中介軟體的利弊，溝通都是達成目標的核心技能。
有經驗的架構師會很重視推銷自己的想法也明白有效溝通的重要性，其中乙個簡單又實用的技巧是在2人以上的場合發表意見時請「站起來」，起立發言非常重要尤其是當其他人坐著的時候。
當你站起來的時候無形中新增一種權威和自信，自然就控制住了場面，聽眾不會隨意打斷你的發言，這些都會讓你的發言效果大為改觀，你會發現站立可以更好的用雙手和肢體語言。在10人以上的場合，起立發言方便你與每位聽眾保持視線接觸。眼神交流、肢體語言等表達方式在溝通中的作用不可小覷。起立發言還可以讓你更好的控制語氣、語調、語速和嗓門，讓你的聲音傳的更遠。當你講到重點內容時，注意放慢語速。發聲技巧也能顯著改善溝通效果。
比溝通事半功倍，起立發言是最簡單、有效的方法。
8、故障終究會發生
硬體會出錯，於是我們增加冗餘資源來提公升系統的可靠性，同時也增加了至少有一台裝置出錯的概率。
既然必然會出錯就需要事先設計好防範故障的模型，以應對威脅系統安全的意外情況。
9、我們常常忽略自己在談判
我們都面臨過削減預算的要求，如果資金運轉促襟見肘，技術方案只能委屈求全。
比如如下情景：
「我們真的需要這東西嗎？」專案投資人發難道。
儘管真的需要，我們通常也不能這麼回答，因為此時我們是在談判，此時我們需要認清自己的角色，不能把自己當成工程師，而且投資人明白他在和你談判，我們應該這樣回答"真的需要嗎"這類問題：
「單台伺服器每天至少崩潰3次，沒有第二台我們甚至無法跟董事會演示，事實上我們需要4臺伺服器，構成2組，這樣在需要時斷開一組而不必被迫關閉系統。即使有一台出現意外，也不影響系統正常執行」
10、量化需求
速度快不能算作需求，響應靈敏和可擴充套件也不能算需求，因為我們無法客觀地判斷是否滿足了這樣的條件。
正確的描述需求應該像這樣：「必須在1500ms內響應使用者的輸入。在正常負載下，平均響應時間控制在750ms-1250ms之間。由於使用者無法識別500ms以內的響應，所以我們沒必要將響應時間降到這個範圍一下。」
11、一行**比500行架構說明更有價值
架構說明書（specifications）很重要，因為它描述了構建系統的模式，但是靜下心來全面徹底地理解架構——即從巨集觀上把握元件之間的互動，又著眼於元件內部的**細節——也很重要。
架構師往往容易被抽象的架構所吸引，沉迷於設計過程。事實上僅有架構說明書是遠遠不夠的。軟體專案的最終目標是建立生產體系，架構師必須時刻關注這個目標，牢記設計只是達到目標的手段，而不是目標。
如果親自開發，應該珍視自己花在寫**上的時間，千萬別聽信這會分散架構師精力的說法。這樣既能拓展你的巨集觀視野，也能豐富你的微觀世界。
12、放之四海皆準的解決方案
架構師應該堅持培養和訓練「情景意識」——因為我們遇到的問題千差萬別，不存在放之四海皆準的解決方案。
「情景模式」：調查有經驗的架構師處理複雜問題的方式。有經驗的架構師和設計師的答案如出一轍：只須使用常識....【乙個】比「常識」更貼切的說法是「情景意識」——在給定情景下對合理性的把握。架構師通過學習和實踐，不斷積累的案例和經驗，建立足夠的情景意識。他們通常需要十年的磨練，才能解決系統層次的問題。
13、提前關注效能問題
商業使用者的需求主要表現衛隊功能的要求。系統的非功能特性則由架構師負責，包括：效能表現、靈活性、持續正常工作時間、技術支援資源等。但是對非功能特性的初始測試往往被拖到開發周期的最後階段，有時還由開發團隊來操刀，這樣的錯誤屢見不鮮。
在專案週期的最後階段才關注效能問題，會導致我們錯失大量歷史資訊，這些資訊包含效能變化的細節。如果效能是架構設計的重要指標，就應該盡早展開效能測試。在採用敏捷方法開發的專案中，如果有2週為乙個迭代週期，我認為效能測試的開始時間最遲不能晚於第三次迭代。
堅持技術測試是需要耐心和毅力的，無論是搭建合適的測試環境，採集適當的資料集，還是編寫必要的測試用例，都需要投入大量的時間。
14、架構設計要平衡兼顧多方需求
平衡兼顧各方的要求和專案的技術需求
ceo需要控制成本
運營部門要求軟體易於管理
二次開發人員要求軟體**容易學習方便維護
業務部門：旅行合同義務、創造收益、樹立客戶口碑、控制成本，創造有價值的技術資產
技術部門：確保軟體的功能
15、草率提交任務是不負責任的行為
傍晚時候，團隊正在完成本次迭代的收尾工作，一切按部就班、有條不紊。只有約翰趕著赴約有些急躁，他倉促寫完自己的**，編譯、檢入，然後匆匆離開。幾分鐘後紅燈亮起（許多採用敏捷開發方法的軟體公司（例如thouthtworks）在每個團隊成員的桌上放置一盞3色燈，用來表示當前的整合狀態，黃色正在整合，綠色整合成功，紅色整合失敗），構建失敗。約翰沒來得及執行自動測試就草率地提交了任務，連累大家無法繼續工作。正常的工作秩序全被打亂了。
這個時候架構師就該發揮作用了，營造一種團隊文化，以維護流程通暢為重，以浪費他人時間為恥。要做到這一點，務必在系統內實現完善的自動測試功能，糾正開發人員的行為。
沉下心來改變系統的生產效率，縮短流程避免各行其是，才能縮短開發時間。總之一定要杜絕一切草率提交任務的念頭。
軟體架構師應該知道的97件事之概括16 30
16 不要在一棵樹上吊死 負責構建系統的人似乎無法接受這樣的事實 沒有哪種資料型別 訊息格式 訊息傳送機制，甚至主流的架構元件 策略 觀點用來能夠用來解決所有的業務問題，畢竟當大家都希望擺脫業務需求不斷滋生的意外和煩惱。才用多鐘表現方式 多鐘傳輸方式不是為了消遣。應當認識到，通過分解系統的非功能引數...
軟體架構師應該知道的97件事 筆記 一
1.客戶需求重於個人簡歷 不要為了學習新的知識或豐富自己的簡歷而選擇新技術解決問題，要盡量選擇切合實際的技術解決客戶的難題。腳踏實地的為客戶著想，選擇正確的方案可以降低專案的壓力，團隊工作起來更開心，客戶也會更滿意，從而你也會有更充裕的時間學習新的知識。2.簡化根本複雜性，消除偶發複雜性 根本複雜性...
軟體架構師應該知道的97件事 筆記 四
46.避免重複 如果開發人員複製救命 中的內容，說明這部分還可以簡化，甚至全部提取出來。消滅複製是架構師的責任，如果有重複，則應該重新研究框架，創造更完善的抽象機制。47.歡迎來到現實世界 現實世界是不可預知的，隨時都可能發生一些讓人預料不到的事情，如客戶撤消訂單，付款時間延誤等。如果現實世界帶來了...