架構師應該編碼嗎？這是個經常出現的問題。
從題目出發，我們先明確一下題中所指的架構師的範圍。由於工作內容的不同，架構師可以細分為很多種，比如系統架構師，應用架構師，產品架構師，企業架構師等等。通常這也意味著各自的技術領域或範疇不盡相同，比如系統架構師會看到軟體、硬體等更大範圍的內容並決策，應用架構師或軟體架構師更偏向於乙個應用領域軟體的技術決策，產品架構師往往注意力集中在多個產品系列的組合發展問題，企業架構師則更傾向於戰略規劃和布局而非**。因此，題目中所指的架構師範圍應該是軟體架構師或應用架構師，由於二者無明顯區別，故在下文中表示相同語義。
乙個軟體架構師，有兩件事離開不開**。一是角色本身的經驗積累**於**，二是所負責軟體的開發過程離不開**。下面分別從這兩個角度來分析一下編碼之於架構師的重要性。
眾所周知，軟體架構師是從開發人員成長起來的，不是一參加工作就任職軟體架構師的。正是由於多年在**上的浸淫，才積累了豐富的設計經驗和全面的編碼技能。這些經驗促成了結構分解的恰到好處，促成了解決方案的知識形成，促成了抽象能力的養成和提高，而分治、知識、抽象這三點恰恰是架構師的法寶。所以，架構師的成長是離不開編碼的。
再看軟體開發過程，好的團隊，架構師一定是團隊中的一員，一定了解核心**的實現。倘若只是輸出幾張設計圖紙就撒手不管，不再關注工程過程，不再關注**實現方法，那就會埋下很多風險的種子。對於軟體實現過程中的核心框架、核心引擎還是要借助於經驗豐富的架構師來把關的，對於新技術的調研與選擇，也是架構師要通過測試來降低技術風險的，對於架構的原型驗證，也是需要以**來展現的。因此，架構師不可能**無關。
通過這兩個環節可以看到，架構師從編碼中來，通過構建原型、框架和基礎，實驗新技術，**評審等必不可少的編碼活動最終完成產品的交付。
當然，架構師畢竟要對軟體結構負責，不能也不應該把所有的時間都用於編碼，也犯不著非要給編碼與非編碼安排個時間比例，誰又能確定一定要百分之幾的編碼時間才是對的呢？
架構師應該掌握哪些設計模式
今天去參加了北京博文視點出版社在上海辦的乙個open party http www.douban.com event 11051981 其中有兩個topic給我很大的啟發，乙個是溫昱的 架構 設計的事實與謬誤 另乙個是老趙 jeffz cn 的 web應用中的快取 當然，我的收穫未必是他們兩位想要傳...
架構師應該知道的那些事兒
在新的團隊有點忙，剛好這本 軟體架構師應該知道的97件事 適合斷斷續續的閱讀，然後慢慢 琢磨 每個人偏重的技術角度不同，所以有些事情讀罷可能未必能引發什麼進一步的想法，但讀到有些以前沒關注過的話題則可能觸發進一步思考。印象最深的一句話是 確保簡單的問題有簡單的解 這本書裡面很多話題都提到了 簡單 這...
架構師應該了解的知識1
原題 被架構師秒殺之後 今天被架構師問了一連串的問題，估計問了有乙個多小時吧，有很多問題都答不上來，突然發現原來自己沒有掌握的知識太多了，原來我覺得技術是用來解決問題的，而不是用來研究的，但現在覺得要更快捷的解決問題，還得好好的研究他們的原理，凡事多問個 他的原理是什麼，底層是怎麼實現的 回來好好整...