26、软件架构：图表绘制、展示技巧与团队管理

软件架构：图表绘制、展示技巧与团队管理

1. 图表绘制工具与规范

1.1 C4 与 ArchiMate

• C4 ：C4 使用与 UML 相同风格的类图，这种类图很有效，无需替换。若公司想规范图表绘制技术，C4 是不错的选择。不过，和所有技术图表工具一样，它无法表达架构可能涉及的所有设计。C4 更适合单体架构，在这种架构中容器和组件关系可能不同；对于分布式架构，如微服务，它的适用性较差。
• ArchiMate ：ArchiMate 是一种开源的企业架构建模语言，用于支持业务领域内和跨业务领域的架构描述、分析和可视化。它是开放组织的技术标准，为企业生态系统提供了一种轻量级的建模语言。其目标是“尽可能精简”，不涵盖所有极端情况，因此受到许多架构师的欢迎。

1.2 图表绘制指南

元素	指南内容
标题	确保图表的所有元素都有标题，或者这些元素为受众熟知。使用旋转等效果使标题与相关元素紧密关联，并有效利用空间。
线条	线条应足够粗以便清晰可见。若线条表示信息流，使用箭头指示单向或双向流量。不同类型的箭头可能暗示不同的语义，但架构师应保持一致。一般来说，架构图中少数存在的标准之一是，实线通常表示同步通信，虚线表示异步通信。
形状	虽然前面提到的正式建模语言都有标准形状，但软件开发领域并没有普遍适用的标准形状。因此，每个架构师往往会创建自己的标准形状集，有时会在组织内推广这些形状以形成标准语言。通常用三维框表示可部署的工件，用矩形表示容器关系，但除此之外没有特定的规则。
标签	架构师应在图表中为每个项目添加标签，特别是当读者可能产生歧义时。
颜色	架构师通常对颜色的使用不足。多年来，书籍因必要原因以黑白印刷，所以架构师和开发者习惯了单色绘图。虽然仍然倾向于单色，但在有助于区分不同工件时会使用颜色。例如，在讨论微服务通信策略时，使用颜色来表明是两个不同的微服务参与协调，而不是同一服务的两个实例。
图例	如果形状因任何原因存在歧义，应在图表中包含一个图例，清楚地说明每个形状代表什么。没有什么比导致误解的图表更糟糕的了，这比没有图表还糟糕。

2. 架构展示技巧

2.1 时间操控

现代架构师需要具备使用 PowerPoint 和 Keynote 等工具进行有效展示的软技能。这些工具是现代组织的通用语言，组织内的人们期望架构师能够熟练使用。然而，与文字处理器和电子表格不同，似乎没有人花太多时间学习如何很好地使用这些工具。

展示工具提供了两种在幻灯片上操控时间的方式：过渡效果和动画。过渡效果用于在幻灯片之间切换，动画允许设计者在幻灯片内创建动态效果。通常，展示工具每张幻灯片只允许一种过渡效果，但每个元素可以有多种动画，如出现、消失和动作（如移动、缩放和其他动态行为）。

架构师使用过渡效果和动画来隐藏幻灯片之间的边界。《Presentation Patterns》中提到的一个常见反模式“千篇一律”指出，想法没有预定的字数，因此设计者不应人为填充内容以使幻灯片看起来饱满。同样，许多想法比一张幻灯片所能容纳的内容更大。使用如溶解等微妙的过渡效果和动画组合，展示者可以隐藏单个幻灯片的边界，将一组幻灯片拼接在一起讲述一个完整的故事。为了表明一个想法的结束，展示者应使用明显不同的过渡效果（如门或立方体效果），以提供视觉线索，表明正在转向不同的主题。

2.2 渐进式构建

《Presentation Patterns》指出，“满是要点的尸体”是企业展示中常见的反模式，即每张幻灯片本质上都是演讲者的笔记，投影给所有人看。大多数人都有过这样痛苦的经历：在展示中看到一张满是文字的幻灯片出现，然后忍不住读完所有内容，接着还要花 10 分钟听演讲者慢慢读幻灯片上的要点。

