架構師是一種神祕的職位，據說每個架構師都有密不可傳的方法，當然我們不信，更多的是隻可意會不可言傳。就是說了我們也不會懂，因為還每到“火候”。所能做的就是，當我們到這種火候的時候我們能想起來曾經有過架構師這麼說過，然後我們就可以更自信的向前大步走....

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色燈，用來表示當前的整合狀態，黃色正在整合，綠色整合成功，紅色整合失敗），構建失敗。約翰沒來得及執行自動測試就草率地提交了任務，連累大家無法繼續工作。正常的工作秩序全被打亂了。

這個時候架構師就該發揮作用了，營造一種團隊文化，以維護流程通暢為重，以浪費他人時間為恥。要做到這一點，務必在系統內實現完善的自動測試功能，糾正開發人員的行為。

沉下心來改變系統的生產效率，縮短流程避免各行其是，才能縮短開發時間。總之一定要杜絕一切草率提交任務的念頭。