转载

为什么很多程序员没有升级到架构师？

作者 | 泰斗贤若如

责编 | Elle

对我们程序员来说，发展的途径要么是走管理岗，从开发升级到项目经理甚至是部门经理；要么走技术升级路线。不过在技术路线方面，无法升级到架构师的程序员不在少数。一方面，在不少公司的高级开发岗位上，无法让程序员实践甚至接触到架构师的技能，另一方面，有不少程序员甚至不清楚架构师所需要掌握的技能和升级途径。所以从结果上来看，至少有5成的程序员止步于“高级开发”的程度，这是非常令人可惜的。

我这几年一直努力地从高级开发升级到架构师，目前虽然职位上没达到，但好歹多少也能干些架构师方面的活了。在本文里，将结合我自身和其它一些程序员的经历，分析不少程序员无法升级到架构师的普遍原因，由此向大家展示从高级开发升级到架构师的难点，并在此基础上给出相关的升级建议。

很多程序员在日常工作里无法接触到架构师的技能

大多数的程序员能在工作中接触到高级开发的技术，所以从初级开发升级到高级开发，难度并不大，但架构师就不同了。

比如在外包公司里，程序员大多是做重复劳动，业务变了，但用到的技术还是增删改查。或者在一些规模比较小的公司，项目组出于成本和质量监控的考虑，也未必会让程序员从事架构方面的工作。哪怕在一些技术含量比较高的互联网公司，出于业务封装的角度，一些高并发高可用的实现往往被封装在方法里，程序员仅仅是通过调用方法实现功能，未必能在代码层面，显式地看到架构方面的技能。

接触不到相关技能，单靠看视频看资料积累起来的技能，在面试过程中往往会不堪一击，从而无法应聘架构师的岗位，这反过来制约了程序员向架构师发展的脚步。

我有时候在面试高级开发的时候，会深入问些架构方面的问题，比如我问，你们系统里，模块间的通讯用的是什么组件，不少高级开发甚至是一头雾水，或者在他们眼里，更多的是调用方法实现功能。

不少程序员往往会深挖单机版的技能

很多工作中得过且过的程序员，在实现的功能通过测试以后，或许就无所事事了，而且这类程序员不在少数，在小公司或外包公司里，这类程序员往往会更多，说实现的，他们的竞争力和从培训班里出来的程序员没什么两样，或许就更熟悉业务背景。

或者有些程序员虽然上进，但会深挖单机版的技术细节，比如我问String对象的== 和equals方法有什么差别，或者，JVM虚拟机调优有哪些实践要点，此类回答他们会回答非常到位。这固然要比纯粹会写代码的程序员要好，但此类技能顶了天只能算高级开发的技能。如果在升级时过度追求这方面的技能，无异于缘木求鱼。

列举架构师平时要干的活，确实和高级开发有差距

上文是从客观和主观两个方面，讲述了架构师升级的难处，在讲述升级方法前，我们先来看下架构师究竟要干什么活，以此来明确努力的方向。

1、需要搭建高可用的框架，比如就拿最简单的搭建数据库服务来说，得考虑如果一台MySQL服务器宕了，如何保证业务切换到另外一台机器上。
2、需要考虑高并发的因素，从这个点展开，架构师至少需要会用nginx，mycat，netty，redis之类的工具，以及考虑搭建实现负载均衡的集群。
3、需要把设计好的架构部署上线，或者哪怕上线动作是由运维来做，但架构师至少要知道如何把nginx集群等组件部署上线的活，由此架构师需要了解必须的linux命令和脚本，以及了解jenkins之类的部署工具。
4、上述技能不是简单会用即可，如果在开发部署和运行过程中由问题，架构师得负责解决。这就要求架构师不能仅仅靠看视频知道如何搭建系统，更得具备针对netty等组件的debug能力，还得能通过看日志，知道集群的运作情况，如果集群出了问题，还得知道如何快速解决。
5、不能仅仅关注技术，更得结合业务，把诸如抢红包之类的需求通过架构实现，这就要求架构师得知道各种组件的优劣，以此能选型并设计方案。

从上述对架构师的需求来看，从高级开发升级到架构师很难，也在情理中了。

从运维入手，熟悉架构师的入门技能

升级到架构师很难，但绝非不可能，对于高级开发而言，从运维入手，或许能熟悉架构师的技能。

1、比如先从ant脚本，jenkins脚本和linux shell脚本入手，能知道系统的部署方式，以及熟悉必备的linux调试技能。
2、通过观察nginx或dubbo或zookeeper配置文件，了解各组件的运作方式，并能通过这些了解高并发高可用系统里负载均衡和失效转移等配置方式。
3、可以观察线上相关的日志，了解系统部署的情况，以及从架构层面了解诸多组件间的关联。

在上述步骤里提到的脚本和日志，在平时工作中只要上点心，应该可以看到，或者我们可以和运维人员多交流请教，上述组件部署和配置的知识也不难知道。在这个过程中，暂时没涉及“修改配置”和“搭建组件”等技能，毕竟这属于熟悉阶段。

多解决实际问题，了解组件的关键配置，并了解组件的底层代码

程序员在熟悉基本的部署和架构方面的技能以后，就可以参与解决一些实际的问题了。在公司里，测试和上线阶段出现的问题不能算少，其中也会包含很多和架构相关的问题，比如kafka没配好，导致消息积压，或者dubbo超时时间配置过长，导致调用链路超时失效，或者再如redis超时时间过长，导致OOM异常。类似问题的种类五花八门，只有想不到的，没有不可能出现的。

刚开始，程序员可以跟在资深人员之后查问题，或者找到问题后，再手动复盘一下，学习架构师分析和解决问题的入手点，一来二去，一定能熟悉组件的配置，并了解组件的底层代码，更能熟悉配置各种框架组件的实施方案。

这个阶段依然属于“见习”，但至少能从实践角度，掌握架构师所需的技能。对比自己通过看视频，以闭门造车的方式积累架构师的技能，通过上述步骤得到的相关经验来源于实际，无疑值钱得多。