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

发表于:2020-6-29 10:08  作者:从码农到工匠   来源:从码农到工匠

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试工程师 阿里巴巴

  架构是一种能力,它不是头衔。换句话说,我们需要具备架构能力,但不一定要成为架构师。就像邓公,他被称为改革开放的总设计师,但他不是设计师。
  既然这样,那我们还需要架构师吗?还需要架构部门吗?我给出的答案是:不需要,因为每个人都应该是架构师。
  为什么架构师不 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 的过程中,便能获得很好的反馈。我不止一次,在写代码的过程中,去重构原来的设计,甚至是完全推翻重来。
  总而言之,架构作为一种能力,作为我们工程师的核心成长目标,值得我们去孜孜不倦的追求。而架构师作为一个职位,在大部分情况下,它就是个“呵呵”。

     本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2020, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道