Zhu哥
我還真見過兩個這樣的架構師。第一個是我第一次當項目經理，公司為了讓技術更上一層樓找了一個架構師，不會寫代碼，只會動嘴，我們技術老大對他確實很看重，但是下面人每一個服的，經常想法整他，比如，有了問題就找他，他說了半天沒用，下面人直接說你告訴我怎麼寫，架構師就懵逼了。最後這個哥們也沒落好。第二個是我去的一家大公司，當初也是架構師進去的，跟我一起的一個架構師也是不會寫代碼，好像是博士畢業，但是公司大，很多人都瞎混，這個哥們也一直混，反正沒人管，活的還挺滋潤。
這就是現實，程序猿，說句不好聽的話，都是草莽出身，一身“英雄氣概”，只佩服“高手”，你弄個只會耍嘴皮子的，怎麼可能讓這些人服呢？別說架構師了，就是程序猿直接領導，如項目經理，如果不會寫代碼，項目協調能力再好，也會被程序員白眼的。
再說了，真正的架構絕不是想出來的。軟件最講迭代，架構也一樣，每個牛逼的架構都是逐漸迭代出來的，當然底層的設計也很關鍵。但是隻靠想，很難出現很好的架構。牛逼的架構是需要不斷迭代的，而不是一成不變。
所以，想做架構師的程序員，寫代碼練內功都是必要的。不懂代碼的架構師，大公司混日子可以，想讓真正幹事的程序猿服你，別妄想了。
祖國的蝸牛
哈哈，想起了一個小故事，以前接手了一個架構師的一個項目，這個架構師是太陽（sun）公司出來的，JAVA代碼能力可見一斑，寫的代碼確實很美觀，讓人看著賞心悅目，但是硬生生的被我找出了好幾十個程序bug，最後還被我吐槽了！
但是，不得不說的是，這個前同事（後來離職去某大公司做AI了）思維很強，邏輯能力很強，動手能力很強，因為能力強，老闆對他是採取散養的方式，當時公司要搭建一個項目，他看了一下午的英語文檔，然後就開始動手了，兩天之後就見到了雛形，一個月之後整個項目上線，直到現在還在健壯的供多個項目調用，雖然偶然有bug，但是整個項目的可擴展性，健壯性，安全性相當高！
所以，不是說架構師不會犯任何錯，寫代碼就一定好，但是整個架構在他面前是很清晰的，很多新的技術他也能快速的掌握其原理，並且使用起來！
架構師不會寫代碼是不可能的，只有寫過代碼才能知道底層需要的是什麼，誰也不可能一上來就搭框架，談架構！只不過他們站在了更加宏觀的角度，去設計，去指揮！
架構師已經不在乎底層的增刪改查怎麼來實現，而是整個業務需要多少臺機器，會有多大的數據量，數據庫怎麼設計？如何方便以後的擴容，日誌怎麼收集，分析？服務間怎麼通信，數據怎麼保持一致？系統怎麼才能健壯？用戶體驗怎麼才能更好？
在其位謀其政，等到有天我們也現在架構師的位置上，我們也可以自豪且牛筆轟轟的說一句：“想當年我寫代碼也很溜的”！
架構師，是我的目標，你的呢？
哎喲JAVA不錯哦
宰相必起於州郡，猛將必發於卒伍。
怎麼看待不會寫代碼的架構師？我通常看都不看。
PPT架構師？
現在很流行一個詞兒——PPT架構師：說起大道理一套一套的，但是每當被問到“這裡是怎麼實現”的時候，PPT架構師總會說“我們不討論細節”，然後接著說那些大道理。
通常這種PPT架構師會遭到程序員“鄙視”的，如果作為一個技術帶頭人不懂技術，不能“服眾”，長此以往，估計就要換個地方去寫PPT了。
架構師的職責
有的人認為架構師的工作是在項目開始之前，其實架構師的職責要貫穿於整個項目：
參與需求分析：脫離業務需求的架構都是耍流氓。
技術選型：架構師在架構設計的同時，需要完成技術選型的工作，而且技術選型是要貼近公司的實際情況，為一個還在SSH框架的公司，設計出一套微服務的框架，明顯就是脫離實際。
把握開發方向：在項目開發過程中，架構師需要經常與程序員溝通，讓程序員可以充分了解架構的意圖。
踩坑：開發過程中難免會遇到各種技術難題，有的時候需要架構師“真刀真槍”地上陣解決。
架構師需要具備哪些品質
技術的深度和廣度，畢竟技術才是架構師的“安身立命”之本。
優秀的架構師，有著深厚的業務知識和經驗的積累。
良好的溝通能力，項目推進過程中，離不開和需求、項目經理、程序員的溝通。
一定的管理能力，畢竟架構師是程序員的“領頭羊”。
必要的時候，打開IDE就能敲代碼的能力。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
早期互聯網領域裡大部分架構師都有過豐富的編碼經歷，傳統軟件公司更是如此，架構師是程序員發展的一個重要方向。但是隨著互聯網領域的不斷髮展，現在確實出現了一批不會做編碼的架構師，可以說這是互聯網領域快速發展的一個必然結果。
架構師在整個互聯網（軟件）產品中起著重要的作用，架構師負責整個軟件體系結構的設計、核心技術方案設計，架構師也需要具備一定的視野，能夠從較高的層次來理解軟件體系結構和技術發展趨勢，可以說架構師是一個技術含量非常高的職業。
既然是技術含量非常高的職業，那麼不會編碼可以麼？當然可以，原因有以下幾點：
第一，架構的設計本就在編碼之上。編程的作用是在架構之下完成功能實現的過程，從結構上來說，架構師本就不應該做具體編碼的事情。這就像籃球教練員也可以不是運動員出身的道理是一樣的，在NBA就有這樣的例子。
第二，技術更新速度的加快促使架構師更加專注。早期的架構師為什麼可以參與一些編碼工作（寫寫接口等），因為一個技術方案可能會使用2年，但是現在技術領域的更新速度已經不允許架構師有編碼的時間了，目前的技術更新速度非常快，這就要求架構師要隨時學習這些新的知識。
第三，架構師更應該注重技術發展的趨勢。相比於能夠完成代碼編寫的工程師來說，能夠把握技術發展方向的架構師才更加專業，這樣才能設計出伸縮性較強的體系結構。所以，對於架構師來說把握技術方向，並作出驗證和判斷才是架構師更應該關注的內容。
所以，遇到不會編碼的架構師是非常正常的情況，也是互聯網行業快速發展的必然結果。
我的研究方向是大數據和人工智能，我也做過多年的架構師工作，我會陸續在頭條上寫一些關於軟件架構方面的文章，感興趣的朋友可以關注我的頭條號，相信一定會有所收穫。
如果有軟件開發方面的問題，也可以諮詢我。
IT人劉俊明
很多人都會有這樣的疑惑：架構師是從程序員做起的，不會寫代碼，還能稱為架構師嗎？其實不然，由於一些公司業務或管理方面的特殊性，確實有部分架構師只需知理論而不用寫代碼，也不會寫代碼，這類架構師更偏戰略執行層面，我們姑且就稱為戰略型架構師吧（如果稱謂有偏頗，請指正），他們的工作內容與職責通常包含如下：
1、 整合公司不同部門的資源；
2、 解決不同技術模塊整合；
3、 解決不同版本之間的兼容性；
4、 解決各個模塊的技術選型等；
5、 解決任務的分解與分解、把控進度。
戰略型架構師的工作是跟人打交道，分配任務以及解決開發過程中各種進度問題，不會寫代碼也就不奇怪了。譬如：服務甲方項目型的公司，特別看重人際關係、溝通能力、展示能力等跟客戶打交道的能力。又或者：一些軟件版本歷史包袱重的企業，由於功能型團隊偏多，在很大程度上造成了架構師能力標準的偏離，往往這些企業的技術負責人還就看重了他在技術之外的能力。
最後，回顧一個大家都知道的故事：諸葛亮揮淚斬馬謖，馬謖理論水平很高，是一個很不錯的軍師，但馬謖缺乏實踐經驗、戰場素質，只會紙上談兵，當他不用直面敵軍時，各種理論說得頭頭是道，但當他自己作為主帥出兵征戰時，這些問題分分鐘就能要他命。架構師是技術團隊的靈魂所在，能寫得一手好代碼，同時具備優秀的架構實戰經驗，以及良好的溝通能力，這樣的架構師，才是程序員心目中的“牛人”。由BAT背景架構師原創出品的【java架構師學習80期專題資料合集】，免費送給大家，助力進階成為實戰型架構師，私信關鍵詞【架構】給優知學院，立即秒領。
優知學院
既然當上了架構師，那麼至少有8-10年工作經驗，而期間至少3-4年處於底層開發，至今來說我還沒遇到不會寫代碼的架構師，就算從產品經理轉型到架構師，也多少會寫代碼，感覺你更想問的是“如何看待（公司中）不寫代碼的架構師”。
其實從架構師的職業定位和項目定位來說，架構師是不需要寫代碼的，但是一般我們鼓勵架構師深入1-2個子功能負責代碼開發。
為什麼這麼說？
整個項目週期，為什麼架構師不需要寫代碼？
這裡推薦《一線架構師實踐指南》瞭解下架構師的職責和工作內容。至於為什麼推薦它，因為是我看過所有架構師文檔中，頁數最少的，但是講的確實最精煉，最通俗易懂，最適合入門的書籍。
簡單來說，軟件架構師負責前期初步方案制定和規劃（與客戶和產品經理溝通）、需求分析、方案設計、風險評估以及整個開發週期過程中的項目把控和風險評估，及時跟進業界最新進展和（客戶）需求確認和調整，以及整個設計實現和變動，當然也必要可需要帶開發團隊對重點功能進行攻關。從中你可以瞭解，架構師其實是對代碼開發人員起到指導作用。
之前也看到公司論壇某架構師同事提到，架構師不應該寫代碼，更應該把精力放在整個架構上去。他抱怨“我整體負責A特性、B特性、C特性，同時還要與下游溝通，與客戶溝通，如果還讓我開發代碼，那除非累死我”，“架構師就做架構師的活，人的精力有限，不應該在侷限於代碼中”。你認為呢？
為什麼鼓勵架構師深入到某1-2個子功能負責代碼開發？
以上觀點其實是我從某架構書中看到（具體書名忘掉了），只是從側面提到，架構師不能只是“紙上談兵”，也要深入某項中。比如你制定了某模塊用c/c++開發，那麼你可以初步看看或者實現以下，看看c/c++是否有侷限性（性能、穩定性等），防止當時的決定，變成以後的風險。
不知道以上介紹，能不能解決你的疑問。
Hello小崔
入行十幾年和很多架構師打過交到，絕大部分的架構師在具備超強的架構能力的同時，同時還兼具強大的編碼能力，而且會的編程語言還挺多，從程序員的角度認知，架構師還是需要懂一些代碼實現的原理對於架構整體架構還是非常有好處的。畢竟程序代碼架構和代碼的實現性能息息相關，所以架構不能脫離開代碼的實現而單獨存在，當然也見過專注於框架，不去在意具體代碼的實現，可能是見識淺薄的原因，相對來講還是非常少。
當今軟件的發展分工是越來越精細，對於架構師來講安心做好框架方面的東西，不關心底層的實現在一定程度上反而有助於提升整體軟件體系結構，框架主要體現以下幾個方面
1.可擴展性，兼容性
一個好的框架在後續加入新的功能之後，可以有機的結合在一起，新的功能的增加還能和之前的舊的功能有兼容性，兩者之間不會因為新的功能的增加而引起衝突，後續再次添加新的功能不需要大範圍的改變框架，在國內很多軟件公司由於前期工期趕得比較緊迫，後面再次添加新的功能需要改動的東西非常多，導致框架的兼容性不夠，成為大家都不敢動的馬蜂窩。
2.健壯性
好的框架支持多個功能的同時不能因為功能多，導致性能的下降，這都是需要在設計之初需要考慮的事情，不能因為功能太多，導致整體系統的性能下降太多，裡面在設計的時候就需要引入共享池的概念，大家一起共用，同時採用預加載的方式提升效率問題
3.有生命力
好的框架用上幾年也不會顯得過時，有前瞻性東西，用了幾年還能不落伍繼續使用，設計之初必須考慮未來幾年負載承受能力，這樣在大規模的功能上線之後的幾年內框架還能支撐住，未來新的未知功能還能繼續支撐，這算是架構的最高境界。
滿足上述三條至於是不是有編碼能力其實已經不是很重要的事情了，相對來講懂得寫代碼在架構的時候顯得更加接近地氣，但容易思維受到限制，關鍵還是看結果。
希望能幫到你。
大學生編程指南
架構師雖然也有水平差異，但是編碼能力一定處於比普通程序員高的水平。架構師主要指責是根據公司的產品，以及產品的業務，選擇一套適合的技術體系，並且能處理最核心的部分進行搭建。
架構師寫代碼真不咋樣？
如果說架構師不會寫代碼，那是不可能的，但是他可能還真沒有年輕一代底層程序員寫增刪改查這麼熟絡，因為架構師到了一定程度只需要關注行業動態和技術藍圖，不需要去關注具體怎麼實現，他只需要關注公司能不能用微服務而不是去關注具體要怎麼配置。
架構師屬於程序員技術上的領袖，因此寫代碼這種粗話，尤其是業務代碼，工作十年八年的架構師沒準還真不如後起之秀，但是這不影響他的技術高度。
我是極客宇文氏，關注我帶了更多IT行業見解極客宇文氏
關注我，跟Z哥一起跨界學習～
如今，架構師可能已經不是你以為的“架構師”了。
在這個分工越來越細的時代，架構師這個詞都慢慢變成了一個統稱。
如果你平時有參加一些行業交流的話，可能會發現有一些面孔經常能看到。這些“架構師”title的架構師其實有不少是「ppt架構師」，這並不是一個貶義詞，也可以稱作是「佈道師」。
因為有些人掌握了一個技能後喜歡去反覆實踐、打磨，尋求新的創新。而有些人則喜歡將自己積累的知識傳遞給更多人，ppt架構師就是後者。
所以，對這些人來說，“說的明白”比“代碼寫的好”更重要。如果還能寫得一手好代碼，那是錦上添花。
還有一些架構師，就是以“實戰”為主的。專門通過自己的知識積累和思考，去制定一些開發框架。他們更看重的是，一個問題我是能解決到95分還是99分，甚至想追求100分。
對這些人來說，代碼比口才重要，因為一個好的框架自己就會說話。
但是怎麼樣的才算“會寫代碼”呢？
我認為最重要的是「抽象能力」。因為性能什麼的可以靠堆硬件，bug什麼的可以靠測試。唯獨「抽象能力」沒有一個統一的客觀標準來說好和不好，這才是真正體現「經驗」價值的地方。
缺少抽象能力會導致什麼結果呢？就好比汽車的輪胎都是圓形的，但是你所理解的竟然
是橢圓形的，然後裝上後這輛車就跌跌撞撞的開著。車主（老闆）實在受不了了，過了一段時間給全部換掉（也就是重做，不是重構哦）。
這個能力怎麼形成呢？就是通過寫大量的代碼來摸索體會其中的優缺點。因為本質上每一行代碼都是抽象設計後的產物。
所以，這個問題不能一概而論。如果是PPT架構師，那麼代碼寫的好不好不是第一位的。
但是如果是負責具體某些框架的架構師，代碼功底就很重要。而衡量一個架構師的代碼功底就看他的「抽象設計」能力，因為這個能力需要編寫大量精心思考後的代碼才能形成。
不知道你是怎麼認為的呢？
歡迎在評論中發表自己不同的觀點，與我交流哦。
z哥的思考全部傾囊相授拉，如果覺得回答對你有所幫助的話給我點個「贊同」吧，好給我一些反饋。
謝謝你的舉手之勞～
瞭解z哥更多，歡迎搜索微信公號：跨界架構師。
內容包括：架構設計丨分佈式系統丨產品丨運營丨個人深度思考。
跨界架構師
我沒遇到過不會編碼的架構師，我只聽朋友說遇到過不會編碼的架構師。
我個人的看法是：不會編碼的架構師做不出好的架構。
不過存在即合理，年底新東方的年會里火的一句話：幹活的不如寫ppt的。得到了很多人的認同。說明這個問題不只在軟件行業，在很多行業都有這種情況。
個人覺得這種架構師做不長久，現在互聯網行業還很火，等潮退了，誰穿褲子了，誰沒穿就一目瞭然了。
