架构师那些不能碰的禁忌

阅读数:9 2020 年 4 月 22 日 17:53

架构师那些不能碰的禁忌

架构师作为技术领域的顶尖战力,上能妙码生花 (代码),下能丹青栩栩 (绘图),是未来架构路线的设计师,是各项选型规范的话事人和推动人,是应对疑难杂症啃硬骨头的 119 队员,更是科技创新的开路先锋…瞧,架构师可以做如此多的事情,面对不同技术水平的团队也无需慌乱,有所侧重即可。

市面上关于架构师技能树如何点亮的分享已多如牛毛,咱反其道而行之,写写架构师容易踩的坑,大部分是我自己踩过的坑,所谓“以人为鉴,可以明得失”。另外本文观点有前提,即文中架构师是指有“真材实料”的非水货。即便这样,这群钢铁直男 / 直女仍难免犯一些忌讳却不自知,故而有此一文。
技能图谱

架构师那些不能碰的禁忌

后端架构师技能图谱

IT 界除了那两个著名矛盾:研发 vs 产品经理,研发 vs 测试,还有个隐晦的矛盾就是 架构师 vs 其他所有人,只是只有 IT 人自己才懂罢了。架构师与研发、测试、产品、业务、运维、PMO 都可能起冲突,因为在我看来,架构师既是“规则制定者”(老板),又是“规则受益者”(投资人),更是“规则参与者”(员工),三角儿合一自己跟自己玩就好了,还管你们其他人做甚?你们跟上就好。这,就是矛盾源泉。希望本文的这些小心可以最大程度化解这些矛盾吧。

忌降维打击

以架构师的专业底蕴,在团队交流协作时极易流露出降维打击姿态,特别在团队的专业能力差别巨大时尤甚。表现在言语上如:

  • “这 N 年前的过时技术 / 设计了”
  • “你没理解这个技术的底层原理”
  • “你们这个抽象考虑的过于简单了,后面架构重新出个标准化组件,你们用就好”
  • “这种实现严重违背了 XX 原理 / 定理 / 原则,建议重构”

大家感受到了没?拥有核武的架构师 与 手端 AK47 的程序员 很多时候本就不在一个水平线上,这是客观事实,但这不是架构师可以发动核打击的理由。很多时候,架构师的一两句没有同理心的表述会瞬间拉远与团队的距离,成为脱群孤雁。当然也不是说程序员都这么敏感和脆弱,但是架构师似乎特别擅长激化这种不同维度之间的矛盾。

偶有架构师跟我吐槽,某些团队水平真的太糟糕了,完全带不动啊。诚然有些程序员的素质确实让人不敢恭维,但当一个架构师流露出自己超出团队水平一大截,且团队无法有效执行自己的技术意图时,架构师就会不自觉的输出“降维“攻击。一个优秀的团队可以自驱动,可能压根不需要你这个架构师,一个普通甚至不及格的团队才能如实体现架构师的领导能力。这时架构师要做的不是“降维”攻击,而是“降维”思考,请将架构师“高高在上”的视角先拉到团队的平均线上,以此循序渐进增加难度和目标,量体裁衣获得点滴进步至少是进步,拔苗助长只会适得其反。

一来大家谁不是从 hello world 开始的,闻道有先后罢了,真不至于那么高傲;二来架构师的权威力和公信力不是也不能靠降维打击塑造起来的,而是靠每一次正确的决策、每一个正确的方案等等累积出来的。三来程序员里即便不是卧虎藏龙至少是各有所长吧,架构师动不动翻车被打脸也不算什么稀罕事,只是好不容易累积的那点权威分分钟被挥霍掉。

忌脱离业务

经过这么多年市场的摧残,应该鲜有人还会挑战这个结论吧。妄图以技术改变世界的,不出意外都被业务方爸爸给教育得妥妥帖帖。任何企业的终极使命都是活下去,要活就需要银子,要银子就得有盈利预期的商业模式。不客气点说,市面上那些逢必谈技术驱动的创业公司,大多是还没找到自己的盈利点的。因为真正的技术驱动,在我看来,从来都是为商业服务的,还真的天真到以为是为了改变世界啊?

架构师更无法超然于业务之外。如果你的设计、你的底层逻辑不是为业务预期筹划的话,不止业务方不满意,包括实施的研发团队也会不堪重负。很简单,当技术方向与业务方向不一致有夹角的话,时间越久实施团队的负担会越重,实施成本和工期也会越高,到最后必然是技术的妥协。当技术不能带来收益,什么情怀什么情结都是唬人的泡泡,一戳就破。

再说一个观点,架构师其实也是个服务行业,为业务团队更快更好的交付价值而努力,为组织将价值最大化而努力。所以架构师的目标和业务团队的目标当然应该是一致的,深入业务一线、掌握业务脉络、预测市场趋势都应该是架构师需要涉猎的,不然选择同步还是异步,用户 ID 选择 INT 还是 BIGINT 还是提前规划为分库分表的分段式设计,选择线性一致性还是最终一致性…从来都不是拍脑袋选的,而是基于用户和市场做出的当下最合理准确的判断。可以粗糙落地但必须未雨绸缪,可以未雨绸缪但不可过度谋划。

