美文网首页软件架构基础课
第21章 架构的绘制与演示

第21章 架构的绘制与演示

作者: 城里的月光_欧阳 | 来源:发表于2021-03-16 15:18 被阅读0次

    刚出道的架构师经常评论说,他们对这份工作在技术知识和经验之外的多样性感到多么惊讶,这使得他们能够从一开始就进入架构师的角色。特别是,有效的沟通对于架构师的成功至关重要。无论一个架构师的技术思想有多高明,如果他们不能说服管理者为他们提供资金,也不能说服开发人员来进行构建,那么他们的聪明才智就永远不会显现出来。

    绘制和演示架构是架构师的两个关键软技能。虽然每一个主题在整本书中都有提及,但我们会对每一个主题进行强调。

    这两个主题出现在一起是因为它们有一些相似的特征:每一个都是架构视觉的重要视觉表现形式,使用不同的媒体来演示。然而,表征一致性是一个将两者联系在一起的概念。

    当形象地描述一个架构时,创建者通常必须展示不同的架构视图。例如,架构师可能会展示整个架构拓扑的概述,然后深入到各个部分以深入研究设计细节。但是,如果架构师显示了一个部分,却没有指出它在整个架构中的位置,这会使查看者感到困惑。表征一致性是指在更改视图之前,始终以图表或表达的形式显示架构各部分之间的关系的实践。例如,如果一个架构师想要描述插件在Silicon Sandwiches解决方案中如何相互关联的细节,那么该架构将显示整个拓扑结构,然后深入到插件结构中,向查看者显示它们之间的关系;一个示例如图21-1所示。

    图21-1.使用表征一致性在更大的图中表示上下文

    精心地使用表征一致性可以确保查看者理解所呈现项目的范围,消除常见的混淆。

    绘图

    架构的拓扑结构总是引起架构师和开发人员的兴趣,因为它捕捉到了结构是如何组合在一起的,并在整个团队中形成了有价值的共同理解。因此,架构师应该磨练他们的绘图技巧如剃刀般锐利。

    工具

    面向架构师的当代绘图工具非常强大,架构师应该深入学习他们选择的工具。然而,在使用一个好的工具之前,不要忽略低精度的工件,尤其是在设计过程的早期。早期构建非常短暂的设计工件可以防止架构师过度依附于他们所创建的东西,这种反模式我们称之为“非理性工件依恋”(Irrational Artifact Attachment)反模式。

    非理性工件依恋

    …是一个人对某件艺术品的非理性依恋与它产生的时间之间的比例关系。如果一个架构师使用像Visio这样的工具需要花费两个小时来创建一个漂亮的图表,那么他们对这个工件的非理性的依恋与投入的时间大致成正比,这也意味着他们将更多地依恋一个四小时的图表而不是两小时的图表。

    敏捷软件开发中使用的低仪式方法的好处之一是围绕着采用尽可能少的仪式来创建适时的工件(这有助于解释许多敏捷专家致力于使用索引卡和便笺)。使用低技术工具可以让团队成员扔掉不正确的东西,让他们自由地进行实验,并通过修改、协作和讨论来揭示工件的真实本质。

    一个架构师最喜欢的变化在手机上的白板照片(连同不可避免的“不要删除!”命令)。使用连接在投影仪上的平板电脑,而不是白板。这有几个优点。首先,平板电脑拥有无限的画布,可以容纳团队可能需要的任意多幅图纸。第二,它允许复制/粘贴“如果…怎么办”场景,当在白板上完成时,这些场景会掩盖原始场景。第三,在平板电脑上拍摄的图像已经数字化了,而且不会不可避免地出现手机白板照片上的眩光。

    最后,架构师需要用一个花哨的工具创建漂亮的图表,但要确保团队已经对设计进行了充分的迭代,以便投入时间来捕获一些东西。

    强大的工具可以在每个平台上创建图表。虽然我们没有必要倡导一个工具胜过另一个(对于本书中的所有图表,我们都很高兴地使用了OmniGraffle),架构师至少应该找到这些基本功能特性:

    层次

    绘图工具通常支持分层,架构师应该好好学习这一方面的技巧。一个层允许绘图者逻辑地将一组项目链接在一起,以启用隐藏/显示单个层。通过使用层,架构师可以构建一个全面的图,但是在不需要的时候隐藏大量的细节。使用层还允许架构师为以后的演示逐步构建画面(请参阅“增量构建”)。

    模板

    模板允许架构师建立一个公共视觉组件库,通常是其他基本形状的组合。例如,在这本书中,读者看到了像微服务这样的东西的标准图片,它们作为一个单独的项目存在于作者的模板中。为组织内的公共模式和工件构建模板可以在架构图中保持一致性,并允许架构师快速构建新的图。

    磁铁

    许多绘图工具在绘制形状之间的线时提供协助。磁铁代表了这些形状上的位置上直线自动连接,提供自动对齐和其他视觉细节。有些工具允许架构师添加更多的磁铁或创建自己的磁铁,以自定义连接在其架构图中的显示。

    除了这些特定的有用特性之外,该工具当然还应该支持线条、颜色和其他视觉工件,以及以多种格式导出的能力。

    绘图标准:UML、C4和ArchiMate

    软件中的技术图有几种正式的标准。

    UML

    统一建模语言(UML)是一个标准,它统一了20世纪80年代共存的三种相互竞争的设计理念。它本应是世界上最好的,但与委员会设计的许多东西一样,未能在授权使用它的组织之外产生太大影响。

    架构师和开发人员仍然使用UML类图和序列图来沟通结构和工作流,但是大多数其他UML图类型已经被弃用。

    C4

    C4是Simon Brown开发的一种图表技术,用于解决UML中的缺陷并使其方法现代化。C4中的四个C如下:

    Context

    表示系统的整个上下文,包括用户角色和外部依赖项。

    Container

    架构中的物理(通常是逻辑)部署边界和容器。这种观点为运营和架构师形成了一个很好的集合点。

    Component

    系统的组件视图;这与架构师的系统视图最为一致。

    Class

    C4使用了UML中相同样式的类图,这些类图是有效的,因此不需要替换它们。

    如果一家公司寻求在图表技术上实现标准化,C4提供了一个很好的替代方案。然而,与所有技术图表工具一样,它也无法表达出架构可能进行的各种设计。C4最适合于容器和组件关系可能不同的单体架构,但不太适合分布式架构,例如微服务。

    ARCHIMATE

    ArchiMate(Arch*itecture-Ani*mate的混合体)是一种开源企业架构建模语言,用于支持业务领域内和跨业务领域的架构描述、分析和可视化。ArchiMate是开放组织的一个技术标准,它为企业生态系统提供了一种更轻量级的建模语言。ArchiMate的目标是“尽可能小”,而不是覆盖所有边缘案例场景。因此,它已成为许多架构师的热门选择。

    图表准则

    无论架构师是使用自身的还是正式的建模语言,他们在创建图表时都应该构建自己的风格,并且可以随意借用他们认为特别有效的表示方法。以下是创建技术图表时使用的一些通用准则。

    标题

    确保图表中的所有元素都有标题或是观众熟知的。使用旋转和其他效果,使标题与他们相关联的元素绑定在一起,并有效地利用空间。

    线条

    线条应该足够粗,以便能够看清楚。如果线条表示信息流,则使用箭头表示方向或双向信息流。不同类型的箭头可能表示不同的语义,但架构师应该保持一致。

    通常,架构图中存在的少数标准之一是实线表示同步通信,虚线表示异步通信。

    形状

    虽然所描述的形式化建模语言都有标准形状,但在整个软件开发世界中并不普遍存在标准形状。因此,每个架构师都倾向于创建自己的标准形状集,有时将这些形状分布在整个组织中,以创建标准语言。我们倾向于使用三维框来表示可部署工件,使用矩形来表示节点,但除此之外,我们没有任何特定的要诀。

    标签

    架构师应该给图表中的每一项都加上标签,特别是当读者有可能产生歧义时。

    颜色

    架构师多年来不经常使用的色彩,书籍用黑白印刷,所以建筑师和开发人员习惯了单色绘图。虽然我们仍然喜欢单色,但我们使用颜色有助于区分不同的工件。例如,在“通信”中讨论微服务通信策略时,我们使用颜色表示两个不同的微服务参与协调,而不是同一服务的两个实例,如图21-2所示。

    图21-2.以独特的色彩再现不同服务的微服务通信实例

    关键字

    如果形状因任何原因而不明确,在图表上添加关键字以明确指出每个形状所代表的内容。

    演示

    现代架构师需要的另一项软技能是使用PowerPoint和Keynote等工具进行有效演示的能力。这些工具是现代组织的通用语言,组织里的人都期望能够胜任地使用这些工具。不幸的是,与文字处理器和电子表格不同,似乎没有人花太多时间研究如何很好地使用这些工具。

    Neal,这本书的合著者之一,几年前写了一本书,名为《Presentation Patterns(Addison-Wesley Professional)》,讲述了如何采用软件世界中常见的模式/反模式方法,并将其应用于技术演示。

    演讲模式对创建一个文档和为某个案例作一场演示之间的根本区别进行了重要的观察,区别之处就是时间。在一场演示中,演示者控制一个想法展开的速度,而文档的话是读者来控制这个速度。因此,架构师在他们选择的演示工具中可以学到的最重要的技能之一就是如何控制时间。

    控制时间

    演示工具提供两种方式来控制幻灯片上的时间:过渡和动画。过渡控制在幻灯片之间的转换,动画允许设计者在幻灯片中创建移动。通常,演示工具只允许每张幻灯片进行一次转换,但每个元素可以有一组动画:飞入(出现)、淡出(消失)和动作(如移动、缩放和其他动态行为)。

    虽然工具提供了各种引人注目的效果,如铁砧从上面掉下,架构师使用过渡和动画来隐藏幻灯片之间的边界。一种常见的反模式在演示模式中被称为Cookie-Cuter,它指出创意没有预先确定的字数,因此,设计者不应该人为地填充内容,使其看起来像是填满幻灯片。同样,许多想法都比一张幻灯片大。通过使用过渡和动画的微妙组合(如“溶解”),演示者可以隐藏单独的幻灯片边界,将一组幻灯片缝合在一起以讲述单个故事。为了表明一个想法的结束,演示者应该使用一个明显不同的过渡(如门或立方体)来提供一个视觉线索,表明他们正在转移到一个不同的主题上。

    增量构建

    《演示模式》一书将弹痕累累的尸体称为公司演示的常见反模式,每张幻灯片本质上都是演讲者的笔记,投影给所有人看。大多数读者都有这样一种痛苦的经历:在演示过程中,看到一张充满文字的幻灯片出现,然后阅读整张幻灯片(因为没有人能忍住当它一出现时就去读完全部内容),只是在接下来的10分钟里,主持人慢慢地向观众朗读这些子弹。难怪这么多公司的演讲都很枯燥!

    在作演示时,演讲者有两个信息渠道:口头和视觉。通过在幻灯片上放置太多的文本,然后说本质上相同的话,演讲者是在使其中一个信息渠道过载而另一个渠道却缺乏信息。解决这个问题的更好方法是在幻灯片上进行增量构建,根据需要构建(希望是图形化的)信息,而不是一次构建所有信息。

    例如,假设一个架构师创建了一个演示来解释使用特性分支的问题,并希望讨论使分支存在太长时间的负面后果。考虑图21-3所示的图形幻灯片。

    图21-3.显示负面反模式的幻灯片的不正确版本

    在图21-3中,如果演示者立即展示整个幻灯片,观众可以看到在接近结尾时发生了一些不好的事情,但他们必须等待到演示者的解释才能意识到这一点。

    相反,架构师在显示幻灯片时应该使用相同的图像但遮盖某些部分(使用无边框白框),并依次展示其中一部分(通过在覆盖框上执行淡出),如图21-4所示。

    图21-4.一个更好的,保持悬念的增量版本

    在图21-4中,演讲者仍然有机会保持一些悬念,使演讲本身更有趣。

    将动画和过渡与增量构建结合使用,可以让演示者进行更具吸引力和娱乐性的演示。

    信息组与演示文稿

    一些架构师使用PowerPoint和Keynote等工具构建幻灯片,但从未实际演示过它们。相反,它们像杂志文章一样通过电子邮件发送,每个人都按照自己的节奏阅读。信息组是一种幻灯片组,它不是用来投影的,而是用图形化的方式总结信息,本质上是使用一个演示工具作为桌面发布包。

    这两种媒体的区别在于内容的全面性以及过渡和动画的使用。如果有人要像杂志文章一样翻阅幻灯片,幻灯片的作者不需要添加任何时间元素。信息组和演示文稿之间的另一个关键区别是材料的数量。因为信息组意味着是独立的,所以它们包含了创建者想要传达的所有信息。在做一场演示时,幻灯片(有目的地)意味着是演示的一半,另一半是站在那里说话的人!

    幻灯片是故事的一半

    演示者经常犯的一个错误是将演示文稿的全部内容构建到幻灯片中。但是,如果幻灯片很全面,演示者应该腾出时间让每个人都坐着看一个演示文稿,然后把它通过电子邮件发给每个人!当演示者能够更有力地表达重要观点时,他们会犯在幻灯片中添加过多内容的错误。请记住,演示者有两个信息渠道,因此战略性地使用它们可以增加信息的冲击力。一个很好的例子就是战略上使用隐身术。

    隐身术

    隐身术是一种简单的模式,演示者在演示文稿中插入一张空白的黑色幻灯片,以便将注意力重新集中到说话者身上。如果某人有两个信息频道(幻灯片和演讲者)并关闭其中一个频道(幻灯片),则会自动为演讲者增加更多的重视。因此,如果演示者想表达自己的观点,请插入一张空白幻灯片,在座的每个人都会将注意力重新集中到演讲者身上,因为他们现在是房间里唯一有趣的东西。

    学习演示工具的基础知识和一些使演示变得更好的技术是架构师技能集的一个很好的补充。如果一个架构师有一个伟大的想法,但却不能找到一种有效的方法来表达它,那么他们将永远没有机会实现这个愿景。架构需要协作;为了获得协作者,架构师必须说服人们认可他们的愿景。现代公司的肥皂盒是演示工具,所以很值得学习如何使用它们。


    原文参考:https://www.jianshu.com/p/d7fe0d7ecfc3

    全书翻译目录:https://www.jianshu.com/p/05711d172dfa

    相关文章

      网友评论

        本文标题:第21章 架构的绘制与演示

        本文链接:https://www.haomeiwen.com/subject/zjzrcltx.html