最近跟一个老弟聊天，他表示很想走上架构师的的岗位，今天就来聊一聊我对架构师这个岗位的理解。

下面是一个 Java 架构师岗位的招聘要求，可以作为一个参考：

工作职责：

独立进行系统或产品的设计、优化和重构；

全流程业务分析、抽象、建模；

能带领 10 人以上团队，研发过程管理，任务拆分与分配，跟进解决各种复杂技术问题；

技术选型，指导项目研发全过程；

负责核心代码编写，主导代码 Review；

负责系统性能优化，保证平台安全、稳定、快速运行。

任职要求：

本科及以上学历，8 年以上 Java 开发工作经验，有金融相关行业背景优先；

具备丰富的系统设计经验，熟悉常见的设计模式和面向对象的设计思想；

主导过 10 人以上团队参与的软件开发经验，并主导架构设计和整体技术规划；

最近一年有一线写代码的经历；

具有深厚的技术功底、广阔的技术视野、精通至少某一个技术领域；

有大规模系统重构经验者优先考虑；

有金融理财相关工作经验者优先考虑；

通过这个招聘可以看到架构师的要求还是很高的，可以说需要掌握十八般武艺。

不过岗位描述并不能百分之百代表真实的岗位要求，要知道有的公司的岗位要求是直接从其他地方复制过来的。

分享几位架构师

下面介绍我在职场上遇到的几位架构师。

架构师 A

我并没有见过本人，却给我留下了很深的印象。原因有几个：

• 留下的代码很多，基本每个系统的基础代码都是他写的；
• 代码质量很高，可以比拟 Spring 源代码，代码中对类、方法、变量的命名都精益求精，设计模式也用得非常好；
• 团队的项目开发基本都是在他写的框架下进行扩展，同事的代码风格受他影响很大。

架构师 B

能写码、能架构的技术工匠，目前在某中厂做首席架构师。虽然没有见过他写的代码，但我对他有一些了解：

• 学历背景和职场背景都非常好；
• 技术深度和广度都很好，经常给公司做一些技术分享，听了之后感觉收获颇多；
• 沟通能力强，有很强的引导力和说服力；
• 学习能力强，接收新东西快。

架构师 C

展现的技术能力比较少，但是职场背景和行业经验丰富，谈谈我和同事们对他的几点认识：

• 沟通能力比较强，不仅体现在日常沟通，遇到扯皮撕逼甩锅的事情，能够很好地应对；
• 善于项目管理，PPT 能力很强；
• 一线技术能力有点退化，基本已经脱离编码；
• 架构设计、技术选型都能胜任，不过有时感觉设计的东西有点不接地气。

架构师 D

目前是一线大厂的高 P，因为并不负责实际的项目，所以并不好评价他的能力：

• 文档能力强，经常在公司分享架构文档；
• 每个项目组的设计基本都是高开在做，所以大家认为他的产出并不高，但是这并不能说明他能力弱。产出不高并不能代表能力不强，这很有可能跟公司的体制有关系，有可能是公司没有给他产出的机会。
• 大厂的 P 级也能一定程度上说明他的能力。

架构师到底做什么

上面我列举了 4 位自己遇到过的架构师，也是比较典型的架构师。那架构师工作内容到底是什么呢？

架构设计

架构设计是多数架构师会有的工作内容，架构设计的方向也很多，比如应用系统架构、网络架构、安全架构、系统架构等。这些工作内容都需要对技术基础和系统有较好的认识，不然很难胜任。

业务梳理

有的公司是有业务架构师的，业务架构师对技术要求可能不会太高，但是对业务能力要求非常高，好多公司要求有 10 年以上本领域的工作经验。在大规模系统群的团队里，业务架构师显得非常重要，重要程度甚至超过技术大牛，要知道，一个大型项目，系统抽象的前提是已经做了很好的业务梳理和业务抽象。

技术选型和分享

技术选型工作对于新技术的引入非常关键，比如注册中心怎么选择、分布式数据库选什么技术、缓存选什么技术、消息队列选什么技术。要做出正确的选择，就必须不仅熟悉这些技术的优缺点、还是熟悉当前公司和团队的情况，比如业务场景和流量、团队规模和团队技术水平、当前团队内使用到的技术等。

对自己的选型结果，需要在公司内部做技术分享。优势也需要就公司的系统对外做技术分享。

代码编写

曾经有一个争论很久的问题，架构师要不要写代码。我见过代码能力很强的架构师，也见过不写一行代码只会坐而论道的架构师。

架构师可以不写代码，但绝对不能失去写码能力。只有写代码的过程才会感受到交付的压力和架构落地的痛点，才能在设计的时候考虑一线程序员的苦。

如果只是在一个高层次上把控架构，很容易不接地气，很容易做出鸡肋的设计，让一线程序员苦不堪言。

技术管理

有些公司要求架构师带团队和带项目，这时候就需要架构师具备管理能力了。

