我见过很多架构图。
颜色很丰富，箭头很有气势， 一页 PPT 打开，仿佛整个系统尽在掌握。
也见过另一种情况。
领导说：“这个系统你们画个架构图看看。” 会议室突然安静了三秒。 然后有人小声说了一句：
“要不……先画个简化版？”
一开始，我也觉得画架构图是个形式活
早些年我对架构图的理解非常朴素：
只要能“看起来像那么回事”， 就算完成任务。
直到后来，我开始频繁遇到一种尴尬场面。
“这个系统怎么改？”
需求评审会上，产品提了一个看似合理的需求。 不算大改，但涉及几个核心流程。
于是有人问了一句：
“这块改动会影响哪些系统？”
现场开始进入一种熟悉的状态：
“大概会影响到一点点 A”
“B 那边可能也要看看”
“C 不确定，要问下那边的同学”
讨论持续了十几分钟， 影响范围却越来越模糊。
于是我提了一个看似很简单的问题
“我们有没有这个系统的架构图？”
没有人正面回答。 有人翻文档，有人翻 Confluence， 最后得出一个结论：
“好像有，但有点旧了。”
后来我才发现，这不是个偶然现象
慢慢地，我发现一个非常稳定的规律：
画不出架构图的系统，通常也改不动。
这里的“画不出”，并不是不会用画图工具， 而是：
画到一半就开始犹豫
箭头不知道该怎么连
模块边界越画越模糊
最后只能靠一句话收尾：
“这个系统有点复杂。”
架构图真正的作用，从来不是“展示”
真正有用的架构图，往往很朴素。
甚至有点丑。
它的作用不是给别人看， 而是逼你把系统想清楚。
当你试图把系统画出来时，会立刻暴露很多问题：
这个模块到底算不算独立？
这条调用是必需的，还是历史遗留？
为什么这个逻辑会出现在这里？
这些问题， 你在写代码的时候，很容易选择性忽略。
有一次，架构图救了我
有一次我们准备对一个老系统做改造。
代码很多，逻辑也绕， 所有人心里都有点虚。
于是我们决定：先不写代码，先画图。
第一版图画出来的时候， 大家的反应出奇一致：
“原来是这么个结构？”
图一画出来，问题自己冒出来了
有的模块职责明显不清
有的服务承担了不该承担的事情
有的依赖关系，已经没人说得清为什么存在
这时候你才发现，真正难的不是“怎么改”，而是“从哪里开始改”。
而架构图，恰恰解决的是这个问题。
画不出来，往往不是能力问题
很多工程师会说：
“我不太会画架构图。”
但实际情况往往是：
系统的边界本身就不清晰
模块职责长期漂移
历史决策无人负责
在这种前提下， 你让谁来画，都会很痛苦。
画不出来，不是因为画图能力差， 而是系统本身已经失去了“可被理解”的形态。
架构图，是一种思考方式
后来我对架构图的态度发生了很大变化。
我不再把它当成“交付物”， 而是当成一种思考工具：
当系统要改之前，先画一遍
当讨论陷入混乱时，回到图上
当新人接手系统时，从图开始讲
哪怕这张图只存在于白板上， 存在于草稿纸上， 它的价值也远大于一页精美的 PPT。
小结
架构图不是画给 PPT 的， 而是画给系统、也画给自己看的。
当一个系统连图都画不清楚时， 往往意味着它已经积累了太多没有被正视的问题。
而当你愿意坐下来， 把系统一笔一笔画出来， 你会发现：
很多“改不动”的系统，其实是从“想不清楚”开始的。
