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