架構師的行為準則（一）
最近看了一本書《軟體架構師應該知道的97件事》，本來並沒對它抱有太多期望和興趣，畢竟這種講大道理的書不可能帶來什麼實際收穫，但看的過程中被裡面中肯實在的建議給吸引，對於我這種在走向架構師這條路上常常迷失方向的人，實在是雪中送炭。讀完後，決定選擇其中對我有觸動的條目，加上實際工作中的感悟，形成一套自認為正確的架構師行為準則，以此來矯正自己的行為。
客戶需求高於一切
不要為了自己的專案經歷上新增光彩而去一味追求時髦而光鮮的方案，而是應該扎根客戶需求，腳踏實地地為客戶著想，這樣才能更體現技術的價值，不至於迷失方向。架構師首先不要把自己當做技術人員，而是業務人員，把實現業務需求作為至上的目標，學會拒絕成本高，價效比不高的技術。
簡化根本複雜性
常常為了解決某一區域性複雜性引入了更為複雜的框架或產品，使得複雜性不減反增。往往正確的方式是做減法而不是加法，把最根本的複雜源找到，把根剷除。
關鍵問題可能不是出在技術上
總結失敗的專案常常會糾結於選擇了錯誤的技術。其實技術並沒有錯，而是在使用技術上或是在執行過程中人為的偏差導致。而架構師解決這種人為的問題比較好的方式是溝通，通過有效地溝通把技術貫徹下去
以溝通為中心，堅持簡明清晰和開明的風格
架構師不要坐在象牙塔裡，命令開發人員實施你的設計和決策，而是應該盡量簡化你的設計，透徹地與他們溝通，並且關鍵在於開明地接受他們的建議並勇於推翻自己的決策
架構決定效能
最好提公升效能的方法不是痛苦地做一次次對即將上線的產品做效能測試和提公升，而是在架構設計的時候就把效能作為重要因素，從架構底層考慮分布式、快取、系統互動劃分等影響效能的重點。提前關注效能，是解決效能問題代價最小的方式
分析客戶要求背後的真實需求
合同上或uc上只是客戶的要求，而並非100%是客戶真實的需求，架構師的重要責任就是挖掘隱藏在要求背後的真實需求，這個不但可以最大化滿足客戶，也往往可以幫助我們避開技術壁壘，當真正抓住客戶需求的時候，我們也許能用更為簡單的替代方案滿足客戶
溝通是架構師達成目標的核心技能
常用的溝通技能和準則有以下幾點：
• 不要把溝通當做對抗
• 不要帶有情緒與人溝通
• 表達自己方案之前傾聽他人觀點
• 站立發言是擴大溝通影響力的一種好方式
• 學習業務或技術領域中的行話，降低溝通成本
不要為預防故障引入更多的故障
架構師常常會為識別出的可能故障點加入監控措施，但往往會忽略做些監控措施也是會有故障的，不要試圖讓你的系統天衣無縫，這往往是使系統更為複雜和脆弱的**。先承認是系統總會有缺陷的，只是把這些缺陷設定為容易察覺和維護的點
量化非功能性需求
往往功能性需求容易量化，因為這些是看得見和摸得著的，但像效能好、可擴充套件性好、高可用性等這些非功能性需求卻不好量化，但作為架構師要有意識地去定義和量化這些需求，只有這樣才能更好地和其他部門更好溝通，謀求更多資源，也便於系統更有效地驗收
一行**比500行架構說明更有說服力
架構師往往喜歡待在象牙塔裡，堆砌大量架構文件，然後希望其他開發人員能乖乖地去實施。這樣做的效果往往是不好的，一方面很難有這樣的牛人能洞察所有的細節，在文件裡就**性地解決了所有問題，另一方面也不利於架構師與開發人員的溝通。比較好的做法是架構師參與具體實施，在實施中驗證和改進架構設計，與大家達成一片也便於加深彼此配合的默契程度。
不存在放之四海皆準的解決方案
不存在最好的架構，只有最合適的架構。不會有一種架構方案，在任何專案裡都適用。雖然我們承認模式的重要性，但在實際專案裡要有選擇性吸收，根本上要本專案和實際困境出發，不要被既有的模式和經驗先入為主，因為沒有一種已有方案能完全不修改地適用於你。
架構設計要平衡兼顧多方需求
架構師從某種角度來講就是一劑膠水，把業務部門的需求、專案進度的需求、測試的需求和開發工程師本身的需求有效地捏合在一起，平衡與兼顧以至達到皆大歡喜。其他職能的人都只是focus在某一區域性，需要架構師這樣的人來通盤考慮，因此他的工作是最雜的，絕不是簡簡單單地拿出乙份架構文件就ok了，需要考慮系統安全、易用性、可測性、商業價值、長期規劃、發布管理和部署方式，使得各個部門人的需求得到響應
架構師的行為準則（四）
結束語
以上這些行為準則不是拿來背誦的，而是應該融入到日常的工作中，有句話說得好，成功是一種習慣，只有習慣了這些成功實踐，才算是真正的成功
架構師的行為準則（三）
讓開發人員自己做主 架構師雖然需要為系統的設計負責，但無須包攬所有的設計工作，應該給予團隊成員足夠的自主權，讓他們發揮自己的創意和能力，你的工作是確保大家的工作能很好的組合在一起，幫助他人解決棘手困難。當你發現同事遇到麻煩時，可以主動給出建議，但更可取的做法是創造良好的氛圍，讓大家主動向你徵求意見。...
架構師的行為準則（一）
最近看了一本書 軟體架構師應該知道的97件事 本來並沒對它抱有太多期望和興趣，畢竟這種講大道理的書不可能帶來什麼實際收穫，但看的過程中被裡面中肯實在的建議給吸引，對於我這種在走向架構師這條路上常常迷失方向的人，實在是雪中送炭。讀完後，決定選擇其中對我有觸動的條目，加上實際工作中的感悟，形成一套自認為...
架構師的行為準則（二）
先確保解決方案簡單可用，再考慮通用性和復用性 系統的複雜性往往是架構師基於通用性和復用性的設計而引入的，很多具體問題往往不需要通用性和復用性的解決方案。如果存在多個可實施方案難以取捨，先簡單後通用原則可以成為最終的評判標準。架構師提供具體解決方案時，無需排斥通用和靈活，但是如果過早脫離具體情況，只會...