Question

当告诉人们我到世界各地去教人软件架构和如何绘图时，得到的反应通常是怀疑或取笑。平心而论，不难看出这是为什么。软件架构的名声已经很差了，一说“大局”往往会让人想起分析瘫痪和一堆很少有人真正理解的UML图。毕竟，软件开发行业在过去十年已经有了长足发展，特别是敏捷宣言的影响以及由此催生的大量技术。

测试驱动开发与图表

测试驱动开发（TDD）是一个例子，它是那些你要么爱要么恨的技术之一。我们不讨论TDD是不是软件设计的“最佳方式”，确实有很多人使用TDD作为设计软件的方式，但它不见得适合每个人。带着写出一些生产代码之后再编写测试的观点在白板上画出一些设计的草图，这也没有错。无论布道者说什么，TDD都不是银弹。

我是一个非常视觉化的人，属于后一个阵营。我喜欢在试图找到解决方案之前，先将问题可视化。向我描述业务流程，我会勾画一个总结出来。跟我谈商业问题，我会画一个高层次领域模型。对我来说，可视化问题的一个方法是提问，搞清楚我是否明白你在说什么。我也喜欢把解决方案画出来，因为它是让一切都公开化、帮助其他人迅速理解的好方法。

为什么人们应该学习如何画草图

为什么这是一项值得人们学习的好技能？简而言之，敏捷（并因此快速行动）需要良好的沟通。画草图是在相对短的时间里传达大量信息的一个很好的方式，但这也是一项我们在软件行业中不再经常谈论的技能。这有几个原因：

1.很多团队立刻想到了UML，但他们已经放弃了把它作为一种交流方法，或者从一开始就没搞明白过。毕竟，UML显然“不酷”;

2.很多团队不再用可视化的方式来设计类，因为他们更倾向于TDD。

画草图不是艺术

我说的“画草图”就是字面的意思。我在12岁的时候被告知，如果想选择艺术作为GCSE1（高中）水平的科目注定会失败，因此很讽刺，我不会画画。但创造艺术作品的能力不是最重要的。相反，快速深入本质，以其他人能理解的方式总结要点，才是重要的。这是简单、有效和高效的沟通方式。

1General Certificate of Secondary Education，（英国面向15至16岁学生的）普通中等教育证书。——译者注

画草图不是综合模型

说明一下，我不是在谈论细节建模、综合UML模型或模型驱动开发。这是关于通过一个或多个简单的草图，有效且高效地交流你正在构建的软件的架构。这让你可以：

帮助大家理解正在构建的“大局”；

在开发团队中建立关于构建的共同愿景；

为开发团队提供一个焦点（比如，把草图贴在墙上），让开发团队里每个人都始终关注软件是什么以及如何构建；

为那些新功能应该如何实现的技术对话提供一个关注点；

提供一个软件开发者可以用来浏览源代码的地图；

帮助人们了解他们所构建的要如何融入“大局”；

帮助你向开发团队以外的人（比如，运营和支持人员、非技术的利益相关者，等等）解释正在构建的是什么；

让新加入团队的软件开发者快速上手；

为技术提供一个起点，比如风险风暴。

对于软件架构草图，我的目标是确保大家理解高层次结构，而不是类的设计细节。这是关于创建一个团队中每个人都能理解和做出承诺的愿景。语境、容器和组件图通常就够了。

画草图可以是协作活动

最后一点，草图可以是协作活动，特别是使用白板或活动挂图而非建模工具。相较于很多人努力追求的协作自组织团队的概念，这要合适得多，但也要求团队里每个人都明白如何画草图。

不幸的是，在很多软件开发团队里，绘制图表似乎已经失宠，但这是每个软件开发者必备的技能，因为它为协作软件设计铺平了道路，让集体代码所有制变得更简单。每个软件开发团队都能从几张高层次草图中获益。