技术

尽管 生产路径图 自从持续交付被编著时在Thoughtworks就是一种近乎普遍的实践，但是我们经常会遇到一些不熟悉生产路径图实践的组织。这一活动经常由一群跨功能团队的人——包括参与设计、开发、发布与运营软件的所有人——在工作坊中完成，他们围在同一张白板前面（或者是一个虚拟的等价物）。首先，按照顺序把流程的步骤罗列出来，从开发阶段一直到发布上产的所有路径。然后，主持一个会议来获取更多的信息和痛点。我们最常见的技术是基于价值流图，尽管有很多具有同等价值的流程图变种。这项活动经常会让参与者眼界大开，因为他们识别出了延迟，风险和不一致的地方，并且可以用可视化的陈述来持续改进构建和部署的流程。我们认为这是一项很基本的技术，所以当我们发现在之前的技术雷达中我们没有提到它的时候，我们感到非常惊讶。

在为组织重新设计业务敏捷性和交付速度时，团队交互是一个关键概念。这些交互将反映在正在构建的软件中（参见康威定律)，并表明团队可以如何有效地自主为客户提供价值。我们的建议是关注团队的设计和互动方式。因为我们相信组织设计和团队交互会随着时间而发展，所以我们认为衡量和跟踪 团队的认知负载 尤为重要，这可以让你理解团队构建、测试和维护其服务的难易程度。我们一直在使用一个模板来评估团队的认知负载，该模板基于高效能团队模式（Team Topologies）作者的想法。

在与客户沟通和重新设计组织时，应用本书的概念所产生的积极影响给我们留下了深刻的印象。作者推荐了一种简单但强大的组织设计方法，仅确定四种类型的团队和三种交互模式；这有助于减少组织内的歧义，并为团队、利益相关者和领导层提供一个通用词汇来描述和设计团队的工作。为了实施组织设计变更，我们设计了理想的未来团队拓扑结构，应用任何技术/人员限制（即员工不足），然后形成最终的结构。这使我们能够更好地为客户提供建议，并通过比较现有/未来的团队结构来预测我们是否确实在改善认知负载。

我们继续推荐团队实施威胁建模——一系列有助于在开发过程中发现潜在威胁并对其进行分类的技术——但是我们想要强调的是，这件事不是只在项目开始时做一次就能一劳永逸的，团队需要避免 security sandwich 现象。这是因为，在任何软件的整个生命周期中，由于外部事件以及需求和架构的调整，可能会出现新的威胁，而现有的威胁将继续发展。这就意味着，威胁建模需要定期重复——重复的频率视情况而定，需要综合考虑诸多因素，例如执行的成本和对业务的潜在风险等。如果结合其他技术使用，例如建立跨功能的安全需求来发现项目所采用的技术有什么公共风险，以及使用自动化安全扫描，这时威胁建模将变得非常有用处。

自我们上次在技术雷达中谈到 BERT （来自变换器的双向编码器表征量）之后, 我们团队已经成功地在一些自然语言处理 (NLP) 项目中使用了它。在其中一个项目里，当我们把默认的 BERT 分词器换成一个经过领域训练的词块 (word-piece) 分词器，再去处理那些含有品牌名称或者维度之类名词的查询任务时，我们看到了显著的改进。虽然 NLP 有一些新的转换模型，但 BERT 凭借优秀的文档以及活跃的社区支持，更加通俗易懂，而且我们也一直发现它在企业级 NLP 背景下非常有效。

视觉回归测试是很有用的强大工具，值得被您收进工具箱。但是在整个页面上使用视觉回归测试的成本非常高。我们看到随着 React 和 Vue 等基于组件的框架逐渐兴起， 组件视觉回归测试 也越来越流行。这项技术能确保在应用程序中不会引入非必要的视觉元素，从而很好的维持了投入和产出之间的平衡。在我们的实践里，组件视觉回归测试很少误测，而且有助于改善架构风格，通过和 Vite 以及 webpack 的 模块热替换 (HMR) 功能共同使用，还可以视之为测试驱动开发应用于前端开发领域的范式转变。