展示时，演讲者有两个信息渠道：口头和视觉。在幻灯片上放置过多文字，然后口头讲述相同的内容，会使一个信息渠道过载，而另一个信息渠道则得不到充分利用。更好的解决方案是对幻灯片进行渐进式构建，根据需要逐步展示（最好是图形化的）信息，而不是一次性全部展示。

例如，架构师创建一个展示来解释使用功能分支的问题，并想讨论长时间保留分支的负面后果。如果一开始就展示整个幻灯片，观众能看到最后会出现不好的情况，但必须等待演讲者解释到那个点。相反，架构师可以使用相同的图像，但在展示幻灯片时用无边框的白色框遮挡部分内容，然后通过对遮挡框执行消失动画来逐步展示内容。这样，展示者仍有机会保持一定的悬念，使演讲更有趣。

2.3 信息幻灯片与展示幻灯片

一些架构师使用 PowerPoint 和 Keynote 等工具创建幻灯片，但从不实际进行展示。这些幻灯片像杂志文章一样通过电子邮件传阅，每个人按照自己的节奏阅读。信息幻灯片不是用于投影展示的，而是以图形方式总结信息，本质上是将展示工具用作桌面出版软件。

信息幻灯片和展示幻灯片的区别在于内容的全面性以及过渡效果和动画的使用。如果有人像阅读杂志文章一样翻阅幻灯片，创作者不需要添加任何时间元素。另一个关键区别是材料的数量。信息幻灯片旨在独立存在，包含创作者想要传达的所有信息；而进行展示时，幻灯片（有意）只占展示的一半，另一半是站在那里演讲的人。

2.4 幻灯片只是故事的一半

展示者常见的错误是将展示的全部内容都放在幻灯片中。如果幻灯片内容全面，展示者就应该省去大家听展示的时间，直接将幻灯片作为文件通过电子邮件发送！展示者在可以更有力地表达重要观点时，却错误地在幻灯片中添加了过多材料。要记住，展示者有两个信息渠道，战略性地使用它们可以让信息更有冲击力。一个很好的例子是战略性地使用“隐形”效果。

“隐形”是一种简单的模式，展示者在展示中插入一张空白的黑色幻灯片，将注意力完全集中在演讲者身上。如果有两个信息渠道（幻灯片和演讲者），关闭其中一个（幻灯片），就会自动更加强调演讲者。因此，如果展示者想强调某个观点，插入一张空白幻灯片，房间里的每个人都会将注意力重新集中在演讲者身上，因为此时演讲者是房间里唯一值得关注的。

3. 让团队更高效

3.1 团队边界

软件架构师不仅要创建技术架构和做出架构决策，还要指导开发团队实现架构。优秀的架构师能够创建高效的开发团队，这些团队紧密合作解决问题并创造成功的解决方案。然而，很多时候架构师会忽视开发团队，在孤立的环境中创建架构，然后将其交给开发团队，导致团队难以正确实现架构。能够让团队高效工作是有效和成功的软件架构师与其他架构师的区别之一。

软件架构师可以显著影响开发团队的成败。感觉被排除在架构过程之外或与架构师（以及架构）疏远的团队，往往对系统的各种约束缺乏正确的指导和了解，因此无法正确实现架构。

架构师的角色之一是创建并传达开发人员可以在其中实现架构的约束，即“盒子”。架构师可以创建过紧、过松或恰到好处的边界。过紧的边界会限制开发团队使用有效实施系统所需的许多工具、库和实践，导致团队内部产生挫败感，通常会使开发人员离开项目去寻找更愉快和健康的工作环境。而过松的边界（或根本没有约束）会让开发团队承担所有重要的架构决策，团队在没有适当指导的情况下进行概念验证和争论设计决策，导致效率低下、混乱和挫败感。有效的软件架构师会努力提供正确的指导和约束，使团队拥有正确的工具和库来有效实现架构。

