提問：網上有個很有爭議的問題“架構師到底該不該寫代碼？”，您對此怎麼看？
我旗幟鮮明的認為：架構師應該寫代碼。
做架構設計需要了解業務。任何與業務分離的架構設計都是耍流氓。
我更反對一家公司設立所謂的架構師部門來把控整個公司的所有架構師資源。我建議每個業務研發團隊都有自己的架構師，他對業務有深刻的瞭解，並根據業務的特點設計系統架構。
畫外音：沒有一種適合所有業務場景的架構解決方案。
為了讓系統設計得更完美，你必須學會查看代碼並編寫代碼。 即使你根本沒有時間編寫代碼，至少系統的每個詳細的細節架構師都需要弄清楚。 CodeReview也非常重要，保證代碼至少是有兩個人看過，而且它的實現邏輯和詳細設計是一致的。
我對架構師的建議是：有時間的話，親自去寫核心代碼，如果沒有時間的話，要把關詳細設計並安排資深工程師去做CodeReview。
提問：目前，互聯網技術更新非常快。你認為架構師對此持什麼態度？
首先，我認為我們需要關注，研究和學習新技術，但是在線上應用新技術時必須要慎重。
到家集團、快狗打車的技術體系，拿存儲來舉例，選擇很多，MySQL最成熟，我們就用它，統一非常重要，一定不能是哪個團隊想用什麼就用什麼，統一能夠節省很多招聘、運維、測試成本，遇到問題能夠查閱社區資料，通過行業牛人溝通快速解決。
提問：大家覺得架構師的知識寬度是很廣的，那會不會有什麼都懂、什麼都不精這樣一種現象存在？
首先，什麼都懂是絕對不可能的，什麼都精通也是絕對不可能的。
雖然業務不一樣，但在架構思路設計中一定有一些共同點。
以我為例，我曾經制作了個上百萬個用戶同時在線的即時通訊系統，，它肯定有架構領域內通用的東西，比如接入、數據、可用性、擴展性、一致性等，所以這些經驗對我以後的推薦系統、支付系統、打車系統等等的設計有很大幫助。
架構師對於知識的寬度和深度都是有要求，我心中合格的架構師，是“π型人才”，除了技術寬度，還要有兩條腿：一條是專項深度，還有一條是通用能力，比如表達、溝通、解決問題、創新等。
提問：有很多立志於成為架構師的人不知道如何開始？沈老師能不能給一些比較具體的建議？
我認為架構師之路分為三個階段：
第一階段，是打基本功的階段。對應我自己的話就是職業生涯的前三年，語言、數據結構、算法、設計模式、研發工具、調試工具等，基本功沒打好，其他的一切都是空談。
第二階段，是業務的深入與技術深度的積累。對於我來說，業務的深入，是職業生涯前五年在即時通訊領域的打拼。
當你進入一家公司時，業務的深度決定了你的價值。企業要想解決一個業務問題，就必須有針對性地招聘相關人才，能夠解決某個業務領域內的大部分技術問題，這是你的核心競爭力。
畫外音：核心競爭力不是Java工程師，而是XX工程師（XX是一個業務前綴，例如即時通訊），很多技術同學容易走偏。
第三階段，π型人才的另外一條腿，即通用素質。就是你的執行力、責任心、推動能力、溝通表達能力、項目管理能力，這會讓其他人感覺你很可靠。 當每個人都具有相似的技術能力時，為什麼要交給你做呢？ 因為公司認為你最可靠，所以可靠性是描述了你是否靠普。
提問：沒有完美的架構，那好的架構有一個什麼樣的標準呢？
架構是為業務服務的，能夠滿足業務的需求並且對它的擴展性多考慮一步，我覺得這樣的架構就是合適的。
畫外音：請注意，是多考慮一步，不是兩步，不是五年後。
曾經被問到：“快狗出租車已經從14年發展到現在，並且該架構已經迭代了許多版本。如果我回到14年並重新進行架構設計，那麼架構會不會是現在的樣子？，答案是一定不會跟今天一個樣子，一定還是和14年時候一個樣子，那個時候的架構，適合那個階段。
架構不但是設計來的，更是演進而來的。
問：很多技術人員都很關注公司的技術氛圍。你在建立技術氛圍方面有什麼經驗可以分享嗎？
提幾個建議把：
第一，指導人機制很重要,也就是說，任何一個技術人員都必須有一個高層領導，有任何技術上的問題一定是有人可以交流和解答的。
第二，技術審查非常重要。技術評審是每個人交流和討論技術問題的好機會。
第三，共享機制非常重要。每個團隊定期組織技術分享，讓大家交流。我每週也花時間和同事們交流技術。
閱讀更多 IT大派 的文章
