如果你曾经访问过 GitHub 上的一个项目（例如），目的是了解它如何融入更大的系统，你就会体会到在初始登录页面上（或很容易从该页面访问）找到一两个图表时的解脱感。 这篇文章是关于架构的重要性，特别是图表的重要性。
我强烈支持开源，但源代码不足以使项目成功，甚至我认为，不足以成为一个真正的开源项目：你的文档不仅应该对所有人可用，而且应该对所有人可访问。如果你想让人们参与进来，提供一种进入的方式至关重要。
除此之外，我认为我们在开源方面有责任（和机会！）来实现多样性。提供图表有助于解决（至少！）四种类型的多样性：
- 母语与你的主要文档语言不同的人
- 阅读大量文本有困难的人（例如，患有阅读障碍的人）
- 更倾向于视觉思考而不是文本思考的人（像我一样！）
- 希望从不同角度（例如，安全性、管理、法律）了解你的项目的人
这篇文章的产生源于我最近参加的一次虚拟演示。 演示没有成功，但我们没有人为此感到压力：这是一个内部演示，这些事情时有发生。 这是一个我们都很熟悉的地方，当团队负责人在几张幻灯片之后，屏幕上弹出一个团队成员发来的消息说“演示 NO GO！”时，我们都为他感到惋惜。
在道歉之后，她问我们是想完全取消还是仅仅讨论他们手头的信息。 我们选择了后者——毕竟，大多数不突出用户体验组件的演示，除了终端窗口之外，没有展示太多内容，至少我们大多数人可以在半小时左右的时间里伪造出来。
幸运的是，参与演示的团队成员有很多关于它本应展示的内容的信息，并且有一个特别好的架构图可供讨论，因此尽管演示存在问题，但我们还是进行了一次富有成效的会议。 她回答了几个问题，然后我提出了一个关于安全性的问题。
这篇文章本可以写一个早期演示中展示的安全漏洞：另一个安全问题被推迟到流程后期（通常是太晚）的例子，这时集成起来既困难又昂贵。 然而，很明显，该团队已经考虑了网络（传输中）和存储（静止时）安全的具体方面。 尽管可能还有改进的空间（什么时候没有呢？），但一位团队成员在通话期间给我发来了更多文档，这让我能够理解该团队所做的一些选择。
这篇文章是关于我们能够进行讨论的事实。 幻灯片中包含了一个架构图，显示了所有主要组件，并用箭头显示了数据流的方向。 它很清晰，并且使用颜色编码来显示不同组件的来源——哪些组件来自外部项目，哪些组件来自内部项目，哪些组件是本次演示的新组件。 参与通话的人员——都是技术人员——能够一目了然地看到发生了什么，而提供描述的团队负责人对各种流程都有清晰的解释。 她的团队成员积极参与，回答具体问题或提供有关特定要点的更多详细信息。 这就是技术讨论应该如何进行的方式，有一件事特别让我高兴（除了该项目已经考虑了安全性之外！）：有一个架构图可供讨论。
世界上没有足够的安全专家可以提供帮助，这意味着并非每个项目都有机会让安全社区的成员仔细审查其设计的每个阶段。 但是当需要分享时，图表是无价的。 我讨厌想到有多少次我被要求查看一个项目并就其安全方面发表我的想法，结果发现所有可用的只是一堆代码和组件文档，没有解释它们如何组合在一起，更糟糕的是，没有架构图。
当你在构建一个项目时，你和你的团队通常都非常投入于细节，以至于你知道它们是如何组合在一起的，并且可以将它保存在你的脑海中或向同事描述关键点。 当有人需要提出不同类型的问题或从不同的角度审查架构和设计时，问题就来了。 图片——架构图——是向外部人员（或项目的新成员）介绍技术层面发生了什么的好方法。 它还具有许多额外的优势：
- 它迫使你思考是否可以用这种方式描述所有内容。
- 它迫使你考虑抽象级别以及应该在什么级别显示什么。
- 它可以揭示以前不清楚的关于依赖关系的假设。
- 它有助于显示各个组件之间的数据流。
- 它可以让你与母语不是你的主要文档语言的人进行更简单的对话。
需要明确的是，这不仅仅是一个安全问题——对于其他非功能性需求，例如高可用性、数据一致性、性能或弹性，情况也是如此——但我是一名安全人员，这就是我体验这个问题的方式。 我也意识到我有一个非常视觉化的头脑，这就是我喜欢了解新事物的方式。 但即使对于那些不倾向于视觉化的人来说，图表至少提供了一个定位自己的机会，并确定你需要深入研究代码或执行的地方。 我还认为，对于任何具有重要复杂性的系统，任何人都不可能在没有架构图的情况下考虑所有安全影响（或任何更高阶的涌现特性和质量）。 这包括设计系统的人员，因为没有系统是孤立存在的（或者没有意义），所以你不可能长时间地将所有这些部分都保存在你的脑海中。
我之前写过关于《构建进化架构》这本书，这本书在帮助项目考虑管理可以变形或改变优先级的需求方面做得很好。 毫不奇怪，这本书大量使用了架构图。 Enarx，一个我密切参与的项目，一直有很多图表，所以我意识到这里存在一些开销，既包括在设计变更时更新图表，也包括考虑为我们的文档的不同使用者提供哪些抽象，但我真的相信这是值得的。 无论何时我们向项目介绍新人或进行演示，我们都会确保至少包含一个图表（通常更多），并且当我们在演示结束时收到问题时，它们几乎总是以“请回到幻灯片x上的图表”之类的短语开头。
我敦促你创建图表，既为了你自己的利益，也为了将来会查看你的项目的任何人。 它是成为一个开放项目的关键部分——架构的开放意味着代码，从而项目本身，变得更容易访问，也更开放给更广泛的社区。 社区成员会欣赏它（你也应该如此）。 你的图表不需要完美。 但它们确实需要存在。
9 条评论