曾经，我幼稚地认为：只有写好代码才能对产品最“大”的贡献。什么需求分析文档，架构设计文档，没有最终的代码落地，那就是一张张的空纸。那些职位高高在上的架构师们，就也是写写胶片，画画图，他们又不懂技术细节，天天开会讨论来，讨论去都是在空谈一切。没有我们这些屌丝写的代码，你让他们去实现，估计几年也搞不出来。我写代码的能力比他们顶上N个人；再看看人家老外，60/70岁了还在码代码。为什么我国到了30岁了，都不去写代码了，都去搞所谓的架构设计了。是他们写代码写不好才去干架构师活吗？
经过这么多年在产品中挖坑、填坑，发现我们的产品是越来越复杂，但使用上也是越来越复杂，问题也是越来越难理清。我们的问题到底是出在什么地方：
- 数据不可靠，系统常出错
- 增加新需求困难，场景总是覆盖不全
- 系统之间集成各种问题难以轻易解决
- 交付不同局点，代码总是改来改去
- 每年代码量成倍增加，前辈的代码看不懂、改不动
- …
这其实是光写好代码是不能解决上述问题的。只有你经历过，感受到，才能认识到系统的架构是何其重要。作为曾经一名码农，这几年一直在设计部与架构部工作，总是羡慕那些高级别的架构师：
- 他们思考问题角度完全不同，总能高屋建瓴概括总结
- 他们思考问题比较全面，又能抽象提炼，让人快速抓住要要点
- 他们们输出的胶片、图画非常简洁，优美，明了，无二义
- 他们画出来图来指导解决集成问题，往往能一针见血地说明关键之处
- …
为什么他们的图能画得那么好，胶片写得那么牛，而我们似乎绞尽脑汁也难画出一张满意的图，难写出几张像样的胶片，是什么原因？是画得太少，写得太少，经验不足，方法不对，无灵感，还是天赋？
看到采铜老师的文章才悄然大悟：原来，不仅是因为架构师需要丰富的实践经验、敏锐的分析能力，以及系统性的建模能力，更主要的是因为：
日常我们通过文字/讲故事是线性叙述，是人和时间的结合；而画图，是人与空间结合，理有助于思维拓展