原則大於個人口味
很多架構師都有著豐富的經驗和個人風格，以至於在平常工作中常以個人口味作為決策的依據，對於普通的開發人員也許是可行的，我們鼓勵大家有個人特色，但架構師更應該依據原則辦事，需要維護和遵守一套大家公認的原則，以此作為判斷是非的工具
從「可行走骨架」開始
敏捷管理崇尚盡早整合，在架構設計這一塊，這個原則也行之有效。架構師在開始階段無需陷入某些難題或細節裡，應該盡快地把各個核心模組串接起來，並能發動開發人員使其簡單地運轉起來，骨架一旦就緒，再進入健身環節。這樣做的好處，一方面可以盡早消除大家之間的誤解，也可以帶來正朝著正確方向前進的信心
資料是核心
資料為王是大家深知的道理，只要這個系統擁有有價值的資料，那麼這個系統就有生命力。架構設計中，資料無小事，任何資料只要是存在於系統中，就需要給予足夠的重視，也許是個廢棄的字段，但它也許會有一天被人錯誤的引用到，或是時不時地遭到別人的詢問是幹嘛用的。
根據投資回報率進行決策
很多架構師認為計算和分配資源是pm要做的事情，與自己無關，自己要做的是設計最優的系統。其實，這個最優不光是技術上的最優，往往在實際專案中大家所關注的是投資回報率最優，老闆想用最少的投資獲取符合需求的產品， pm想用最少的人力發布專案，開發人員想用少的**完成功能等等，作為架構師應該把投入產出比作為決策的乙個重要因素
起碼有兩個可選解決方案
乙個經驗豐富的架構師會對一些關鍵的問題給出多個解決方案，並能分析其優缺點，並最後一般取捨之後做出選擇，這是一種令人信服的說明問題和解決問題的方式。
不能不了解硬體
軟體架構師常常無法正確考慮硬體因素，有多種原因，但大多和缺乏硬體的了解脫離不了干係。最好的解決辦法是加強與基礎設施架構師合作，共同對架構和設計進行評估
架構無小事
很多系統建設初期的瑣碎事情在架構師看來是些小事情，比如單元測試、多餘的庫依賴、版本號的公升級、開發人員不合理的**風格等等，這些事情不給於重視盡早解決，會在將來的某天去解決會需要數倍的成本，有效率的架構師會盡早解決這些「小事」
警惕新技術，不輕易拋棄老技術
很多架構師包括大部分的開發人員都有新技術的追求傾向，但暗藏在每個新玩意後面的是風險和缺陷，在引入每項新技術之前，需要給予足夠的評估，不要只看到它power的一面，更應該熟知其潛在的危害。而對於已接收過現實檢驗的老技術不要輕易拋棄，可能它存在些缺陷是某些新技術可以取代的，但我們應該更珍惜對它的了解和成熟，更可取的態度是試圖去優化它而不是拋棄
拉伸關鍵維度，發現設計中的不足
穩定的問題才能產生高質量的解決方案
最好的架構師不是要去解決難題，而是要圍繞難題開展工作，要能夠將四處瀰漫的軟體問題圈起來，並畫出其中的各種邊界，確保對問題有穩定的、完整認識。如果問題是穩定的，那麼解決後就永遠不會再來麻煩你
對決策負責
償還技術債務
系統裡或多或少會存在一些已識別的缺陷，比如單元測試覆蓋率低、可測性差、效能不達標、**壞味道多等等，架構師常常會視為眼中釘，想一夜之間把它們都消滅掉，其實更應該把它們作為債務，有計畫地可控地去償還，要把握好償還的時機，這樣我們的成本和收益比才會更好
結束語
以上這些行為準則不是拿來背誦的，而是應該融入到日常的工作中，有句話說得好，成功是一種習慣，只有習慣了這些成功實踐，才算是真正的成功
架構師行為準則
架構師的行為準則 一 最近看了一本書 軟體架構師應該知道的97件事 本來並沒對它抱有太多期望和興趣，畢竟這種講大道理的書不可能帶來什麼實際收穫，但看的過程中被裡面中肯實在的建議給吸引，對於我這種在走向架構師這條路上常常迷失方向的人，實在是雪中送炭。讀完後，決定選擇其中對我有觸動的條目，加上實際工作中...
架構師的行為準則（四）
原則大於個人口味 很多架構師都有著豐富的經驗和個人風格，以至於在平常工作中常以個人口味作為決策的依據，對於普通的開發人員也許是可行的，我們鼓勵大家有個人特色，但架構師更應該依據原則辦事，需要維護和遵守一套大家公認的原則，以此作為判斷是非的工具 從 可行走骨架 開始 敏捷管理崇尚盡早整合，在架構設計這...
轉 架構師的行為準則（四）
原則大於個人口味 很多架構師都有著豐富的經驗和個人風格，以至於在平常工作中常以個人口味作為決策的依據，對於普通的開發人員也許是可行的，我們鼓勵大家有個人特色，但架構師更應該依據原則辦事，需要維護和遵守一套大家公認的原則，以此作為判斷是非的工具 從 可行走骨架 開始 敏捷管理崇尚盡早整合，在架構設計這...