2022年我参加过一次技术方案评审。负责方案的程序员正在介绍自己的设计讲到一半一个架构师突然插话为什么不用消息中心的方式干嘛在代码里直接调用第三方发消息的接口当时我心里冒出的第一个判断是这是一个PPT架构师完全不了解实际情况。这类架构师知道很多业界的好实践习惯在技术评审会上说应该用这种方案抛出来的尽是脱离实际情况的想法。这句话为什么暴露了问题这里的问题不在消息中心这个方向对不对。业界确实有公司建统一的消息中心,把短信/站内信/Ding消息/订阅消息等等的发送统一起来方向本身没毛病。问题在于他不知道三件事。第一件系统里根本没有消息中心。要搞就得从零开始搭建接口协议、可靠性、监控、运维工作量成本推动接入每一样都要考虑的。这不是评审会上嘴上一句话的事。第二件从零建一个基础服务不可能塞进一个业务需求里顺便做掉。业务需求有它自己的边界和交付时间评审会审的是这个需求的技术方案不是整个系统的技术演进规划。第三件他长期不碰代码对当前系统里有什么、真正缺什么、哪些事需要专门立项去做已经没有感知了。我当时还想到一点既然他觉得消息中心这么重要为什么自己不提前规划一个真正了解系统、长期参与系统建设的架构师要么知道这件事已经在规划中要么就会主动推动立项而不是到了评审会上才随口把问题抛给做方案的程序员。架构设计的基础是对代码的了解做架构设计是需要判断和深入了解系统现在是什么状态以及下一步应该往哪里走。当前系统有什么缺什么哪里耦合严重哪些地方变化频繁留下了哪些历史包袱哪些问题需要单独立项推进。这些东西文档里往往看不到的真正有价值的信息很多都藏在代码里。比如两个模块能不能拆成独立服务是需要实际看看代码之间到底耦合得有多深共用了多少数据表有多少逻辑缠在一起。这些东西真正写过、改过、读过才能清楚的。所以架构师想保持对系统的判断力没有什么捷径就是持续写代码、读代码。你光听别人说了解到的是不全面的。架构设计建立在对现状的准确判断上而判断最终来自代码。脱离一线之后架构靠什么判断如果不再写代码也不再经常看代码架构设计还能靠什么剩下的通常就是两样东西业界的做法和过去的经验。业界的做法没有问题但那是别人根据自己的情况做出的选择。团队多大、业务怎么做、代码写成什么样、历史包袱有多少都不一样。别人适合的方案放到自己的系统里未必合适。过去的经验也是一样。经验当然有价值但经验对应的是当时的系统。几年过去了代码变了业务变了团队也变了过去有效的做法未必还适用。所以参考业界实践没有错用过去的经验也没有错。问题在于不能拿这些东西代替对当前代码的了解。还有个现象挺有意思为什么这类建议经常出现在评审会上因为对一个已经不写代码的人来说评审会可能就是他还能直接接触系统细节的地方。平时不看代码到了评审会上看到一个方案脑子里的那些经验和见闻自然就会冒出来。问题往往不是建议一定错了而是没有足够了解当前系统就开始给当前系统下结论。怎么保持对实现的感知这里说几个比较实际的做法做系统设计的人可以自己对照一下。坚持做代码评审尤其是核心模块。代码评审是了解系统变化最直接的办法很多架构上的问题光看设计文档其实看不出来。但是少发表意见多听。定期看看核心模块最近改了什么。不需要从头到尾读一遍挑改动比较多的地方看很快就能知道最近业务主要在往哪里走。新引入的技术组件自己先写个小原型。真正跑一遍之后才知道它用起来顺不顺手跟现有技术栈是不是合适。看文档和自己动手完全是两回事。参与一些关键模块的开发。多参与线上问题的排查这是了解系统现状非常好的方式。真正出问题的时候系统怎么表现、哪里最容易出问题处理过几次印象会很深刻。小结这其实不只是架构师的问题。程序员做到一定阶段都会越来越多地参与设计、评审最后也会成为那个在会上给别人提意见的人。到了这个阶段提出来的东西到底有没有用很大程度上取决于自己还知不知道系统现在到底是什么样。代码不会替你做架构设计但它会告诉你系统真实的样子。