架构师那些不能碰的禁忌

架构师作为技术领域的顶尖战力，上能妙码生花(代码)，下能丹青栩栩(绘图)，是未来架构路线的设计师，是各项选型规范的话事人和推动人，是应对疑难杂症啃硬骨头的 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