管理是一门大学问，方向也很多，比如项目管理、团队建设，这对一直钻研技术的架构师们绝对是一个挑战。

沟通协调

沟通协调是一门软实力，对架构师来说非常重要。比如下面的三个场景：

• 自己设计的架构和方案要说服团队成员使用；
• 团队成员因为一个设计发生了分歧，谁都说服不了谁；
• 一个团队成员非要引入一个技术，但是这个技术很可能对系统整体有影响。

学习提高

架构师需要不断提高自己，最好能做到某一技术领域或业务领域的专家级别，这样才更容易建立自己的影响力。

必要的准备

技术提升

要走向架构师，首当其冲就是提升自己的技术能力。但同时也要注意到，一个人不可能精通所有的技术。社会上能招一个同时精通前端和后端的候选人都很难。

不过最好有一两门自己精通的技术，最好是能达到源码级别，比如 Kafka、RocketMQ。对自己负责的系统，技术必须熟练掌握，至少不能有盲区。

技术不是最重要，但技术好一些能被吐槽的少点。

提升技术视野，多跟身边的朋友交流，看看其他公司的技术选型和系统建设，给自己一些参考和启发。

建立影响力

影响力太重要了，有的大佬通过影响力被推荐去做架构师。我们可以从下面几个方面尝试打造自己的影响力：

• 优秀开源项目作者、贡献者、优秀布道师；
• 公司高级职位，比如大厂高 P；
• 优秀博客主或技术自媒体人；
• 行业内资深人士，比如某领域 10 年以上从业者；
• 创业获得过投资。

软技能

程序员每天钻研技术，很容易忽略了自己的软实力，包括沟通协调能力、项目推动能力、建立信任的能力、技术分享能力、说服力。这些能力可以在平时刻意地练习。

曾经有一个架构师看了我写的代码说最好别这样,但是当我反问为什么别这样时他没能说出所以然，我也只是出于礼貌做出了修改，假如我是一个杠精，那后果会怎样。

技术上说服别人很难，往往公说公有理婆说婆有理，但尝试从下面几个方向说服对方呢？

• 不遵守设计原则：你的代码违背了里氏替换原则；
• 这一块儿代码有点乱，这是一个 xxx 场景，用 xxx 设计模式优化一下会更清晰；
• 不符合编码规范，阿里巴巴 P3C 规范有一条是这么写的；
• 代码耦合了，订单服务的业务耦合到了库存服务；
• 这样写会有效率问题，你可以使用 xxx tps 压测一下；
• 这里多线程修改一个变量会不会有并发问题，是不是应该用并发集合类。

薪资对标

这个也是必要条件，如果一个公司招聘架构师起薪是 80 万，而你目前的薪资只有 30 万，就算你技术再好，也不可能对标上去啊。

职场中兢兢业业的态度是好的，但是如果要考虑走上架构师岗位，也要关注自己的薪资，及时作出调整和选择。千万不要一味地做老黄牛。

架构经验

我面试过很多人，竟然有不少候选人工作 10 年都没有参与过从 0 到 1 的系统建设，这是非常被动的。好多公司招架构师会要求主导过从 0 到 1 的系统设计或者主导过大规模重构。

Title

在职场上，Title 是个奇怪的东西，有时候不重要，有时候又很重要。有的公司招架构师去了其实是做高级开发，有的公司招高级开发去了实际是做架构师。

Title 的作用会体现在招聘过程中。比如公司招一名架构师，在薪资能对标的情况下，候选人的简历中当前职位是高级还是架构可能会对结果有一定影响。所以如果有机会选择 Offer，其他条件差不不大的情况下 Tile 也是一个值得关注的点。

拓宽人脉

多结交圈内的朋友，靠朋友推荐很靠谱，一方面自己不容易跳到坑里，另一方面公司也很乐意接收推荐的的人才。

写在最后

刚毕业几年，觉得架构师是神一样的存在。但工作久了，我遇到过不能写代码的架构师、遇到过技术和业务都很一般的架构师、遇到顶着架构师的 Title 做项目管理的同事、也遇到过所谓的 PPT 架构师。

想成为架构师，首先要知道架构师具体在做什么，每家公司可能不尽相同，同时必须清楚自己想做的工作内容，业务方向和技术方向选一个还是都要。

最后，我分享几点心得：

• 架构师岗位远远没有想象的那么光鲜亮丽；
• 做架构师很难，你的设计很可能会被不断地 diss、吐槽，磨炼耐操的能力；
• 经常回顾和总结，看看自己的阶段性产出，如果觉得不满意，考虑下是自己的问题还是公司平台问题；
• 已经进入公司就不要太在意 Title 了，经常跟领导沟通，对齐期待，不要跑偏；
• 保持学习成长和社交。

    

使用无须实名的阿里云国际版，添加 微信：ksuyun  备注：快速云！