我眼中的架构师:一个优秀的架构师应该具备什么?

时光退回到七八年以前,那个时候“架构师“还是一个很“高大上“的title。可是在今天的互联网圈,随便一个工作了三、五年的开发人员,都可以称之为架构师。

随便多翻几个招聘网站,你可以看到:前端架构师、后端架构师、Android架构师、iOS架构师、php架构师、运维架构师、DB架构师、搜索架构师、中间件架构师、大数据架构师。。。五花八门,不一而足。

从这些岗位需求可以看出,“架构师“这个词其实是一个很“虚“的词,不同技术领域、不同行业,所要求的技能点、所侧重的能力模型是差别很大的,不是一个简单的“架构师“就可以概括的。

而本文也将谈谈我个人对“架构师“这个职位的理解:虽然不同领域要求的能力模型不一样,但个人认为,作为一个“架构师“,还是有一些共同的东西需要掌握的。

本人新书出版,对技术感兴趣的朋友请关注:
在这里插入图片描述

https://mp.weixin.qq.com/s/uq2cw2Lgf-s4nPHJ4WH4aw

格局

“格局“这个词听起来比较虚,但我举个通俗的例子:你去一个陌生的城市旅游,我想你首先需要的就是一张“地图“。这张地图定义了这个城市的“边界“,也定义了这个城市的所有地方,通过这张地图,你会对这个城市有一个“全局的了解“。

而这种“全局的视野“,不是说架构师才需要,换做其他职位、其他行业,同样的道理。做产品经理,需要对产品有“全局视野“;做运营,做市场,需要运营、市场相对应的全局视野;做技术,需要技术相关的全局视野。

说了这么多,可能还是比较“虚“,我就举个例子来说明到底什么叫“全局视野“,比如你现在负责开发一个新系统,你可能需要去理解下面这些关系到“大局的问题“:

这个系统的定位是什么?它能创造什么核心价值?

做这个系统的背景是什么?-- 为什么以前不做,现在要上?是因为业务发展到了一定规模?还是开发资源现在有多余,没事可干?

这个系统在整个组织架构中,处于什么位置?跟这个系统关联的其它系统目前什么状况?

产品经理如何看待这个系统?技术老大如何看?

这个系统的需求,是处于比较确定、比较清晰状态?还是有很大灰度空间?很多核心点,大家还没想清楚?

这个系统所用的技术体系,是比较老?还是最新的?

业界类似的系统,人家是如何做的?

。。。

关键点:上面随便举的这个例子,并没有标准答案,我想表达的是,一个有“大局观“,一个有“格局“的人,在做一件事情之前,要对所做的事情有一个“全局把握“,风险在哪?挑战在哪?提前要有心理准备!

最后再多说一句:“格局“是有层次的,国家总理在“国家“这个层次思考,CEO在行业、“公司“这个层次思考,业务线负责人在他所负责的那个“业务“层面思考,技术老大可能主要在“技术层面“思考,产品老大在“产品层面“,到了最下面,写代码的,在“代码“这个层面思考。

不同层次的人,聚焦的范围大小不一样。可如果你能把你的“范围“往外扩一圈,这对你做自己的“本职工作“会很有好处。

而这,在我看来就是“格局“。

历史观-技术血脉

如果说“格局“是从空间的角度去看待问题,那么“历史观“就是从时间的角度去看。

任何一种技术,都不是谁吃饱了没事干凭空想象出来的,它一定是要解决某个特定问题。而这个特定问题,一定有它的历史背景:是因为之前的技术,在解决这个特定问题上,解决的不够好、或者有其它副作用,所以才发明了这个新技术。

所以,看待一个技术,一个方法论,需要把它放到“历史长河“中,去看它在历史中,处于什么位置。

推而广之,何止是技术,任何其他学问,何尝不需要“历史观“?说个更专业点的哲学名词,就这是所谓的“历史唯物主义“吧!

抽象能力

同“格局“一样,“抽象能力“又是一个很“虚“的词。可作为架构师,就是需要这种“务虚思维“。

抽象也是一个“层次“结构,从最底层到最上层,不同工作阶段,你需要在不同抽象层级进行思考。

很多写代码的人,都比较习惯“自底向上“的思维方式。当你跟他讨论需求的时候,他首先想的是这个需求如何实现,而不是这个需求本身是否合理?这个需求跟其它需求有什么关联关系?

这种过早考虑“实现细节“的思考方式,会让你“只见树木,不见森林“,最终淹没在茫茫的各种细节之中,层次混乱,把握不住重点。

同样拿上面的例子举例,假如让你做一个新的系统,那么从“抽象“到“细节“,你可能需要考虑:

每个需求的合理性?

这个系统的领域模型是什么样的?

这个系统是应该在旧的上面改造?还是应该另起炉灶?

这个系统可以分成几期,分期实施?

这个系统要拆分成几个子系统?

每个子系统又拆分出多少个模块?

系统的表设计?api接口设计?job的设计?系统之间的消息传输?

。。。

从上到下,是一个逐级细化的过程,并且进入到下1级之后,上1级可能又会退回去修改。

深入思考的能力

深入思考能力,这里主要指“技术“的深度。关于“广度“,在上面的“格局“这个层面已经包含。

“深度“不是说,你要在所有领域都很深。人一生的精力是有限的,你不可能对所有技术领域都很深,但你需要1个比较深的领域。

这种深度,并不代表你当前的工作就需要这个技术领域,而是说这种“深入思考的方式“,会让你在思考其他问题时,也会带着这个“习惯“。

这个东西很重要,因为技术一直在更新换代,当你面对一个新技术的时候,如果你有深入思考的能力和习惯,那你对新技术的理解往往也就很透彻。

同时,“深度“会让你对“技术风险“有更加清醒的认知,你做一个项目的时候,这里面潜在的“坑“,你可能会提前发现,而不是等做到那了,发现问题了,被迫思考。

架构的落地

任何的架构必须可以落地,可以实现。不能落地,只能停留在ppt上面的架构,那只能忽悠人。这种架构,对实际不仅没有指导作用,还会有反作用,对实际开发产生误导。

而一个架构师,应该跟踪从架构设计到架构落地到完整过程,“理论“到“实际“必然是有间隙的,跟踪这个过程,实时修正,才可能真的做到“理论“与“实际“的统一。

业务架构 vs. 技术架构

业务架构和技术架构通常是2个不同的侧重领域,业务架构强调的是对“领域“的深刻理解,这通常和“领域专家“密切相关,这里可能会强调系统的“可扩展性“,“可复用性“,对需求的弹性应对;

技术架构,需要对底层技术有足够的把控,这里可能会强调系统的“高性能“,“高并发“,“高可靠“等。

业务架构和技术架构并不是相互独立的,一般都是“业务驱动技术“,2者在互相促进中,同时往深度、广度上发展。

组织架构与领导力

再复杂的系统,都是“人“开发出来的。而人多了之后,“人“相关的问题都会自然产生:沟通不充分、组织混乱、职责不清。。。

作为一个架构师,一般很难“独善其身“,说我只管“技术“,不管“人“。因为你的工作,是一个“团队“完成的,而不是一个“千里走单骑“的英雄。

所以熟悉整个组织架构,沥青职责,把各种混乱的流程、协作理顺,也是应该考虑在内的。

总结

说到现在,你会发现,我可能说的并不是一个“纯粹的架构师“。的确如此,上面这些是我认为作为一个“技术人“,应该去不断修炼的东西,而不是光“架构师“需要。

展开阅读全文

没有更多推荐了,返回首页