|
|
51CTO旗下网站
|
|
移动端

我是如何在阿里做“架构师”的?

架构是一种能力,它不是头衔。换句话说,我们需要具备架构能力,但不一定要成为架构师。就像邓公,他被称为改革开放的总设计师,但他不是设计师。

作者:从码农到工匠来源:码农到工匠|2020-06-28 08:34

架构是一种能力,它不是头衔。换句话说,我们需要具备架构能力,但不一定要成为架构师。就像邓公,他被称为改革开放的总设计师,但他不是设计师。


图片来自 Pexels

既然这样,那我们还需要架构师吗?还需要架构部门吗?我给出的答案是:不需要,因为每个人都应该是架构师。

为什么架构师不 Work?

在来阿里之前,我是在 eBay 的 payments 部门工作,当时有一个架构师叫 Scott,所有的设计和方案都需要获得他的 approve 才能通过,结果他成了整个团队的 bottleneck,很多事情都 block 在他那个地方。

工程师很难受,光是给他介绍业务和系统设计,就需要花费了大量的时间讨论(因为时差原因,经常一个讨论要一个星期才会有定论)。

他也不容易,要去理解每个系统的结构和业务细节,已经累成狗。效率低下尚且不说,这样的折腾最后带来了什么益处呢?

说实话,我现在回想起来,除了几个变量命名我觉得 Scott 说的比较有道理以外,其他还真没什么更有价值的东西了。

这里我想主要问题是因为 Scott 不在执行团队内部,他不了解细节,所以也很难给出有价值的输入。

很多东西,我们认为“他不懂”,也就是他的方案不能让我们信服,自然,合作起来就很困难。

很多人喜欢拿建筑架构和软件架构做类比,认为既然建筑需要建造师,那么软件也应该需要架构师。Too simple,too naive!

其实,二者除了都需要有图纸,都有艺术的成分之外,并没有多少共同之处。

首先,建筑和软件不同。

建筑的标准性、确定性要比软件高的多,而软件的灵活性简直是没有边界的,任何一个 function 都可以有无数的实现方式,没有定式。

因此,软件架构图的约束力,要远远低于建筑图纸的约束力。建筑如果不按照设计来,你就不能实现其功能。而软件设计文档和代码,完全可以是两个平行宇宙。

其次,建筑工人和程序员不同。

程序员的工作绝对不仅仅是“搬砖”这么简单,软件设计是一个充满挑战的创造性工作。

它需要对各种微妙之处进行权衡,只有深入其中,hands-on coding,才能真正的发现问题。

因此,飘在开发团队之上,指手画脚的 PPT 架构师,注定是很难成功的。

为什么架构部门不 Work?

如果说架构师是轻量级解决方案的话,那么,还有一个“大规模杀伤性武器”就是设立一个专门的架构组织。

几年前的 B2B 就有一个这样的架构组织。我记得在当年的“架构图”KO 会议上,当时的负责人要求我们画架构图,我就质问他这个架构组存在的意义是什么?

如果只是画架构图,给老板当 PPT 用的话,这个图我不愿意画。我当时还严厉的说了句名言——KO 不一定要 Kick Off,也可以是 Kick Out。

不止于此,而后我又“上书”到当时 B2B 的 CTO,再然后,随着 CTO 的调离,架构负责人的离职,也就没有然后了......

实际上,“架构图”这种务虚活动还好,虽然无用,但也构不成杀伤。真正构成杀伤的是架构组织不甘无为,挖空心思要“做事情”。

可以说,在业务技术部门,架构组这种“想做事”的行为是很危险的,事情越大,杀伤力越大。

何出此言?我们不妨先来看一下,在业务技术部门,架构组织能做什么?

①业务架构?

我是营销域的,是订单域的,是商品域的,是供应链域的... 你架构组告诉我,你对业务领域,业务流程,业务细节的理解比 PD、运营、工程师更懂?

恐怕难,一个合格的 PD 应该能做好业务领域的抽象和业务流程的抽象,至于细节,好像没有人比一线开发更懂。架构组,卒!

②应用架构?

需求相对清晰之后,我一个在应用架构领域尚且有一些影响力的 TL 在和团队讨论边界划分,设计方案的时候,时常会争论不休。

你一个架构组的“外人”想来指手画脚?呵呵,你这是有多低估程序员的自尊心啊。架构组,卒!

③技术架构?

好吧,那我们架构组回归技术本身,做点纯技术的事情总可以吧。对不起,但凡有点价值的技术中间件,已经有中间件团队在做了。

还记得,ICBU 架构组搞的 Hilton 容器和 AE 架构组(中间件团队)的“我行我素”使用 Spring Boot 吗?

这种重复造轮子完全没有必要。在云原生成熟之前,PandoraBoot 就是最好的解决方案。架构组,带着整个 BU 一起——卒!

