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的。得到了很多人的认同。说明这个问题不只在软件行业，在很多行业都有这种情况。
个人觉得这种架构师做不长久，现在互联网行业还很火，等潮退了，谁穿裤子了，谁没穿就一目了然了。
