架构师应该多维度多视角地思考 - Gregor

22-04-29 banq

程序员是无到有构建代码,应该注重组合思维,做出来的东西需要能够相互组合在一起;而架构师是从上而下的视角,因为不参与具体细节构建,但为了落地,应该具有多维度多维度视角,从程序员到架构师思维转变很重要,下面是原文摘要:
一个人能看得更多不仅意味着要有更好的视力,还意味着能看到更多的维度。想象以下情况:



两个人正在争论一个物体的形状。一个人一直声称它是一个矩形,而另一个人坚持认为它是一个圆形。讨论一直在进行:“矩形!”、“圆形!”、“来吧,它有 4 个角!”、“什么?它就像它得到的那样圆!”。因为圆形和矩形实际上是完全不同的形状,所以看不到和解。双方都是聪明人,排除了缺乏理解是他们争吵的原因。一位建筑师进来并注意到他们都在看同一个物体:一个圆柱体。

从侧面看圆柱体的人会准确地看到一个矩形。同样,从顶部看同一个物体的另一个人也清楚地看到了一个圆圈。只要每个参与者都保持自己的观点,他们就可以争论很长时间。这就是为什么软件先驱Alan Kay 有一句名言:

“一个观点的改变值得 80 点智商。”
这是一个强有力的声明,但也是一个很大的解脱。

建筑师不必是房间里最聪明的人。相反,他们让其他人更聪明。

架构是一个视角问题
IT 处理巨大的复杂性:在庞大的系统数量之下,存在如此密集的相互依赖关系网络,如果蝴蝶扇动翅膀导致飓风或系统中断,您不会感到惊讶。

我们通过使用简化的模型或预测来应对这种复杂性。流行的4+1 架构视图模型就是一个典型的例子。为了推理和描述应用程序的架构,该模型提出了以下视图:

  • 逻辑视图通常通过类图描述系统的功能结构。
  • 过程视图描述了系统的过程和行为,例如通过状态图。
  • 开发视图说明了软件模块。
  • 物理视图描述了如何将软件工件部署到基础设施资源,例如服务器。
  • 场景通过将用例映射到其他视图(因此 +1)来验证设计。

这些视图在系统上放置不同的镜头或过滤器,以便更容易描述系统的结构和行为。然而,我们必须提醒自己,这些预测中的每一个都是对底层系统的巨大简化。视图的存在主要是为了让我们更容易理解系统。

模型的力量和危险
架构师在模型中思考——这就是他们处理复杂性并做出更好决策的方式,而不是仅仅跟随他们的直觉或倾听最响亮的人。

上面的视图是模型。但是,模型是简化的,我们很清楚所有模型都是错误的(请参阅The Software Architect Elevator)。

一般来说,没关系,模型无法匹配现实,因为那样它们就不会抽象事物或降低复杂性。

你选择的模型会影响你的想法。您需要简单但不简单的模型。

在过去,地球被认为是大多数事物的中心,导致地心模型。这个模型适用于太阳的运动,但除非你试图创造抽象艺术,否则行星的运动相当复杂且难以解释。然而,这种模式在很大程度上受到宗教学者的青睐。

在 IT 中,这将是由象牙塔架构师定义的参考架构,他们更满足于满足特定的结构规则而不是系统的实际行为(随意将“地球”替换为“核心系统”)。

哥白尼一定看到这个模型有问题,并推导出了一个将太阳置于中心的替代模型,恰当地称为日心说。在这个模型中,行星的运动显得更有条理和合理。您可以将哥白尼视为变革推动者,他提出了诸如运行其他人的软件是一件坏事这样的异端思想。

多维度
因此,我们上面的圆柱体故事涉及使用不同模型的两个人。就像哥白尼和他的前辈们观察天空中行星的相同运动一样,他们对所看到的东西有着截然不同的想法,就像圆形和矩形一样。而且由于人们的观点植根于二维,同一物体可以有不同形状取决于你看它的角度的想法对他们来说似乎很陌生。

架构师依赖模型和预测,但意识到它们植根于同一个底层系统。
架构师喜欢模型和投影,但他们意识到投影并不是孤立存在的——它们植根于同一个底层系统。这就是为什么建筑师倾向于较少陷入圆形与矩形辩论的原因。

人体维度
与许多其他架构主题一样,维度不仅适用于技术系统,也适用于组织系统。

对话可能会像圆形与矩形辩论一样容易陷入困境。一个很好的例子是关于团队自治与一致性的讨论。大多数经理认为,给予团队更多的自主权意味着他们在地图上到处都是,即不是很一致。因此,他们认为他们必须在一个和另一个之间做出选择——圆形或矩形,但不能同时选择两者。

Spotify 已经意识到,让自治发挥作用的原因实际上是一致性,正如他们的一个工程文化视频中所展示的那样:




Stephen Bungay 的优秀著作《行动的艺术》很好地解释了对齐的需要作为自治的先决条件,而不是相反。组织架构师也看到了圆柱体。
 

1
猜你喜欢