优秀系统架构的 5 个特点

有两本书帮助我对成为架构师的艺术有了一些理解。 我很久以前就读过它们，但我仍然时不时地翻阅它们：97 件每个软件架构师应该知道的事情，作者 Richard Monson-Haefel；以及 美丽的架构：领先的思想家揭示软件设计中隐藏的美，作者 Diomidis Spinellis 和 Georgios Gousios。

关于它们有趣的是，它们都表达了多种观点：有些是矛盾的——即使在每本书中也是如此。 这在一定程度上反映了这样一个事实，即我认为成为一名系统架构师是一门艺术或一门学科。 不同的从业者对此会有不同的看法。 你可以说计算机科学是一门硬科学，它确实有部分是这样的，但很多软件工程（有意使用小写）都超越了这一点。

我认为，对于系统架构来说，情况更是如此：一旦你了解了它，你可能就能理解它是什么，但很难指出某物——甚至是一组原则——并说，“那就是系统架构。” 有时，定义某物最简单的方法是定义它不是什么：例如，搜索“当我看到它时我就知道了，而本案中涉及的电影不是那样。”

然而，让我尝试举例说明当某人（或一群人）在做好的系统架构时，你应该期望看到的那类事物

1. 图片： 如果你无法在图片中展示系统的不同组件，我不相信你能完全描述每个组件的功能或它们如何交互。 如果你无法将它们分开，你就没有正确描述的系统，因此你没有架构。 我知道我非常注重视觉效果，但对我来说，这感觉像是必不可少的。
2. 数据描述： 如果你不知道你的系统中有哪些数据，你就不知道它做什么。
3. 实体描述： 组件、用户、打印机，无论是什么，你需要知道什么在做什么，这样你才能描述对它做了什么，以及为了什么。
4. 时间意识： 这听起来可能有点奇怪，但所有系统（任何有用的系统）都会随着时间的推移处理数据。 如果你不考虑什么会改变，你就不会理解是什么在改变，并且你将无法考虑如果事情以你意想不到的方式或由不应该首先进行更改的组件更改时可能会出现什么问题。
5. 关于故障模式的一些思考： 我之前说过，我会再说一遍：“事情会出错。” 你不能被期望想象所有可能出错的事情，但你有责任考虑如果不同的组件和数据（以及整个系统的运行）崩溃了，可能会发生什么。

当然，有一些有用的工具和方法（例如使用 UML 视图）可以帮助你完成所有这些。 但你不需要成为所有这些方面的专家——甚至任何一个方面的专家——才能成为一名优秀的系统架构师。

不过，我还要补充最后一件事，我称之为“公交车和失忆症格言”。

六个月后，你就会忘记细节或者被公共汽车撞到。 所以记录下来。 全部记录下来。

你知道这是有道理的。

本文最初发表于 Alice, Eve, and Bob – 一个安全博客，并经许可转载。