3.2 架构师的个性类型

个性类型	特点	影响
控制狂架构师	试图控制软件开发过程的每个细节。做出的每个决策通常过于细化和底层，导致对开发团队的约束过多。例如，可能会限制开发团队下载有用的开源或第三方库，坚持让团队使用语言 API 从头开始编写所有内容；还可能对命名约定、类设计、方法长度等设置严格限制，甚至为开发团队编写伪代码。	剥夺了开发者的编程乐趣，导致团队产生挫败感，对架构师缺乏尊重。在从开发者过渡到架构师时，很容易成为控制狂架构师，因为难以抗拒继续做之前开发者角色的工作，如创建类图和设计模式。
纸上谈兵架构师	很久没有编码（如果有过的话），在创建架构时不考虑实现细节。通常与开发团队脱节，在完成初始架构图后就从一个项目转到另一个项目。在某些情况下，可能对技术或业务领域力不从心，无法从技术或业务问题的角度领导或指导团队。其创建的架构图往往过于高层，对任何人都没有实际用处。	开发团队最终承担了架构师的角色，导致团队速度和生产力下降，团队对系统的工作方式感到困惑。架构师没有足够时间与开发团队一起实现架构（或选择不花时间）是陷入这种个性类型的最大标志。
有效架构师	能够提供恰到好处的边界，为开发团队提供正确的指导和约束，使团队能够有效地实现架构。	创建高效的开发团队，团队成员紧密合作，共同解决问题，实现架构目标。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B{架构师类型}:::decision
    B -->|控制狂架构师| C(创建过紧边界):::process
    B -->|纸上谈兵架构师| D(创建过松边界):::process
    B -->|有效架构师| E(创建合适边界):::process
    C --> F(团队挫败、效率低):::process
    D --> G(团队混乱、生产力下降):::process
    E --> H(团队高效、合作良好):::process
    F --> I([结束]):::startend
    G --> I
    H --> I

学习展示工具的基础知识和一些改进展示的技巧，对架构师的技能集是一个很好的补充。如果架构师有好的想法但无法有效地展示，就永远没有机会实现这个愿景。架构需要协作，为了获得协作者，架构师必须说服人们认同他们的愿景。现代企业的展示工具就像是演讲台，因此值得学习如何很好地使用它们。同时，架构师要明确自己的角色，为开发团队提供合适的边界和指导，以创建高效的开发团队。

3.3 如何创建有效边界

架构师要创建有效边界，需平衡对开发团队的约束和自由，以下是一些具体的操作建议：
1. 明确架构目标 ：在项目开始时，清晰地定义架构的目标和关键需求。例如，确定系统的性能指标、可扩展性要求、安全标准等。将这些目标传达给开发团队，让他们明白工作的方向和重点。
2. 确定核心组件和接口 ：架构师应识别系统的核心组件，并定义它们之间的接口。这些接口就像是组件之间的契约，规定了数据的传递方式和交互规则。例如，在一个电商系统中，订单管理组件和库存管理组件之间的接口，应明确规定订单创建时如何更新库存。
3. 提供技术选型指导 ：架构师可以为开发团队提供技术选型的建议，但不要过于限制。例如，推荐使用某些成熟的框架和工具，但也要允许团队在合适的情况下尝试新的技术。同时，要说明选择这些技术的原因和优势。
4. 建立沟通机制 ：建立定期的沟通机制，如周会、项目进度汇报等。在沟通中，架构师可以了解团队的进展和遇到的问题，及时给予指导和支持。同时，也让团队成员有机会反馈对架构的理解和建议。
5. 鼓励创新和自主 ：在架构的框架内，鼓励开发团队发挥创新能力，自主解决问题。例如，对于一些非核心的功能模块，允许团队采用不同的实现方式，只要符合整体架构的要求。

