架构制图：工具与方法论( 五 )

2. 架构描述的方式

本文插图
【架构制图：工具与方法论】对于同一件事物，作家会选择用文字来叙述，而画家却会用图画。尽管两者想要传达的信息是一致的，但描述方式的不同也会带来效果上的巨大差异。架构描述也分文字（Text）和图（Diagram）两种形式，两者各有千秋：

文字的背后是由一套严谨和完备的语言作为支撑，因此其描述可以做到非常精准和详尽，而且编写起来也很方便，随便打开个记事本软件都能写；此外，就跟写代码一样，文字很易于做版本管理，借助简单的文本 diff 工具就能一目了然地对比出不同版本之间的细节差异；
相比而言，图并不具备以上文字所独有的特点，但也有自己的独特优势：图是直观而形象的，顺应了人类与生俱来的视觉识别本能；图的表达能力更强，很多时候一小张图所能传达出的信息（比如空间位置关系、颜色分类、图标形状），也许用一千行字也不足以完整准确地描述出来，即所谓“一图胜千言” 。

聪明的你冷笑了一声：哼，又不是小孩子非得做选择题，难道不可以文字与图都要吗？当然可以，理想的架构描述一定是图文并茂的。但现实世界显然比理想残酷，实际软件项目中很难给你留足时间先憋出一篇完美的架构文档。如果以成年人的思维去考虑投入产出比（ROI），那么你一定会优先选择画图。
3. 为什么你应该优先画图？

本文插图
敏捷软件开发宣言中提到：相比详尽的文档，可运作的软件更加重要（Working software over comprehensive documentation）。这么说当然不代表就不用写文档了，只是提倡没必要写过于详尽的文档。为什么？因为详尽的文档需要耗费大量的编写和维护成本，不符合敏捷开发的小步迭代和快速响应变化等原则。
那么，在如今这个全面敏捷开发的时代，如何也顺应潮流更加敏捷地编写架构文档呢？ROI is your friend —— 不求多，但求精，尽量用最少的笔墨表达出最核心的内容。从内容上来说， ROI 高的部分一般是偏顶层的整体架构或最核心的关键链路，这点在后文的 C4 模型理念中也有体现。而从形式上来说，图在文字面前具有无与伦比的表达力优势，显然是 ROI 更高的选择。
4. 为什么你需要学习画图？

本文插图
多画图是没错，但有必要专门学习吗？又不是素描彩笔水墨画，只是画一堆条条框框而已，稍微有点工程常识的都能上。画的有点丑？那没关系，顶多再动用点与生俱来的艺术美感，把这几条线对对齐那几个框摆摆正，再整点五彩斑斓的背景色啥的，不就显得很专业了嘛？
看到这里，屏幕前的你又轻蔑一笑：哼，显然没这么简单。确实，道理说出来大家都懂，架构制图与工程制图一样，都是一件需要下功夫认真严谨对待的事情。但现实中大部分人还真没这工夫去下那功夫，比如上面贴的两幅很常见的架构图。第一张图不用多说，这种草图自己涂涂抹抹挺好，但拿出来见人就是你的不对了。那第二张图呢，看上去似乎还挺像那么回事的？并不是，如果你更仔细地去揣摩，就能发现这张图底下所隐藏的很多模糊和不严谨之处（可参考这张图的来源文章：The Art of Crafting Architectural Diagrams）。
所以，能画图并不代表能画好图；要想制得一手既漂亮又可读的好图，还是需要经过持续学习与刻意练习的，很难仅凭直觉和悟性就能掌握其中的关键要领。此外，错误的图往往比没有图还要糟糕，即使你只是抱着“有图就行，差不多那个意思得了”的心态，也至少应该理解一些科学制图的关键要素，避免给本来就已经很复杂难做的项目又蒙上一层模糊滤镜，甚至起到混淆和误导的反作用。