在此我想稍微提一下支付宝的中间件团队(架构部门?),我不知道历史,也许 TecFin 的确是有其特殊性。

但是,从整个集团角度来说,我认为统一的技术中台,应该是更好的做法。

对一个企业来说,也许在某个特殊阶段,的确需要实体架构组织去保障落实架构工作。

但大部分情况下,特别是在技术体系已经相对完备的情况下。比如在阿里,业务技术部门,最好是不要在 BU 内设立专门的架构组织。

相信我,在我的职业生涯中,看到过很多业务技术部门设立的技术架构组织案例,基本都是以失败而告终。

人人都是架构师

架构师不行,架构部门也不行。那架构的事情谁来做呢?看一下你座位左边的,再看一下你座位右边的,再看一下你主管.... 别看了,他们是要做,你自己也要做,人人都是架构师。

首先,让我们来看一下什么是架构能力,我认为广义的架构能力,应该是一套分析问题、解决问题的方法论。

它需要你具备洞察问题本质要素,理清要素之间的关系,以及制定相应策略的能力。

从这个视角出发,我认为架构能力就是核心竞争力,每个工程师都应该具备一定的架构能力,人人都应该是架构师。

怎么理解?我认为有如下三点:

①作为技术一线员工,也许你的工作时间并不长,架构能力相对较弱,没有捷径,学习学习再学习,成长成长再成长,架构作为能力是可以习得的,没那么高深。

②作为技术团队 Leader,你必须要具备一定的架构能力了,不管是业务架构还是应用架构。

TL 都应该具备能发现问题里的本质要素,以及理清要素之间关系的能力。如果你已经是一名 TL,然而架构能力还比较欠缺,则需要尽快去补足。

不足没有关系,有关系的是停止了学习和成长。就像怀素说的,很多后劲不足的人主要是过早的停止了学习和成长,你的能力应该是围绕着你的层级震荡的,这个震荡范围偏差不会太大,迟早会归于一个相对合理的区间。

③作为 CTO(没吃过猪肉,但看过猪跑),CTO 没得选了,必须是一个非常、非常优秀的架构师才行。你不仅要熟悉业务架构,精通技术架构。

更重要的是因为屁股问题(康威定律),你还要去设计组织架构,让生产关系适应生产力的发展。唯有如此,技术才能稳定高效的支撑业务发展。

听说,腾讯没有 CTO,所以他们每个 BU 都有一套自己的技术栈和中间件,大家各自为政。

如果上图对腾讯的架构描述属实的话,我觉得最好他们还是要有一个 CTO 比较好。

因为很明显,对于通用的技术解决方案,比如大数据处理,技术中间件。没必要重复造轮子,复用很明显是更加科学的做法。

在这一点上,如下图所示,我认为阿里无疑是走在腾讯前面的。其中,数据中台和技术中台,我认为是阿里做的最好,也是最 NB 的地方。

至于业务中台为什么旁边飘着一朵小乌云呢,这是因为业务的抽象复用要比技术的抽象复用难的多的多的多,不同业务面临的业务问题的差异是巨大的,而不同业务面临的技术问题相对业务问题,要稳定的多。

我想,这也是为什么技术中台已经成功,业务中台还在探索的原因吧。

如何践行

最后,分享一下我是如何在团队做“架构师”的。

一方面,我会不遗余力的培养团队成员的架构能力,我会不断的和他们探讨系统的边界是否合理,模型抽象是否合理,流程抽象是否合理,模块设计是否合理。

并要求他们说清楚设计背后的思考和理念是什么,然后用我自己的方法论、思考和他们去碰撞,这样反复进行,我和团队都会有所成长。

另一方面,我会 hands-on coding,参与核心业务逻辑的编码工作,这点很重要。

一定要深入代码细节中去做架构,因为很多问题只有在 Coding 的过程中才会暴露出来。

另外,无谓的讨论是低效的,验证架构是否合理的方式,就是结合业务场景,写代码去验证。

设计是否合理,是否优雅,在 Coding 的过程中,便能获得很好的反馈。我不止一次,在写代码的过程中,去重构原来的设计,甚至是完全推翻重来。

总而言之,架构作为一种能力,作为我们工程师的核心成长目标,值得我们去孜孜不倦的追求。而架构师作为一个职位,在大部分情况下,它就是个“呵呵”。

作者:从码农到工匠

编辑:陶家龙

出处:转载自微信公众号从码农到工匠(ID:craftsman_frank)

【编辑推荐】

  1. 必备的三款电路图软件,太好用了!
  2. 国产化操作系统画脑图,就选这3款思维导图软件!
  3. 盘点全网最强UML图制软件,职场、面试必备!
  4. 月入百万的设计师都在用的5款“平面布置图”软件盘点
  5. 替代Matlab的国产软件出现,开发商知乎答疑,称半年实现70%功能
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢
24H热文
一周话题
本月获赞

订阅专栏+更多

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微