【轉載】架構師的行為準則（一）

    最近看了一本書《軟體架構師應該知道的97件事》，本來并沒對它抱有太多期望和興趣，畢竟這種講大道理的書不可能帶來什麼實際收獲，但看的過程中被裡面中肯實在的建議給吸引，對于我這種在走向架構師這條路上常常迷失方向的人，實在是雪中送炭。讀完後，決定選擇其中對我有觸動的條目，加上實際工作中的感悟，形成一套自認為正确的架構師行為準則，以此來矯正自己的行為。 

客戶需求高于一切 

      不要為了自己的項目經曆上添加光彩而去一味追求時髦而光鮮的方案，而是應該紮根客戶需求，腳踏實地地為客戶着想，這樣才能更展現技術的價值，不至于迷失方向。架構師首先不要把自己當做技術人員，而是業務人員，把實作業務需求作為至上的目标，學會拒絕成本高，成本效益不高的技術。 

簡化根本複雜性 

      常常為了解決某一局部複雜性引入了更為複雜的架構或産品，使得複雜性不減反增。往往正确的方式是做減法而不是加法，把最根本的複雜源找到，把根鏟除。 

關鍵問題可能不是出在技術上 

      總結失敗的項目常常會糾結于選擇了錯誤的技術。其實技術并沒有錯，而是在使用技術上或是在執行過程中人為的偏差導緻。而架構師解決這種人為的問題比較好的方式是溝通，通過有效地溝通把技術貫徹下去。 

以溝通為中心，堅持簡明清晰和開明的風格 

      架構師不要坐在象牙塔裡，指令開發人員實施你的設計和決策，而是應該盡量簡化你的設計，透徹地與他們溝通，并且關鍵在于開明地接受他們的建議并勇于推翻自己的決策。 

架構決定性能 

      最好提升性能的方法不是痛苦地做一次次對即将上線的産品做性能測試和提升，而是在架構設計的時候就把性能作為重要因素，從架構底層考慮分布式、緩存、系統互動劃分等影響性能的重點。提前關注性能，是解決性能問題代價最小的方式。 

分析客戶要求背後的真實需求 

      合同上或uc上隻是客戶的要求，而并非100%是客戶真實的需求，架構師的重要責任就是挖掘隐藏在要求背後的真實需求，這個不但可以最大化滿足客戶，也往往可以幫助我們避開技術壁壘，當真正抓住客戶需求的時候，我們也許能用更為簡單的替代方案滿足客戶。 

溝通是架構師達成目标的核心技能 

      常用的溝通技能和準則有以下幾點： 

不要把溝通當做對抗

不要帶有情緒與人溝通

表達自己方案之前傾聽他人觀點

站立發言是擴大溝通影響力的一種好方式

學習業務或技術領域中的行話，降低溝通成本

不要為預防故障引入更多的故障

      架構師常常會為識别出的可能故障點加入監控措施，但往往會忽略做些監控措施也是會有故障的，不要試圖讓你的系統天衣無縫，這往往是使系統更為複雜和脆弱的來源。先承認是系統總會有缺陷的，隻是把這些缺陷設定為容易察覺和維護的點。 

量化非功能性需求 

      往往功能性需求容易量化，因為這些是看得見和摸得着的，但像性能好、可擴充性好、高可用性等這些非功能性需求卻不好量化，但作為架構師要有意識地去定義和量化這些需求，隻有這樣才能更好地和其他部門更好溝通，謀求更多資源，也便于系統更有效地驗收。 

一行代碼比500行架構說明更有說服力 

      架構師往往喜歡待在象牙塔裡，堆砌大量架構文檔，然後希望其他開發人員能乖乖地去實施。這樣做的效果往往是不好的，一方面很難有這樣的牛人能洞察所有的細節，在文檔裡就預測性地解決了所有問題，另一方面也不利于架構師與開發人員的溝通。比較好的做法是架構師參與具體實施，在實施中驗證和改進架構設計，與大家達成一片也便于加深彼此配合的默契程度。 

不存在放之四海皆準的解決方案 

      不存在最好的架構，隻有最合适的架構。不會有一種架構方案，在任何項目裡都适用。雖然我們承認模式的重要性，但在實際項目裡要有選擇性吸收，根本上要從本項目和實際困境出發，不要被既有的模式和經驗先入為主，因為沒有一種已有方案能完全不修改地适用于你。 

架構設計要平衡兼顧多方需求 

      架構師從某種角度來講就是一劑膠水，把業務部門的需求、項目進度的需求、測試的需求和開發工程師本身的需求有效地捏合在一起，平衡與兼顧以至達到皆大歡喜。其他職能的人都隻是focus在某一局部，需要架構師這樣的人來通盤考慮，是以他的工作是最雜的，絕不是簡簡單單地拿出一份架構文檔就ok了，需要考慮系統安全、易用性、可測性、商業價值、長期規劃、釋出管理和部署方式，使得各個部門人的需求得到響應。