架构师究竟比高级开发厉害在哪?

Jaiky杰哥 2020-05-15

即将开播:5月14日,Jenkins在K8S下的三种部署流程和实战演示

架构师究竟比高级开发厉害在哪?

目前我在互联网公司里干了1年多,接触了多位技术和业务的架构师,由于我正在升级到架构师,所以能直观地感受到高级开发和架构的差距,而且,对于高级开发如何升级到架构师,本人目前更有切身体会。

本文将结合我在互联网公司的工作体验,和大家分享下架构师和高级开发在工作中的侧重点,由此能给大家带来升级到架构师的启示。

差距首先体现在工作态度上

架构师或立志升级到架构师的高级开发,平时工作中一定有如下的特质。

1. 出了问题第一时间去调查分析问题,哪怕这个问题看上去和自己无关,而不是想办法推脱问题。

2. 上班的时候,基本没时间看无关网页或手机,哪怕手头没活,也会看项目框架或看技术,或者思考如何优化。

3. 出了问题,一般会深挖,哪怕当前无法从根源解决问题,但一般会找到根源原因,而不是想办法绕过去。

这点我深有体会,别说互联网公司的架构师都这样,连表现不错的高级开发也会这样,因为要在互联网公司生存下来,这些可能是必备条件。

当然,我也见到过得过且过的,但一般上升空间都比较小,或者无法进一步提升,或者没能力竞争外面更高工资的岗位。

技术方面,架构师的基本功与高级开发的技术存货

一般的开发大多关注“单机版” 的代码,只要在本机上开发完成任务就行,然后外带些debug技能,能跟踪到代码,能使用数据库就行。

而高级开发的“高级”体现在两个地方,第一,对业务更熟悉,但话说回来,换了公司,业务值多少钱呢?第二就是对代码底层有进一步的了解,比如理解Spring Boot的启动步骤等。

而架构师的基本功要比高级开发要高些,下面来对比下我见到的架构师和高级开发的各种表现,大家从中能看出两者的差别。

1. 由于高级开发大多是调试单机版程序,所以看日志的时候,一般是在本地看,或者是用工具把日志下载到Windows本地,然后用文本工具查找关键字。

但对架构师而言,这种查日志的效率太低,大多都是用less和grep之类的命令来看,也就是说,架构师必须对linux的操作和很熟悉。

2. 高级开发一般无需考虑打包部署等问题,而架构师在优化分布式组件前,必须要打包项目。

所以架构师需要对项目打包(比如maven命令),项目部署(比如jenkins或uDeploy)还有项目质量管理(比如继承sonar)有了解,如果项目还需要部署在云平台上,可能还得了解Docker或k8s之类的工具。

也就是说,除了写代码之外,架构师还至少得了解项目的集成部署这块内容

3. 架构师更得了解组件集群等内容,比如分布式组件,云平台集群,反正不是单机版。

可能高级开发也会多少了解些Dubbo,缓存之类的组件知识,但架构师更得掌握这些组件的分布式部署相关内容,即一台机器失效了,其它热备的机器该如何顶上。

除了开发代码,架构师更得关注压测,方案评估和系统上线等实施要点

架构师多少得具备些产品的相关意识,这些意识必须始终贯穿于工作中,这块就是和高级开发相比,架构师值钱的技术了。   

1. 对于架构师而言,产品(或相关组件模块)不是做出来就好了,更得进行压力测试,压测结束后,架构师还得鸡蛋里挑骨头,锱铢必较地想优化点。

2. 架构师还得借鉴些当前的同类产品(或者是竞争产品),对性能而言,只有更好没最好,比如一个模块当前运行时间是2秒,还得想尽一切办法压缩到1秒,这就要求架构师精通各种技术。

3. 架构师更得评估各种风险,尤其是当新版本上线时,发布时候就好比一个关口,首先得保证新老代码兼容,不能导致停服,其次得控制风险,预先设计好各种基于代码或数据库的回退或处理预案, 一有风吹草动,就得立即回退。

也就是说,架构师首先得保证系统能平稳上线,其次在开发过程中,应当预先考虑到线上的各种风险,并且更得时刻考虑优化的方向,而高级开发并没有这类要求。

架构师是某一领域的主心骨,高级开发还是处于“干分配的活”阶段

架构师不仅只是技术控,更得结合业务,和相关团队合作,制定出当前可行,且实施风险较小的各类方案。

也就是说,架构师虽然不会像项目经理那样侧重于项目管理,但也需要有带人的经验,一方面把自己的设计理念让组员落实,另一方面,一旦自己分管的系统出了问题,高级开发尚可以退缩,而架构师应当责无旁贷地负责解决。

这里我列些我见过的架构师平时的一些工作场景。

1. 架构师手机上有各种群,包括业务和技术相关的,要求是@你的一定得第一时间解决。

如果客户不是@你,虽然没@,但报的问题和你有关, 也得第一时间解决,所以大多数架构师养成了手机不关,而且半夜醒来看手机的习惯。

而高级开发还可以等着架构师来分配活。