当面临如何跨多种尺寸设备和平台一致地使用设计系统的挑战时，Salesforce 的团队提出了设计令牌这个概念。令牌将诸如颜色和字体等值存储在一个中心位置。这使得将选项与决策分开成为可能，并且显著改善了团队之间的协作。设计令牌并不是新事物，但随着 Tailwind CSS 和 Style Dictionary 等工具的引入，我们看到设计令牌被更频繁地使用。

使用真实电子邮箱的测试账户，或使用 SMTP（简单邮件传输协议）服务器进行测试仍然是较为常见的软件测试方法。 然而，使用真实的服务进行测试会带来测试邮件将被发送到真实的人的风险，也常常会使自动集成测试变得复杂。 我们完全可以使用 虚拟 SMTP 服务器来测试邮件发送 ，它记录了发送电子邮件的请求，但并没有实际发送。 在这个领域存在多个开源工具，比如 fake-smtp-server，它提供了 Web UI 来展示邮件，便于可视化测试；以及 mountebank，它提供了 REST API 来获取已发送的邮件，便于集成测试。 我们建议探索这种技术，以减少风险，提高测试效率。

我们看到许多客户项目正在使用 联邦学习 (ML)。传统上机器学习模型训练时需将数据放在集中运行模型训练算法的地址。在隐私角度上，这存在问题，特别是当训练数据包括敏感或者可用于身份识别信息时；用户也许不愿意分享数据，当地的数据保护法律也可能不允许我们将数据转移至一个中心化的位置。联邦学习是一个去中心化的技术，它使模型可以在大量不同来源的数据集上训练，并让数据保持在远端，例如用户的设备上。尽管网络带宽和设备的算力限制目前仍是这项技术重大的挑战，但是我们喜欢联邦学习的思路，让用户可以完全控制自己的个人信息。

自从2017年以来，我们几乎每一期技术雷达都写过关于开发人员平台以及如何构建它们的内容。与此同时，团队拓扑学这本书还很好地描述了一个理想的平台，即用“自服务的 API、工具、服务和知识”来支持开发人员。然而，我们经常看到团队对于实现这种平台的愿景操之过急。事实上，构建一个 增量开发平台 才是关键所在。

团队拓扑学建议在任何特定阶段，都努力去实现一个所谓的“最小可行平台”，这个平台的第一版甚至可以是一系列的 wiki 文档。下一个增量可以通过提供模版或允许成员创建请求来提高服务水平。进一步的增量可以引入自服务 API，但前提是有价值。简而言之，尽管我们小心地反对全量工单驱动的平台运营模式，但从零到自服务是另一个极端。调整你自己的步调，将产品管理思维应用于内部平台 并逐步增量地建立它。

自从 2016 年在技术雷达中介绍微前端以来，我们已经看到 Web UI 广泛地采用它们。然而，最近我们看到一些项目把这种架构风格也拓展到了 移动微前端 。当应用程序变得足够庞大与复杂时，就有必要将开发工作分配给多个团队。这提出了围绕团队自治、仓库结构与集成框架的许多挑战。过去，我们提到过 Atlas 与 BeeHive，但是这些框架未能获取关注而且也不再处于活跃开发状态。最近的方法包括用于将多个团队的工作集成到单个应用程序中的 Tuist 或 Swift 包管理器。但根据我们的经验，团队最终经常会实现自己的集成框架。虽然我们毫无疑问看到了在扩充移动开发团队规模时对模块化的需求，但是对微前端的需求却不太确定。这是因为尽管微前端意味着团队与页面或组件之间的直接对应关系，但是这种结构却有可能最终导致业务领域上下文的职责模糊，由此增加团队认知负载。我们的建议是遵循良好、整洁的应用程序设计，当规模扩大为多个团队时采纳模块化，仅当模块与业务领域高度对齐时才采用微前端架构。