3.4 团队协作与沟通

一个高效的开发团队离不开良好的协作与沟通。架构师在其中起着重要的引导作用，以下是一些促进团队协作与沟通的方法：
1. 团队建设活动 ：组织团队建设活动，如户外拓展、聚餐等，增强团队成员之间的信任和默契。在活动中，大家可以放松心情，更好地了解彼此，从而在工作中更有效地合作。
2. 代码审查 ：建立代码审查机制，让团队成员互相审查代码。这不仅可以发现代码中的问题，还可以促进知识共享和技术交流。例如，在审查过程中，经验丰富的开发者可以向新手传授编程技巧和最佳实践。
3. 知识分享会 ：定期举办知识分享会，让团队成员分享自己的学习成果和项目经验。这可以拓宽团队成员的知识面，提高整个团队的技术水平。例如，分享新的算法、框架的使用经验等。
4. 使用协作工具 ：选择合适的协作工具，如项目管理工具（Jira、Trello）、版本控制工具（Git）、即时通讯工具（Slack、钉钉）等。这些工具可以帮助团队更好地管理项目进度、跟踪问题和进行沟通。

3.5 持续改进团队效率

团队效率的提升是一个持续的过程，架构师需要不断地关注和改进。以下是一些持续改进团队效率的方法：
1. 收集反馈 ：定期收集团队成员的反馈，了解他们对工作流程、架构设计等方面的意见和建议。可以通过问卷调查、一对一沟通等方式进行。
2. 分析数据 ：分析项目数据，如项目进度、代码质量、缺陷率等。通过数据发现问题和趋势，为改进提供依据。例如，如果发现某个模块的缺陷率较高，就需要深入分析原因，采取相应的措施。
3. 引入最佳实践 ：关注行业的最佳实践和新技术，将适合团队的方法和技术引入到项目中。例如，引入敏捷开发方法、自动化测试框架等。
4. 调整架构 ：根据项目的发展和团队的反馈，适时调整架构。架构不是一成不变的，需要根据实际情况进行优化和改进，以适应团队的发展和业务的需求。

4. 总结

在软件架构领域，图表绘制、展示技巧和团队管理都是至关重要的方面。

在图表绘制方面，C4 和 ArchiMate 各有其适用场景，架构师应根据具体需求选择合适的工具。同时，遵循图表绘制的规范，如标题、线条、形状、标签、颜色和图例的使用规则，可以使图表更加清晰和易于理解。

在展示技巧方面，架构师需要掌握时间操控、渐进式构建等方法，合理区分信息幻灯片和展示幻灯片的使用，并且认识到幻灯片只是故事的一半，要充分利用口头和视觉两个信息渠道，使展示更加生动和有说服力。

在团队管理方面，架构师要明确自己的角色，避免成为控制狂架构师或纸上谈兵架构师，努力成为有效架构师，为开发团队提供合适的边界和指导。同时，促进团队的协作与沟通，持续改进团队效率，以实现架构的目标。

总之，软件架构师需要不断提升自己在这些方面的能力，才能更好地推动项目的成功实施，实现软件系统的高质量交付。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B(明确架构目标):::process
    B --> C(确定核心组件和接口):::process
    C --> D(提供技术选型指导):::process
    D --> E(建立沟通机制):::process
    E --> F(鼓励创新和自主):::process
    F --> G(团队建设活动):::process
    G --> H(代码审查):::process
    H --> I(知识分享会):::process
    I --> J(使用协作工具):::process
    J --> K(收集反馈):::process
    K --> L(分析数据):::process
    L --> M(引入最佳实践):::process
    M --> N(调整架构):::process
    N --> O([结束]):::startend

通过以上的方法和策略，架构师可以更好地应对软件项目中的各种挑战，带领团队创造出优秀的软件产品。希望这些内容能够为软件架构师和开发团队提供有益的参考和启示。