先確保解決方案簡單可用，再考慮通用性和復用性
系統的複雜性往往是架構師基於通用性和復用性的設計而引入的，很多具體問題往往不需要通用性和復用性的解決方案。如果存在多個可實施方案難以取捨，先簡單後通用原則可以成為最終的評判標準。架構師提供具體解決方案時，無需排斥通用和靈活，但是如果過早脫離具體情況，只會迷失在無限的可能性裡，被複雜的配置選項、超負荷的引數列表、冗長羅嗦的介面，以及存在缺陷的抽象所淹沒。先簡單滿足需求，當重複需求再次發生時，通過重構來達到復用是一種不錯的方式
架構師應該親力親為
架構師乾久了往往會脫離技術本身，迷茫在抽象之中，這是很危險可怕的。架構師要取得其他同事的信任，應該比業務人員更懂業務，比開發人員更懂具體的編碼，比測試人員更懂如何有效地測試，就像航班的主駕駛員，雖然不需要親自操作，但經驗豐富，持續地監視著情況，一旦發現異常隨時採取行動。架構師應該專案的交付和質量負有最終的責任。架構師應該盡可能地參與專案，不能把技術決策和方向上的難題拆分出扔給別人，需要採取更務實的辦法，比如親自動手研究或和其他成員討論。
持續整合是架構師的重要任務
普通的開發人員會focus在各自負責的小模組，只會對單個模組負責，而架構師需要對整個系統負責，持續整合是一種對整個系統進行有效控制的好方法，架構師有責任讓它執行起來。
避免進度調整失誤
雖然保障進度是pm的職責，但變更要發生的時候，作為對技術最有發言權的架構師應該站出來，把變更的必要性和風險進行仔細分析，最大限度地支援pm的決策。
取捨的藝術
我們做系統，特別是網際網路系統，絕不是做乙個變形金剛，而是做乙個有缺陷但卻滿足了現階段商業需求的系統，因此架構師需要有取捨的藝術，你的架構是能用有限的資源滿足最迫切的需求，捨掉那些看是光鮮卻無太多用處的東西
打造資料庫堡壘
在上層的程式設計中，架構師一般都會推崇先簡單實現，然後在逐步重構的敏捷方式，但對於較為穩定的後端資料庫，我們需要採取更為謹慎的態度，因為資料庫是整個系統的基石，無論是業務設計還是技術設計都得保持它的穩定性，這是整個系統穩定的基礎。我們往往會發現這麼乙個現象，當程式第一版上線後，資料庫裡表只會增加不會刪除，也不會刪除多餘的字段，每次資料庫變更都會引起所有人的緊張，也會使得本已混亂的資料庫設計更為混亂。
重視不確定性
優良的架構能夠從整體上降低設計決策的重要性，糟糕的架構則會使得常常突出選擇的重要性。如果出現兩個合理地選擇，架構師應該停下來，設法找出介於兩者之間的、具有更低重要性的決策，了解兩者之外還存在其他選擇，比決策結果本身更有價值
不要輕易放過不起眼的問題
專案的失敗或線上故障往往是由於專案過程中的不起眼問題所引起，比如一些特殊的邊界情況，而這些問題絕不能指望開發主力們去發現和解決，因為他們的注意力都會focus在主要矛盾上，作為時刻監控專案的架構師應該擔當起發現這些「小bug」的義務。
讓大家學會復用
架構師有義務提高開發人員可復用地解決問題的意識，比如以上幾種措施：
架構文件的抽象程度要適中
架構師寫架構文件常常很糾結，寫得太高層次的話就太空洞，無切實的指導意義；寫得太具體的話，比如指明到類的各種uml圖，就會很約束開發人員。文件要寫到什麼程度，關鍵在於滿足他人的需求，比如業務部門想從文件中得知系統各功能的實施可行性，因此你的文件要能體現各主要功能是如何滿足的。測試人員想知道系統內部如何流轉和如何對系統進行測試，因此你的文件要體現系統主要模組的執行流程和系統可測試性。開發人員需要知道系統各自模組的劃分和之間的互動規範，因此你的文件要體現模組化設計。pm需要知道這個專案有哪些風險點，因此你的文件要體現風險點識別和如何規避。dba和運維人員需要知道系統的資料量和效能情況，因此需要指明系統如何應對大資料量的情況。關鍵一點，架構師不是為了設計而設計，是要想清楚別人為什麼要看你的文件，怎樣滿足別人的需求
先嘗試後決策
設計中有很多需要決策的點，很多架構師喜歡在象牙塔裡憑藉經驗做決策，感覺這就是架構師需要幹的。其實，這樣的做法往往會讓你很被動，不如延遲決策，把需要決策的點丟擲來，讓大家去嘗試，在實踐比較中，其實無須決策，正確的選擇自然就出來了，這樣也更能拉近你和大家的距離，提高大家的積極性和你的權威性
掌握業務領域知識
架構師的角色任務在於理解業務問題、業務目標、業務需求、並設計技術架構來滿足它們。掌握業務領域知識將有利於架構師選擇合適的架構模式，更好地制定針對未來的擴充套件計畫。
coding是屬於設計範疇
很多人常常把軟體開發模擬於傳統行業，把coding比作是生產過程，因此很多一線開發人員稱作自己為**工人，很多架構師也是這麼認為，只是把開發人員當作實現自己設計的生產工具而已。其實coding相對於傳統行業應該屬於設計範疇，真正生產過程實際上是由工具來完成的編譯、構建和發布過程。架構師更應該把coding當作設計來看，從紙上的設計到coding後的**還有很多設計點可挖，同樣的輸出的背後也許**於完全不同的coding，其軟體成品的價值也是完全不同的。
架構師行為準則
架構師的行為準則 一 最近看了一本書 軟體架構師應該知道的97件事 本來並沒對它抱有太多期望和興趣，畢竟這種講大道理的書不可能帶來什麼實際收穫，但看的過程中被裡面中肯實在的建議給吸引，對於我這種在走向架構師這條路上常常迷失方向的人，實在是雪中送炭。讀完後，決定選擇其中對我有觸動的條目，加上實際工作中...
架構師的行為準則（二）
走向架構師之路 先確保解決方案簡單可用，再考慮通用性和復用性 系統的複雜性往往是架構師基於通用性和復用性的設計而引入的，很多具體問題往往不需要通用性和復用性的解決方案。如果存在多個可實施方案難以取捨，先簡單後通用原則可以成為最終的評判標準。架構師提供具體解決方案時，無需排斥通用和靈活，但是如果過早脫...
架構師的行為準則（三）
讓開發人員自己做主 架構師雖然需要為系統的設計負責，但無須包攬所有的設計工作，應該給予團隊成員足夠的自主權，讓他們發揮自己的創意和能力，你的工作是確保大家的工作能很好的組合在一起，幫助他人解決棘手困難。當你發現同事遇到麻煩時，可以主動給出建議，但更可取的做法是創造良好的氛圍，讓大家主動向你徵求意見。...