可观测性实践已经将对话从监测通俗易懂的问题转换为帮助解决分布式系统中的未知问题。通过应用 CI/CD 流水线的可观测性 ，我们已经看到在传统生产环境之外采纳这种立场以帮助优化测试与部署瓶颈的成功。复杂的流水线会在运行太慢或遭受非确定性影响时给开发者带来摩擦，进而减少关键反馈循环并且阻碍开发者效率。此外，它们作为关键部署基础设施的角色在快速部署周期中产生了压力点，就像一些组织在应对最近的 log4shell 漏洞时所发生的那样。追踪的概念能够很好地转移到流水线上：子跨度抓取构建每个阶段的信息，而不是抓取服务调用级联。在分布式架构中用于分析调用流的瀑布图同样可以有效地帮助我们识别流水线瓶颈，甚至是那些扇入扇出的复杂流水线。这使得针对性大幅提高的优化工作成为可能。 尽管此项技术适用于任何追踪工具，但是 Honeycomb 支持一个名为 buildevents 的工具，其有助于抓取流水线追踪信息。一种替代方案，即抓取已经由 CI/CD 平台暴露的信息，由 buildviz （由一位 Thoughtworker 构建并维护）采纳，允许在不更改步骤配置文件自身的情况下进行相似的调查。

随着软件复杂性的不断增加，软件依赖项的威胁路径变得越来越难以守护。软件工件供应链层级，又称 SLSA（读作 “salsa”），是一个由联盟组织策划的，为组织机构提供防范供应链攻击的指南集。该框架衍生于一个 Google 多年来一直使用的内部指南。值得称赞的是，SLSA 并没有承诺提供“银弹”，即仅使用工具确保供应链安全的方法，而是提供了一个基于成熟度模型的具体威胁和实践的清单。这个威胁模型是很容易理解的，其中包含了真实世界发生的攻击实例，并且要求文档中也提供了指南，帮助组织基于日渐增强的稳健性水平为其行动措施排定优先级，以改善他们供应链的安全态势。自我们第一次在技术雷达中提到 SLSA 以来，它已经通过示例，围绕软件认证增添了很多细节，以跟踪如构建出处等问题。我们的团队发现 SLSA 在具体执行指导和更高层次对供应链威胁的认知之间取得了良好的平衡。

在保障系统安全性的压力不变且总体安全威胁不减的情况下，一个机器可读的 软件物料清单 （SBOM）可以帮助团队掌握他们所依赖的库中的安全问题。随着美国总统令的发布，业界对 SBOM 的概念和如何创建 SBOM 都有了清晰的认识，例如国家标准与技术研究院（NIST）也针对如何执行总统令提出了更详细的建议。现在我们已经具备了在项目中使用 SBOM 的生产经验，项目范围从小型企业到大型跨国公司，甚至是政府部门，而且我们确信它能为我们提供益处。更多的机构和政府部门应当考虑索取正在使用的软件的 SBOM。随着 Firebase Android BOM 等可以自动罗列应用软件 BOM 中依赖库的新工具的不断出现，这项技术也将持续强化。

可持续发展是一个需要企业持续关注的话题。在软件开发领域，可持续发展的重要性日益显著，并且我们也可以看到出现了很多不同的达成途径。 例如，在构建软件碳足迹方面，我们建议对 碳效能作为软件架构的特性 进行评估。一个重视碳效能的架构会将碳效率作为架构设计和基础设施选型的考虑因素，以最大限度地减少能源消耗，进而实现减少碳排放。该领域的测量工具和开发建议也日趋成熟，使得开发团队可以将碳效能与性能、可扩展性、财务成本和安全性等其他因素一起进行考量。就像软件架构中的所有因素一样，碳效能应该被视为一种权衡。我们建议将碳效能视为构成架构的一整套质量属性中的一个附加特性。因为这类特性应由组织目标驱动并划分优先级，而不应该留给一小部分专家孤立地思考。

你应该如何编写好的代码？如何判断自己是否写了好的代码？作为软件开发者，我们总是在寻找一些自然易记的规则、原则和模式，以便在讨论如何编写简单的、易修改的代码时，我们有统一的语言和价值观。

Daniel Terhorst-North最近尝试为好代码创建了一个类似于检查表的东西。他认为与其拘泥于像 SOLID 这样一套规则，不如使用一组特性作为目标。他设计出了名为 CUPID 的特性组，来描述为了写出"令人愉悦"的代码，我们需要做出哪些努力：在该特性指导下的代码应该是可组合的，遵循 Unix 哲学的，可预测的，风格自然的以及基于领域的。

