采纳
生产路径图尽管生产路径图自从持续交付被编著时在Thoughtworks就是一种近乎普遍的实践，但是我们经常会遇到一些不熟悉生产路径图实践的组织。这一活动经常由一群跨功能团队的人——包括参与设计、开发、发布与运营软件的所有人——在工作坊中完成，他们围在同一张白板前面（或者是一个虚拟的等价物）。首先，按照顺序把流程的步骤罗列出来，从开发阶段一直到发布生产的所有路径。然后，主持一个会议来获取更多的信息和痛点。我们最常见的技术是基于价值流图，尽管有很多具有同等价值的流程图变种。这项活动经常会让参与者眼界大开，因为他们识别出了延迟，风险和不一致的地方，并且可以用可视化的陈述来持续改进构建和部署的流程。我们认为这是一项很基本的技术，所以我们很惊讶地发现在之前的技术雷达中并没有提到它。
威胁建模我们继续推荐团队实施威胁建模——一系列有助于在开发过程中发现潜在威胁并对其进行分类的技术——但是我们想要强调的是，这件事不是只在项目开始时做一次就能一劳永逸的，团队需要避免 security sandwich 现象。这是因为，在任何软件的整个生命周期中，由于外部事件以及需求和架构的调整，可能会出现新的威胁，而现有的威胁将继续发展。这就意味着，威胁建模需要定期重复——重复的频率视情况而定，需要综合考虑诸多因素，例如执行的成本和对业务的潜在风险等。如果结合其他技术使用，例如建立跨功能的安全需求来发现项目所采用的技术有什么公共风险，以及使用自动化安全扫描，这时威胁建模将变得非常有用处。
试验
组件视觉回归测试视觉回归测试是很有用的强大工具，值得被您收进工具箱。但是在整个页面上使用视觉回归测试的成本非常高。我们看到随着 React 和 Vue 等基于组件的框架逐渐兴起，组件视觉回归测试也越来越流行。这项技术能确保在应用程序中不会引入非必要的视觉元素，从而很好地维持了投入和产出之间的平衡。在我们的实践里，组件视觉回归测试很少误测，而且有助于改善架构风格，通过和 Vite 以及 webpack 的 模块热替换 (HMR) 功能共同使用，还可以视之为测试驱动开发应用于前端开发领域的范式转变。
联邦学习我们看到许多客户项目正在使用联邦学习(ML)。传统上机器学习模型训练时需将数据放在集中运行模型训练算法的地址。在隐私角度上，这存在问题，特别是当训练数据包括敏感或者可用于身份识别信息时；用户也许不愿意分享数据，当地的数据保护法律也可能不允许我们将数据转移至一个中心化的位置。联邦学习是一个去中心化的技术，它使模型可以在大量不同来源的数据集上训练，并让数据保持在远端，例如用户的设备上。尽管网络带宽和设备的算力限制目前仍是这项技术重大的挑战，但是我们喜欢联邦学习的思路，让用户可以完全控制自己的个人信息。
移动微前端自从 2016 年在技术雷达中介绍微前端以来，我们已经看到 Web UI 广泛地采用它们。然而，最近我们看到一些项目把这种架构风格也拓展到了移动微前端。当应用程序变得足够庞大与复杂时，就有必要将开发工作分配给多个团队。这提出了围绕团队自治、仓库结构与集成框架的许多挑战。过去，我们提到过 Atlas 与 BeeHive，但是这些框架未能获取关注而且也不再处于活跃开发状态。最近的方法包括用于将多个团队的工作集成到单个应用程序中的 Tuist 或 Swift 包管理器。但根据我们的经验，团队最终经常会实现自己的集成框架。虽然我们毫无疑问看到了在扩充移动开发团队规模时对模块化的需求，但是对微前端的需求却不太确定。这是因为尽管微前端意味着团队与页面或组件之间的直接对应关系，但是这种结构却有可能最终导致业务领域上下文的职责模糊，由此增加团队认知负载。我们的建议是遵循良好、整洁的应用程序设计，当规模扩大为多个团队时采纳模块化，仅当模块与业务领域高度对齐时才采用微前端架构。
CI/CD 流水线的可观测性可观测性实践已经将对话从监测通俗易懂的问题转换为帮助解决分布式系统中的未知问题。通过应用 CI/CD 流水线的可观测性 ，我们已经看到在传统生产环境之外采纳这种立场以帮助优化测试与部署瓶颈的成功。复杂的流水线会在运行太慢或遭受非确定性影响时给开发者带来摩擦，进而减少关键反馈循环并且阻碍开发者效率。此外，它们作为关键部署基础设施的角色在快速部署周期中产生了压力点，就像一些组织在应对最近的 log4shell 漏洞时所发生的那样。追踪的概念能够很好地转移到流水线上：子跨度抓取构建每个阶段的信息，而不是抓取服务调用级联。在分布式架构中用于分析调用流的瀑布图同样可以有效地帮助我们识别流水线瓶颈，甚至是那些扇入扇出的复杂流水线。这使得针对性大幅提高的优化工作成为可能。尽管此项技术适用于任何追踪工具，但是 Honeycomb 支持一个名为 buildevents 的工具，其有助于抓取流水线追踪信息。一种替代方案，即抓取已经由 CI/CD 平台暴露的信息，由 buildviz （由一位 Thoughtworker 构建并维护）采纳，允许在不更改步骤配置文件自身的情况下进行相似的调查。
评估
碳效能作为软件架构的特性可持续发展是一个需要企业持续关注的话题。在软件开发领域，可持续发展的重要性日益显著，并且我们也可以看到出现了很多不同的达成途径。例如，在构建软件碳足迹方面，我们建议对碳效能作为软件架构的特性进行评估。一个重视碳效能的架构会将碳效率作为架构设计和基础设施选型的考虑因素，以最大限度地减少能源消耗，进而实现减少碳排放。该领域的测量工具和开发建议也日趋成熟，使得开发团队可以将碳效能与性能、可扩展性、财务成本和安全性等其他因素一起进行考量。就像软件架构中的所有因素一样，碳效能应该被视为一种权衡。我们建议将碳效能视为构成架构的一整套质量属性中的一个附加特性。因为这类特性应由组织目标驱动并划分优先级，而不应该留给一小部分专家孤立地思考。
CUPID你应该如何编写好的代码？如何判断自己是否写了好的代码？作为软件开发者，我们总是在寻找一些自然易记的规则、原则和模式，以便在讨论如何编写简单的、易修改的代码时，我们有统一的语言和价值观。Daniel Terhorst-North最近尝试为好代码创建了一个类似于检查表的东西。他认为与其拘泥于像 SOLID 这样一套规则，不如使用一组特性作为目标。他设计出了名为 CUPID 的特性组，来描述为了写出"令人愉悦"的代码，我们需要做出哪些努力：在该特性指导下的代码应该是可组合的，遵循 Unix 哲学的，可预测的，风格自然的以及基于领域的。
服务器端驱动 UI服务器端驱动 UI 仍然是移动开发圈的一个热议话题，因为这项技术允许移动端开发者利用更快的变更周期，而不违反应用商店关于重新验证移动应用的任何政策。服务器端驱动 UI 将渲染分离到移动应用程序的一个通用容器中，而每个视图的结构和数据由服务器提供。这意味着对于过去那些需要经历一次应用商店发布之旅的修改，现在只需要简单改变服务器发送的响应数据即可实现。虽然一些非常大的移动应用团队已经利用这种技术取得了巨大的成功，但它也需要大量的投入来建立和维护一个复杂的私有框架。这样的投入需要一个令人信服的商业案例。在此之前，最好谨慎行事。我们的确陷入过某种过度配置的可怕困境，并没有真的获得预期的收益。但在 Airbnb 和 Lyft 等巨头的背书下，我们很可能会看到一些有用的框架出现，有助于降低这种复杂度。这一领域值得关注。
暂缓
没有 "使用原生的远程工作方法 "的卫星式工人术语 "远程团队配置 "并不只是描述一种配置；它包含了多种模式和口味。许多团队最近都在改变模式。他们正从新冠疫情下被迫采取的 "每个人总是远程 "的工作模式中走出来，转而采用（通常是轮流）卫星式工人的模式，即部分团队在同一地点办公，部分团队远程工作。我们看到他们中的许多人没有正确考虑这对工作方式意味着什么。没有“使用原生的远程工作方法”的卫星式工人回到了优先考虑同地办公的工作方式。在有卫星式工人的配置中，重要的是仍然默认使用“原生的远程工作方法”。例如，如果团队中在同一地点工作的人一起参加会议，他们仍然应该在各自的笔记本电脑上参与数字协作或会议聊天。团队需要意识到排斥他们的卫星工人和创造孤岛和排斥感的风险。如果你知道总是有至少一个卫星团队成员，那么默认的工作方式应该假定是远程的。