2. 出任何问题,比如业务上功能有问题,或者系统运行时出了OOM等性能问题,或者通过监控发现关键性指标下降,架构师都需要在第一时间介入。

3. 自己组内,或者别的组对自己分管领域内有任何问题,包括业务上的和技术上的,都应当是协调解决。

4. 更多的时候,架构师更得和相关人员(产品,其它组或系统运行维护人员等)开会,评估各种方案的实施方式。

在定方案的时候,每个组都会有私心,想自己组少改些,这时架构师就得协商或妥协出各类方案。

架构师在这方面的工作量甚至超过了写代码的工作量,我就经常见到诸多架构师上班时开会,下班或者周末才有自己的时间来写代码。

系统发布阶段,最能体现出架构师和高级开发的水平

在高级开发的眼里,系统发布仅仅是把最新代码和脚本部署到生产服务器上,之前我也是这样认为的。但在这个阶段,架构师需要考虑如下方面的问题。

1. 在发布的时间段里,会新老代码并存,比如灰度发布时,会切一部分流量到新代码上,这时如何保证兼容性。

2. 发布时的回滚步骤,如果涉及到数据库回滚,还得准备好各种SQL。

3. 数据清洗和数据迁移的步骤,往往上新功能后,数据清洗的范围是全局的,架构师还得考虑性能问题。

4. 系统上线后,该对那些关键步骤进行监控打点,以及打点后,提示异常的阀值该如何设置?

从中我们能看到,架构师更得掌握系统运维+性能综合调优+系统监控等能力,这块对高级开发而言,其实要求是很低的。

我见到的牛人架构师,以及他们的进阶方式

在进互联网公司前,由于我写了两本书,也接触过一些牛人,但进互联网公司后,发现第一牛人的数量比预期多很多,而且都很年轻,第二牛人在一些领域的精通程度超过我的想象。

就说我的师傅,除了工作态度好责任心强肯帮助人之类的软实力外,看日志调试代码到jar包里去debug的硬实力也厉害,更重要的,对一些分布式组件,达到了出畅销书(至少1万本)的地步。

而我师傅的师傅,更是业内大牛,不仅在Spring方面出了很多书,而且最近在极客世界里录制的视频课,目前销量就2万+了,后期估计至少5万+。

跟着牛人学,我在互联网公司里能力提升不慢,且架构方面有了一定的进步,以我的切身体会,怎么快速提升呢?

1. 当然得熟悉业务,否则没法干活,但熟悉以后不能沾沾自喜,更得看技术(尤其是值钱的技术)如何同业务整合。

如何熟悉业务?没捷径,第一看文档,第二看代码,第三问人,第四还得看自己领域外的但本系统会调用的上下文系统。

2. 出了问题别推,通过看日志等方式排查,再不行,还得深入debug一些组件包去看。

当排查问题的数量和种类积累到一定程度后,自己可能就无师自通了,我见过的一些大牛,基本上有问题就调查,从不推诿。

3. 毕竟个人的眼界有限,接触到的面也未必多,所以一定多跟牛人打交道。

请牛人帮忙排查问题时,自己一定得在旁边多看,平时更得和牛人交流,牛人们往往会给出学习的方式和学习的点,而且牛人会帮忙指导各种技术里的坑。

4. 多参与些自己领域外的工作,比如压测和系统部署,干活的时候不能仅仅停留在技术领域,更得关注项目启动,组件部署乃至项目部署等方面。

其实不少牛人不仅干过开发,更干过系统集成和系统运行维护的活,这样对分布式组件等之前的知识,就不仅仅停留在“会开发”的地步。有时候哪怕自己未必被分配到这类活,但也一定要多参与。

通过什么渠道我们能获得架构师相关的帮助文档和实践机会

1. 目前网上有大量的架构师进阶资料,包括分布式组件的,包括云计算等的,甚至有架构师相关的面试技巧的。对此,大家一定得多看带框图的,和业务实践相关的文档。

2. 一定得理论结合实际,架构师相关的文档如果光看,比较枯燥,很容易就半途而废,这点我自己有体会。

怎么结合呢?最好能去互联网公司锻炼一段时间,哪怕在其中就干高级开发的活,平时也绝对有机会接触到架构师的技能。

3. 一定得多和人打交道,小到和自己组员多沟通,中到和自己公司里相关的牛人多沟通请教,再大点范围,可以和网上的一些大牛多交流。

我体会下来,这些交流绝不会白费,除了能得到技术交流的机会外,还能掌握到一些挣钱的渠道和方法。

总结,升级到架构师,不仅仅得提升技术

确实,提升到架构师离不开技术的提升,但架构师最终是要让技术解决实际业务问题,所以在提升过程中,我更多关注的是“技术+案例”的资料,比如我会搜索“dubbo案例”之类的,以此深挖技术的落地方式。

而且,架构师还得和人打交道,这比与技术打交道难多了,因为各样的人都有。

那么升级到架构师以后,会带来哪些收益呢?

相关推荐

舍我其谁 / 0评论 2020-04-18