意外泄露机密似乎是一个老生常谈的事故，也出现了像 Talisman 这样的工具来帮助解决这个问题。在此之前，拥有高级安全许可证的 GitHub Enterprise Cloud 用户可以对其帐户启用安全扫描，意外提交和推送的任何机密（API 密钥、访问令牌、凭据等）都会触发警报。GitHub 推送保护更深入了一步，并将其提前到了开发工作流程中，如果更改被推送的时候检测到有机密，则直接拒绝这次推送。 这需要为组织进行配置，当然仅适用于许可证持有者，但欢迎提供额外的保护以防止泄露机密。

在集中式应用程序中，服务器上的数据是可信单一数据源——对数据的任何修改都必须经由服务器完成，本地数据只是服务器数据的副本。 这似乎是实现软件的多人协作自然且必然的选择。 本地优先应用程序 ，或 本地优先软件，是一组即能够实现多人协作，且可以使数据所有权本地化的软件设计原则。 它优先使用本地存储和本地网络，而不是远程数据中心或云服务器。 无冲突复制数据类型 (CRDT) 和点对点 (P2P) 网络等技术有可能成为实现本地优先软件的基础技术。

指标库，有时也被称作无头商业智能(BI)，是一种将指标的定义与其在报表和可视化中的使用相解耦的中间层。在传统意义上讲，指标定义在商业智能(BI)工具的上下文中。但是这样的做法会导致重复与不一致，因为不同的项目组可能将指标用于不同的上下文中。通过指标库解耦指标的定义，便可以清晰且一致地在多个报表、可视化甚至嵌入式分析中复用指标。这并不是一项新技术；例如，Airbnb 在几年前就引入了 Minerva 。不过，随着越来越多的工具开箱即用地支持指标库，指标库在数据和分析生态的影响力越来越大。

服务器端驱动 UI 仍然是移动开发圈的一个热议话题，因为这项技术允许移动端开发者利用更快的变更周期，而不违反应用商店关于重新验证移动应用的任何政策。服务器端驱动 UI 将渲染分离到移动应用程序的一个通用容器中，而每个视图的结构和数据由服务器提供。这意味着对于过去那些需要经历一次应用商店发布之旅的修改，现在只需要简单改变服务器发送的响应数据即可实现。虽然一些非常大的移动应用团队已经利用这种技术取得了巨大的成功，但它也需要大量的投入来建立和维护一个复杂的私有框架。这样的投入需要一个令人信服的商业案例。在此之前，最好谨慎行事。我们的确陷入过某种过度配置的可怕困境，并没有真的获得预期的收益。但在 Airbnb 和 Lyft 等巨头的背书下，我们很可能会看到一些有用的框架出现，有助于降低这种复杂度。这一领域值得关注。

自从谷歌首次将服务质量指标（SLIs）和服务质量目标（SLO）作为其网站可靠性工程（SRE）实践的一部分推广以来，Datadog 、Honeycomb 和 Dynatrace 等观察性工具开始将 SLO 监控纳入其工具链。OpenSLO 是一个基于 Kubernetes 使用的 YAML 格式声明式、中立的规范语言新兴的，且允许将 SLI 和 SLO 定义为代码 的标准。虽然该标准仍然很新，但我们看到了一些令人鼓舞的势头，比如 Sumo Logic 公司贡献了 slogen 工具来生成监控和仪表盘。我们对在代码中对 SLI 和 SLO 定义进行版本化的承诺，和将可观察性工具作为所部署服务的 CI/CD 流水线一部分这一更新感到兴奋。

在我们本期技术雷达的讨论中，出现了几个用于生成合成数据的工具和应用。我们发现，随着工具的成熟， 模型测试的合成数据 成了一项强大而且有广泛应用的技巧。在验证机器学习模型判别能力的过程里，合成数据虽然尚不能取代真实数据，但也有相当广泛的使用场景。例如，合成数据可以用于预防小概率事件下模型彻底失效，或者在不暴露个人隐私信息的前提下对数据流水线进行测试。在探索缺乏真实数据的边缘场景以及确认模型偏差时，合成数据也很有用处。有一些有助于生成数据的工具，例如 Faker 和 Synth 可以生成服从预期统计特性的数据，Synthetic Data Vault 等工具可以依照输入数据集特性来生成数据。

