Thoughtworker 热爱技术。我们致力于构建技术、研究技术、测试技术、开源技术、书写技术,并不断改进技术。支持卓越软件并掀起IT革命是我们的使命,Thoughtworks 技术雷达就是为了完成这一使命。
技术雷达是 Thoughtworks 每半年发布一次的技术趋势报告,由 Thoughtworks 的 21 名高级技术专家组成的技术咨询委员会(TAB)编写。TAB 每年召开两次面对面会议,每两周召开一次视频会议。其主要职责是为 Thoughtworks 的首席技术官 Rachel Laycock 和名誉首席技术官 Rebecca Parsons 提供咨询建议。同时,他们也通过定期讨论 Thoughtworks 的全球技术战略以及对行业有重大影响的技术趋势并以此来撰写技术雷达。
作为一个综合型组织,TAB 能够审视影响 Thoughtworks 技术战略和技术人员的各种主题。从首席技术官到开发人员,雷达将会为各路利益相关方提供价值。本期技术雷达内容基于 2023 年 8 月的 TAB 线上会议创建。
本期内容对百余个技术条目进行分析,阐述它们目前的成熟度,并提供了相应的技术选型建议。我们建议您探索雷达中提到的内容以了解更多细节。技术雷达的本质是图形性质,把各种技术项目归类为技术、工具、平台和语言和框架。如果技术可以被归类到多个象限,我们选择看起来最合适的一个。我们还进一步将这些技术分为四个环以反映我们目前对其成熟度的态度。
AI 辅助软件开发毫无意外,本期技术雷达主要围绕 AI 相关话题展开讨论。这是有史以来第一次,我们需要一个可视化指南来理清不同 AI 的类别和功能(即使在 JavaScript 生态系统十分混乱的时期,我们也从未采取过这样的做法)。作为一家开创 CI、CD 等突破性工程实践历史的软件咨询公司,我们对于使用 AI 辅助软件开发特别感兴趣。因此,本期技术雷达讨论了许多代码辅助工具, 如 GitHub Copilot、Tabnine 和 Codeium。我们兴奋于 open-source LLMs for coding 在工具领域可能带来的变革,并且我们看到了在编码之外的辅助领域中工具和能力的爆炸式增长,如用户故事编写辅助、用户研究、电梯演讲和其他基于语言的任务。同时,我们希望开发人员能够负责任地使用所有这些工具,并且始终掌控主导权,比如 hallucinated dependencies 就是其中一个需要注意的安全和质量风险。
衡量生产力有多有效
对于非技术人员来说,软件开发有时似乎很神奇,这导致管理者需要努力衡量开发人员在完成其神秘任务时的生产效率。我们的首席科学家 Martin Fowler 早在 2003 年就撰写了有关此主题的文章,但问题并没有消失。在这期雷达中,我们讨论了许多现代工具和技术,它们采用更加细致入微的方法来衡量软件的创造过程,但这仍然不够。幸运的是,业界已经不再使用代码行数作为产出衡量标准。然而,衡量框架 SPACE 中 A(Activity,活动)的替代方法,例如拉取请求的数量或已解决的问题的数量,仍然不足以成为衡量生产力的良好指标。相反,行业已经开始关注“工程效能”:我们不应该衡量生产力,而应该衡量我们知道对流程有贡献或有损害的事物。我们不应该专注于个体的活动,而应该关注系统中的浪费来源以及可以从经验上证明导致开发人员对“生产力”感知产生影响的条件。新的工具,比如 DX DevEx 360,通过关注开发者体验而不是一些虚假的产出衡量标准解决了这个问题。然而,许多领导人仍然以模糊的、定性的方式衡量开发者的“生产力”。我们怀疑,这种兴趣的复苏至少有一部分原因是受到了人工智能辅助软件开发的影响,这不可避免地引发了一个问题:它是否产生了积极的影响?虽然衡量标准可能变得更加细致入微,但真正的生产力衡量仍然难以捉摸。
众多大语言模型
大语言模型(LLMs)为现今人工智能的许多重要突破奠定了基础。目前的应用多使用类似聊天的界面进行交互,例如 ChatGPT 或 Google Bard。生态中的主要竞争者(例如 OpenAI 的ChatGPT,Google Bard,Meta 的 LLaMA 以及亚马逊的 Bedrock 等)在我们的讨论中占据重要地位。更广泛来说,大语言模型可以应用于从内容生成(文本、图片和视频)、代码生成到总结概述和翻译等各种问题。通过自然语言的抽象层,这些大模型成为了强大的工具库,被诸多信息工作者广泛使用。我们讨论了大语言模型的各个方面,包括自托管式大语言模型,相较云托管的大语言模型,它支持更多的定制和管控。随着大语言模型日益复杂,我们正在深思如何在小型设备上运行大语言模型,特别是在边缘设备和资源受限的环境中。我们还提到有望提高性能的 ReAct 提示工程,以及利用大语言模型驱动的自主代理开发远超简单的问答交互的动态应用。我们也提到一些向量数据库(包括 Pinecone)由于大语言模型而重新流行起来。大语言模型的底层能力,包括更专业化和自行托管的能力,将继续呈爆发性增长。
远程交付解决方案日臻成熟
尽管远程软件开发团队多年来利用技术克服地理限制,但疫情的影响进一步推动了这一领域的创新,巩固了向完全远程或混合工作演进的趋势。在本期技术雷达中,我们讨论了远程软件开发实践和工具的成熟,和团队们如何继续以有效协作为重点,不断突破界限,在一个更加分散和动态的环境中进行工作。一些团队利用新的协作工具不断提出创新解决方案。其他团队则继续调整和改进现有的面对面实践,例如实时结对编程或集体编程、分布式工作坊(例如 远程事件风暴)以及异步和同步沟通。远程工作提供了许多好处(包括更多样化的人才储备),但面对面交流的价值是显而易见的。团队不应中断重要的反馈循环,并且需要意识到在转向远程工作时所做的取舍。
追踪健康债务状况试验通过将健康度评级与其他服务级目标(SLO)同等对待,并据此确定增强的优先级,而不是仅仅关注跟踪技术债务,我们不断体验到团队对其生态系统的改进。通过有效分配资源来解决与健康状况相关的最有影响的问题,团队和组织可以降低长期维护成本,更高效地发展产品。这种方法还能加强技术和非技术利益相关者之间的沟通,促进对系统状态的共同理解。尽管不同组织的衡量标准可能有所不同(请参阅本博文中的示例),但它们最终都有助于实现长期可持续性,并确保软件保持适应性和竞争力。在瞬息万变的数字环境中,专注于跟踪系统的健康状况与债务,可为维护和增强系统提供结构化的循证战略。
通过依赖健康检查化解包幻觉风险评估确保软件供应链的安全已成为交付团队普遍关心的问题,这也反映在该领域的工具和技术数量不断增加,而一些工具和技术我们在之前的雷达中也进行了介绍。在软件开发过程中使用基于 GenAI 的工具日益普及,这也引发了一种新的软件供应链攻击媒介:包幻觉。我们认为在开发过程中使用 GenAI 工具的团队需要重视这类风险。团队可以通过对依赖进行健康检查化解包幻觉风险:在选择依赖之前查看它的创建日期、下载数量、github 评论及星标数、贡献者数量、活动历史记录等。一些依赖健康检查可以在包存储仓库和 GitHub 上执行,而像 deps.dev 和 Snyk advisor等工具也可以提供帮助。尽管依赖健康不是一项新技术,但随着团队在软件开发过程中越来越多地尝试 GenAI 工具,该实践正在获得新的关注。自托管式大语言模型评估大语言模型(LLMs)通常需要大量的 GPU 基础设施才能运行,但目前有强烈的推动力使它们可以在更简单的硬件上运行。对大语言模型进行量化可以减少内存需求,使高保真度模型可以在成本更低廉的硬件甚至是 CPU 上运行。像 llama.cpp 这样的工作使大语言模型可以在包括树莓派、笔记本电脑和通用服务器在内的硬件上运行成为可能。
许多组织正在部署自托管式大语言模型。这往往是出于安全或隐私方面的考虑,有时是因为需要在边缘设备上运行模型。开源示例包括 GPT-J、GPT-JT 和 Llama。这种方法提供了更好的模型控制,以进行特定用途的微调,提高了安全性和隐私性,以及离线访问的可能性。尽管我们已经帮助一些客户自托管开源大语言模型用于代码生成,但我们建议在决定自托管之前仔细评估组织的能力和运行这类大语言模型的成本。
忽略 OWASP 十大安全风险榜单暂缓OWASP 十大安全风险榜单长期以来一直是 Web 应用程序最关键的安全风险参考。尽管众所周知,我们曾写过它在软件开发过程中未得到充分利用,并警告不要忽略 OWASP 十大安全风险榜单。但鲜为人知的是 OWASP 也在其他领域发布了类似的十大榜单。在八月初发表了第一个主要版本的 OWASP LLM 十大安全风险榜单 强调了提示注入、不安全的输出处理、训练数据投毒以及其他个人和团队构建 LLM 应用程序时最好注意的风险。OWASP 近期也发布了 OWASP API 十大安全风险榜单的第二版。鉴于 OWASP 十大安全风险榜单的覆盖范围(Web 应用程序、API、LLM 及其他)、质量以及与持续变化的安全形势的相关性,我们继续向团队警告不要忽略 OWASP 十大安全风险榜单。
Colima采纳Colima (https://github.com/abiosoft/colima) 现在是我们在 macOS 上替代 Docker Desktop 的首选方案。我们持续在几个项目中使用它来提供 Docker 容器运行时的 Lima VM,在 macOS 上配置 Docker CLI,并处理端口转发和挂载卷。Colima 可以配置为使用 containerd 作为其运行时,这也是大多数托管的 Kubernetes 服务上的运行时,可以提高重要的开发到生产环境的一致性。DataOps.live试验DataOps.live 是一个自动化 Snowflake 环境的数据平台。受 DevOps 实践启发,DataOps.live 可以像在其他网络平台一样在数据平台中实施持续集成和持续交付 (CI/CD),自动化测试, 可观测性和代码管理。我们的团队正在用它来管理数据产品的全生命周期,包括代码和数据的开发、分支、部署。通过它的自动化环境管理,能够轻易建立、修改、自动销毁基于特征分支的环境。它的声明式标准 (SOLE) 能力也值得关注,因其可以优化开发者体验。它能使团队构建数据产品的时间从几个月变为几天。我们的团队成功将 DataOps.live 用于生产环境, 这也是我们推荐在使用 Snowflake 时使用这一平台的原因。Orca试验Orca 是一个专有的云安全平台,用于识别、优先级排序和修复安全风险和合规问题。它支持主流的云提供商和混合设置。Orca 拥有广泛的安全查询和规则,以持续监控已部署的工作负载,检测配置错误、漏洞和合规性问题。它支持云虚拟机、无服务器函数、容器以及已部署工作负载的 Kubernetes 上部署的应用。这些内置的安全规则会定期更新,以跟上不断演进的合规标准和威胁向量。由于 Orca 无需代理,因此提供了良好的开发者体验,并且易于设置。另一个显著的特点是它促进了安全的左移。我们的团队使用 Orca CLI 来扫描容器镜像和 IaC 模板,以检测漏洞和配置错误,作为预提交钩子或 CI/CD 工作流的一部分。它还持续监控和扫描容器仓库(如 AWS ECR),以查找已发布镜像中易受攻击的基础镜像或脆弱的操作系统依赖项。根据我们团队的经验,Orca 提供了从开发到生产的安全状态的统一视图,因此我们将其放入试验阶段。
DX DevEx 360试验DX DevEx 360 是一款基于调查的工具,它通过聚焦开发人员在日常工作中面临的阻力点,如代码审查流程、代码质量、深度工作能力等,寻找提高开发人员生产力的关键指标。该调查由 Nicole Forsgren 和 Margaret-Anne Storey 制定,他们曾和其他专家一并主导了 DORA 和 SPACE 两个项目。
我们的平台工程团队已成功使用 DX DevEx 360 来了解开发人员的观点并识别存在的阻力点,从而为平台发展路线提供参考。与类似调查工具不同,使用 DX DevEx 360,我们获得了90%以上的回应率,开发人员通常会就问题和改进想法进行详细评论。该工具令人赞赏之处还有:它将结果透明化给公司的工程师,而不仅仅是经理,此外它支持按团队进行分析,从而实现每个团队环境的持续改进。
mob试验mob 是一个用于远程结对编程或集体编程中无缝进行 git 交接的命令行工具。它将所有版本控制工具隐藏在一个命令行界面背后,这使参与集体编程会话变得更加简单。它还提供了关于如何远程参与的具体建议,例如,在 Zoom 中“窃取屏幕共享”,而不是结束屏幕共享,以确保参与者的视频布局不发生变化。我们的一些团队强烈推荐 mob,并且它已经成为我们在远程协作或集体编程中工具链的重要组成部分。
Open-source LLMs for coding评估GitHub Copilot 是软件开发时有价值的辅助编程工具。而在工具背后,大语言模型(LLMs)通过赋能内联代码助手、代码微调和 IDE 中的对话支持等方式,无缝提升开发人员的体验。大多数这些模型都是专有的,只能通过订阅服务使用。好消息是,您可以使用几种开源的 LLMs 进行编码。如果您需要构建自己的编码辅助服务(比如受到高度监管的行业),可以考虑 StarCoder 和 WizardCoder。StarCoder 使用由 BigCode 维护的大型数据集 进行训练,而 Wizardcoder 是 Evol-Instruct 调整后的 StarCoder 模型。
我们在实验中使用了 StarCoder,发现它对于生成诸如代码、YAML、SQL 和 JSON 等 结构化软件工程元素十分有用。根据我们的实验,我们发现这两个模型都可以使用提示词中的 小样本示例 进行上下文学习 。尽管如此,对于特定的下游任务(例如为 Postgres 等特定数据库生成 SQL),模型仍需要微调。最近,Meta 推出了 Code Llama,一款专用于编程的 Llama 2。使用这些开源模型时务必要小心谨慎。在选择任何这些编码 LLMs 供您的组织使用之前,请考虑它们的许可,包括代码的许可和用于训练模型的数据集的许可,仔细评估这些方面后再做决定。
Tabnine评估Tabnine 是目前炙手可热的编程助手领域的有力竞争者之一。它提供了内嵌的代码补全建议,以及直接在 IDE (Integrated development environment,集成开发环境) 中进行对话的能力。与 GitHub Copilot 类似,Tabnine 的出现远远早于现在这个各家纷纷大肆炒作的时期,也因此成为了该领域中最成熟的产品之一。与 Copilot 不同的是,Tabnine 使用的模型仅在获得授权的代码上进行训练,并提供了一个可以自行托管的版本,供担心其代码片段会被发送给其他第三方服务的组织使用。Tabnine 既提供有受限制的免费版本,也提供付费版本,后者会有更全面的建议,还提供了一种使用本地模型的模式(尽管功能较弱),供您在没有互联网连接的情况下使用。
Playwright采纳使用 Playwright,您可以编写在 Chrome、Firefox 和 WebKit 中运行的端到端测试。通过使用 Chrome 开发者工具(DevTools)协议(CDP),Playwright 可以提供新功能并消除 WebDriver 中出现的许多问题。基于 Chromium 的浏览器直接实现了 CDP。不过,为了支持 Firefox 和 Webkit,Playwright 团队不得不向这些浏览器提交补丁,这有时可能会限制框架。
Playwright 的功能包括:内置自动等待,这使得测试更可靠、更易于理解;浏览器上下文,可让您测试跨标签页的持久会话是否正常工作;以及模拟通知、地理位置和黑暗模式设置的能力。Playwright 为测试套件带来的稳定性给我们的团队留下了深刻印象,并且喜欢它可以并行运行测试以更快地获得反馈。Playwright 的其他特色包括更好地支持懒加载和追踪。尽管 Playwright 有一些局限性(例如,组件支持目前处于实验阶段),但我们的团队认为它是首选的测试框架,甚至在某些情况下会从 Cypress 和 Puppeteer 上迁移过来。
Dart试验Dart 是由 Google 开发的编程语言,支持构建跨平台的应用程序,包括 Web 浏览器、WebAssembly、桌面和移动应用。它的采纳是由 Flutter 的主导地位推动的。在跨平台原生移动应用框架领域,Flutter 是一个流行的、使用 Dart 作为其核心语言的跨平台 UI 工具包。根据社区的反馈,Dart 从最初的版本开始不断演进,除了具备健壮的类型系统,还在3.0版本中添加了内置的 sound null safety。此外,Dart 的生态系统正在快速发展,拥有活跃的社区、丰富的可用库和工具,这使其对开发者非常具有吸引力。
语法性别 API评估在许多语言中,性别的表现都比英语更为明显,且词语会根据性别发生变化。例如,称呼用户时,可能需要对词语进行变形,但通常的做法是默认使用男性形式。有证据表明,这会对人的表现和态度产生负面影响 —— 当然,这也是不礼貌的。使用性别中立语言的变通办法往往显得笨拙。因此,正确地称呼用户是首选。借助Android 14 中引入的语法性别 API,安卓开发者们现在可以更容易地做到这一点。
Spring Modulith评估尽管我们是微服务(microservices)的早期倡导者,并看到该模式在无数系统上取得了成功,但我们也看到微服务被误用和滥用,这通常是microservice-envy(microservice envy)导致的。与其从头开始构建一个由单独部署的进程组成的新系统,我们通常建议从一个精心设计的单体应用开始,并且仅当应用程序达到一定规模时,才将其分解为可单独部署的单元,此时微服务的好处才能超越分布式系统所固有的额外复杂性。最近,我们看到人们对这种方法重新产生了兴趣,以及对什么构成了精心分解的整体有了更详细的定义。Spring Modulith 是一个框架,它以一种使代码在适当时候更容易拆分成微服务的方式来组织代码。它提供了一种模块化代码的方法,使领域和限界上下文的逻辑概念与文件和包(package)结构的物理概念保持一致。这种对齐方式使得在必要时重构单体架构以及单独测试领域变得更加容易。Spring Modulith 提供了一种进程内事件机制,有助于进一步解耦单个应用程序中的模块。最重要的是,它与 ArchUnit 和 jmolecules 集成,可以自动验证其领域驱动的设计规则。
以上条目为随机抽取,欲获取完整版技术雷达
请扫码或点击左下角 [阅读原文] 进行查看或下载