忌不计成本

自古以降,IT 都被视作成本中心,翻译下就是,IT 一个花钱部门,挣钱?那是销售和市场的事。诚然,随着国内最近几年互联网的大浪淘沙,对 IT 的投资大部分老板不太会吝啬了,就冲着程序员这种闷头干的傻劲,肯定是物超所值。但 IT 的这种“闷头干”值不值,必须有个前提就是方向对不对,而架构师就是指方向的关键人,如果指错方向的话,血本无归真不是开玩笑。简单一句话就是,身为成本中心的 IT 最应该有成本的觉悟。

让人哭笑不得的是,程序员群体里有成本意识的人少之又少,最有成本意识的可能是 CTO 或者人力外包的项目经理了吧。架构师作为追逐技术领先的扛把子,一旦沾上了追求完美的“恶习”,就会浮想联翩,这功能得上那功能也不能缺,“过度”追求超出当前业务规模和需求的技术投入。像不像双 11 的你,提前消费屯了一堆你一年可能也用不完的东西,等一年过去了,新的双 11 来了,有了更想买的东西,原来屯的可能也过期了,技术同样如此,同样有保鲜期。所以,架构师们请捂紧钱包 (成本),理性架构。

有时候未雨绸缪的铺垫性设计就好,不用全部实现到位。比如目前的业务并发量压根用不到限流,但是你可以先有一个网关应用,或者请求拦截组件,能够随时注入这个限流功能,并且对业务系统还是无感的,这就是优秀的铺垫性设计,点到即止。

在追求完美的这条不归路上,似乎架构师都变成了处女座,世界不是完美的,一直这么运转着,系统更加不是完美的,也这么运行着。因为任何好或坏的事物都会找寻那个平衡点,让其自身存在着。比如自行车就是个极端不平衡的交通工具,而我们不管怎么歪歪扭扭的骑着它就是不会摔,因为我们找到了人体与自行车之间的美妙平衡。所以,架构师追求的从来就不应该是完美的“方案”,而是完美的“平衡”:技术成本 vs 技术收益,系统化的有所取舍。

忌重复劳动

程序员,作为著名的脑力工作者,八成的时间却是在重复劳动。所谓学会增删改查,走遍 IT 都不怕。但是架构师却不能在此列,架构师确实需要有大量的经验打底,但这个底可不是用来做重复的设计或方案的,是用来以此为基础做出更多的沉淀、抽象、复用、创新、升级。

在我看来,架构师证明自己有存在价值的重要依据就是,自己和所属团队是否长期在从事重复劳动。架构师自己在重复劳动,说明缺少了创造力;团队在重复劳动,说明架构师没有为团队起到领导作用。架构师最应该是那个拿着榔头满世界找钉子的人,重复劳动不一定就是坏的但一定是有优化空间的,身为架构师要是对这颗钉子视而不见,让组织陷入重复劳动的泥潭中,架构生涯堪忧。当然还是要强调一下,满世界找钉子敲也要有个度,因为我们的上一忌就说的是成本,一个组织不可能支持你漫天开火。

一句话,当你看到了很多钉子的时候务必按耐住,找到最突出的几颗敲;当你突然看不到什么明显钉子的时候,重复劳动这颗钉子一直就在那儿等着你。

忌权威效应

权威的来源多种多样,可以是传统型的权力、宗教、等级,也可以是魅力型的才能、品格、信仰,更可能是理法型的律法、服从。架构师的权威当然更多的是来自于专业性才能,前文也或多或少提到了,架构师工作可以有效推行更多靠的是权威。当技术服你,业务认你的时候你的架构决策当然会推行的比较顺利。而当权威因为错误的决策或者无法带领团队攻克难关、突破瓶颈,而不断被损耗之后,你以后的工作可能会举步维艰,随之而来的是被挑战、被质疑甚至被无视。

我没能耐劝说你不必执着,放下再争取回来就是了,这可不是一件轻巧的事情,需要内功修炼。但换个角度说,再牛的人也有犯错或者被吐槽的时候,我等凡人也就没必要硬要伪装完人了。

最后

著名的熵增原理也就是热力学第二定律告诉我们,一个孤立的系统会不断的走向无序和混乱,直到最终消亡,组织同样如此。管理学大师彼得德鲁克说过:管理要做的只有一件事,就是如何对抗熵增。架构师的这五忌都会加速组织的熵增,在架构师的职能内核里除了专业技能就是管理,所以别以为管理与架构师绝缘。反抗熵增 (让组织有序) 的手段很多,比如注入更多的创新或者科技含量、制定合理有效的流程规范、标准化各种基础框架等等。聪明的你肯定知道怎么做,甚至可以做的比我知道的更多。

合格的架构师唯一考核指标就是,不仅受团队敬仰亦得领导垂青。做到这两点,就离成功不远了。

本文转载自技术琐话公众号。

原文链接: https://mp.weixin.qq.com/s/8wRgI3-QZNOMP8s1E81ckg

评论

发布