我们仍旧为 TinyML 这项技术和它在构建可以运行在低功耗和移动设备上的机器学习（ML）模型的能力而感到兴奋。时至今日，运行机器学习（ML）模型仍然需要高昂的计算成本，并且在某些情况下还需要使用专用硬件。虽然模型的创建仍然大致属于上述情况，但可以通过一种方式创建模型，使它们能够在小型、低成本和低功耗设备上运行。如果你一直在考虑使用 ML 但苦于计算能力或网络环境的限制而放弃，那么这种技术值得你去评估。

当我们两年前第一次把它纳入雷达时，可验证凭证是一个有趣的标准，有着一些潜在的应用前景，但它并没有在爱好者群体之外广为人知。当涉及到将负责实施该标准的证书授予机构时，如州级政府等，情况更是如此。自疫情以来的两年后，随着对加密安全、尊重隐私和可由机器验证的电子凭证的需求的增长，政府开始意识到可验证凭证的潜力。我们现在开始看到可验证证书出现在我们与公共部门客户的合作中。W3C 标准以凭证持有者为中心，这与我们使用物理凭证时的经验相似：用户可以将其可验证凭证放在自己的数字钱包中，并在任何时候向任何人展示，而无需得到凭证发行者的许可。这种去中心化的方法也使用户能够更好地管理和有选择地披露自己的信息，这大大改善了数据隐私的保护。例如，在零知识证明技术的支持下，你可以在不透露你的生日情况下构建一个可验证凭证来证明你是一个成年人。值得注意的是，尽管许多基于可验证凭证的去中心化身份解决方案依赖于区块链技术，但区块链并不是所有可验证凭证实施的先决条件。

术语 "远程团队配置 "并不只是描述一种配置；它包含了多种模式和口味。许多团队最近都在改变模式。他们正从新冠疫情下被迫采取的 "每个人总是远程 "的工作模式中走出来，转而采用（通常是轮流）卫星式工人的模式，即部分团队在同一地点办公，部分团队远程工作。我们看到他们中的许多人没有正确考虑这对工作方式意味着什么。 没有“使用原生的远程工作方法” 的卫星式工人回到了优先考虑同地办公的工作方式。在有卫星式工人的配置中，重要的是仍然默认使用“原生的远程工作方法”。例如，如果团队中在同一地点工作的人一起参加会议，他们仍然应该在各自的笔记本电脑上参与数字协作或会议聊天。 团队需要意识到排斥他们的卫星工人和创造孤岛和排斥感的风险。如果你知道总是有至少一个卫星团队成员，那么默认的工作方式应该假定是远程的。

团队搭建网站时会默认选择单页面应用 (SPA) 的普遍现象让我们担心人们甚至没意识到 SPA 原本只是一种架构风格时，就立即进行了项目的框架选型。SPA 会招致传统基于服务器的网站所不具备的复杂性：譬如搜索引擎优化，浏览历史管理，网站分析，首页加载时间等。我们需要适当地分析和考虑，来确定这种复杂性是出于业务需求还是用户体验，以此做出权衡。我们通常看不到团队去进行这种权衡分析，即使是在业务需求不能证明这种使用是合理的情况下，也盲目地接受了 默认使用 SPA 的复杂性。事实上，我们已经开始注意到许多新的开发人员甚至都不知道有替代的方法，因为他们整个职业生涯都是在类似 React 这样的框架中度过的。我们相信，许多网站都会受益于服务端逻辑的简洁性，并且我们从例如 Hotwire 这种有助于减少用户体验差异的技术中受到了鼓励。

“云原生”一词最初用于描述最大限度利用公有云托管的架构。例如由许多小型、无状态和协作流程组成的分布式架构，以及具有高度自动化的构建、测试和部署能力的系统。然而，我们注意到越来越多 肤浅的云原生 设计，简单地大量使用云供应商提供的专有服务，而没有注意到应用程序其实是大单体、脆弱且笨重的。要注意的是，无服务函数本身并不能使应用程序更具弹性或更易于维护。云原生实际上是架构设计，而非对于实现方式的选择。