架构师需要编码？

在IT行业中按照岗位职责不一样，存在企业架构师、业务架构师、技术架构师等，由于笔者是一名Java技术架构师，我想从技术架构师来聊聊这个问题。

架构师的职责是什么？

从笔者来看，一名架构师应该是一个团队的技术担当，对团队承担的主要项目所涉及到的关键技能必须具备掌控性，当然并不是在技术的方方面面都要比团队其他成员强，因为这个实在无法做到面面俱到，技术并不是架构师需要关注的唯一点。

想成为技术担当，不能远离代码。

我相信大家在工作过程中一定存在这样的情况。例如某一天线上环境突然出现假死，业务接口无响应，但资源的消耗很低。项目组成员正在不知所措的时候，此时一名架构师过来进行指点，一套所谓的方法论直接丢过来。

系统响应慢可以查查数据库是否有慢查询、缓存是否有击穿、内存是否有溢出，并分别加以展开阐述，讲的觉得非常不错，各种技术栈的作用如数家珍，听着也觉得高大上，但听过后项目组排查的方向或者方向足够大,这样对项目组的帮助其实非常有限。

究其原因，就是这名架构师长期脱离代码，脱离一线，漂浮在上层所谓的解决问题思路上，对底层的技术原理已经严重脱节。

如果一个有经验的架构师，遇到上面的描述，在资源使用情况都很低，但项目假死，都会第一时间想到线程阻塞的问题，通常会建议项目组通过jstack等工具去查看线程栈、分析线程实际阻塞在哪行代码上，这样给项目组带来的帮助是立竿见影的，架构师的技术影响力自然而然的就会树立起来。

所以我认为作为一名架构师，不应该只飘忽在原理理论层面，还是要坚持下沉到编码层面，技术是作为技术类架构师的核心竞争力，作为一名不层脱离代码的架构师，提出的技术架构方案往往能更容易落地，能避免落人PPT架构师之嫌。

但作为一名架构师，如果眼里只有编码，一门心思只想写代码，那也是不行的。

架构师除了常规的功能性需求，非功能性需求往往是架构师重点需要关注的，例如系统的扩展性、性能、高可用性如何保证，故障应急方案，忽略了这些，一旦生产环境出现故障，整个项目组很可能会手忙脚乱，或许你很牛，能快速止血，但也只是降低影响，故障已经产生，团队的绩效必然会受到影响，故架构师理应从全局对项目质量进行把控，尽量提前预知可能发生的异常，事前进行规避。

总的来说，如果要成为一名优秀的技术架构师，不脱离编码、不脱离一线是非常有必要的，但要控制比重，做到兼顾，毕竟架构师是对项目的最终质量的第一负责人。

---

掌握一到两门java主流中间件，是敲开BAT等大厂必备的技能，送给大家一个Java中间件学习路线，助力大家实现职场的蜕变。

Java进阶之梯，成长路线与学习资料，助力突破中间件领域

最后分享笔者一个硬核的RocketMQ电子书，您将获得千亿级消息流转的运维经验。

获取方式：私信回复RMQPDF即可获取。

个人网站：https://www.codingw.net