技术雷达针对当今科技领域发展的前沿指南.PDF

针对当今科技领域发展的前沿指南 关于技术雷达雷达一览贡献者本期主题本期雷达技术平台工具语言和框架 3 4 5 6 24 关于技术雷达 Thoughtworker 酷爱技术。我们致力于建造技术，研究技术，测试技术，开源技术，书写技术，并不断改进技术。支持卓越软件并掀起 IT 革命是我们的使命，Thoughtworks 技术雷达就是为了完成这一使命。它由Thoughtworks 中一群资深技术领导组成的技术顾问委员会，通过定期讨论 Thoughtworks 的全球技术战略以及对行业有重大影响的技术趋势而创建。 技术雷达以独特的形式记录技术顾问委员会的讨论结果，从首席技术官到开发人员，雷达将会为各路利益相关方提供价值。这些内容只是简要的总结。 我们建议您探索雷达中提到的内容以了解更多细节。技术雷达的本质是图形性质，把各种技术项目归类为技术、工具、平台和语言和框架。如果技术可以被归类到多个象限，我们选择看起来最合适的一个。我们还进一步将这些技术分为四个环以反映我们目前对其的态度。 想要了解更多技术雷达相关信息，请点击：thoughtworks.com/cn/radar/faq 雷达一览 技术雷达持续追踪有趣的技术是如何发展的，我们将其称之为条目。在技术雷达中，我们使用象限和环对其进行分类，不同象限代表不同种类的技术，而圆环则代表我们对它作出的成熟度评估。 软件领域瞬息万变，我们追踪的技术条目也如此，因此您会发现它们在雷达中的位置也会改变。 采纳：我们强烈主张业界采用这些技术。我们会在适当时候将其用于我们的项目。 试验：值得追求。重要的是理解如何建立这种能力，企业应该在风险可控的项目中尝试此技术。 评估：为了确认它将如何影响你所在的企业，值得作一番探究。 暂缓：谨慎推行。 技术雷达是具有前瞻性的。为了给新的技术条目腾出空间，我们挪出了近期没有发生太多变化的技术条目，但略去某项技术并不表示我们不再关心它。 贡献者 技术顾问委员会（TAB）由 Thoughtworks 的 22 名高级技术专家组成。 TAB 每年召开两次面对面会议，每两周召开一次视频会议。其主要职责是为 Thoughtworks 的首席技术官 Rachel Laycock 和名誉首席技术官Rebecca Parsons 提供咨询建议。 作为一个综合型组织，TAB 能够审视影响 Thoughtworks 技术战略和技术人员的各种主题。本期技术雷达内容基于 2024 年 2 月技术委员会成员在纽约的面对面会议创建。 BharaniSubramaniam SelvakumarNatesan Scott Shaw 本期主题 （或许）开源的许可证 在我们的会议中，关于许可证引发了两类讨论。首先，多年来，开源软件开发生态系统依赖于一组由开源倡议组织（Open Source Initiative，OSI）编录的许可证，大多数情况下仅使用流行的几种。然而，最近发生了一些变化。一些知名工具，最近因为其维护者突然从开源模式切换到商业模式而受到了一些负面评价。当然，我们愿意为软件付费，并且认可对于额外功能使用商业许可证的常见模式。只是我们觉得，当这种转变出现在一个受众广泛的工具的核心功能上，尤其是当一个生态系统已经围绕该工具发展起来时，这是有问题的。其次，另一个有趣的转变出现在一些自诩开源的软件上，其基本功能只有在消费者支付订阅费或其他费用后才能使用。尽管这种商业模式以前就存在，但似乎在许多闪亮的新 AI 工具中被更多地利用了——它们提供了一些在细则之下过于隐藏的惊人功能。我们建议特别关注许可证问题。在使用中要提起警惕，并确保存储库中的所有文件都受到顶层许可证的覆盖。 人工智能助力软件开发团队 显然，人工智能目前正在讨论中占主导地位：技术雷达中约有三分之一的类目与之相关。我们不仅讨论了面向开发者的人工智能工具，如GitHub Copilot，CodiumAI，aider和Continue，我们还探讨了如何在整个团队中全面使用 AI、以及如何利用人工智能改变软件开发的各个方面。这其中包括一系列最终未能入选的工具，例如Warp这样的人工智能辅助终端，将截图转换为代码的能力、由 LLMs 支持的 ChatOps 以及许多其他主题。尽管开发人员工具正在发展的日臻成熟，但我们始终对于“软件开发的所有方面都可以从人工智能和相关工具的务实使用中受益”抱有怀疑，我们正在积极跟踪相关领域的创新。与此同时，在人工智能带来近乎神奇的新技能时，相关的质量与安全风险也在涌现，这需要团队保持警惕，包括让非开发人员意识到潜在的风险。 涌现的大语言架构模式 在技术领域，“模式”因为能够为特定问题提供一个简洁的解决方案名称而受到欢迎。随着大语言模型（LLMs）的日益普及，我们开始看到支持常见上下文的特定架构模式不断涌现。例如，我们讨论了NeMo Guardrails，它允许开发人员围绕 LLM 的使用建立治理政策。我们还讨论了像Langfuse这样的工具，它们能够更好地观察LLM 的输出步骤，并知道如何处理（并验证）充斥着生成代码的臃肿代码库。我们讨论了如何使用检索增强生成（RAG），这是我们偏爱的模式，以提高 LLM 输出的质量，在企业生态系统中尤其有效。此外，我们还讨论了使用低能耗（和成本）大语言模型产生材料，然后由更强大（也更划算）的大语言模型选择性审查的技术。模式为技术构建了一个重要的词汇库，随着生成式 AI 继续渗透软件开发，我们预计会看到模式（以及不可避免的反模式）的爆炸式增长。 让Pull Request（PR）更接近正确的持续集成 Thoughtworks 一直推崇在软件开发过程中采用快速反馈循环，因此也是持续集成（CI）的大力支持者。为此，我们在 20 世纪 90 年代末构建并开源了有史以来第一个 CI 服务器 —Cruise Control。最近，我们的首席科学家Martin Fowler 在他的bliki上更新了对于持续集成的规范定义，以重申对这一实践的关注。然而，我们许多团队被迫忽视 CI/CD 中的 CI 部分，因为他们发现自己处于必须使用 Pull Request（PR）的情况。尽管 PR 的做法最初是为了管理大规模分布式的开源团队和不可靠的贡献者，然而目前已经发展成了同行评审（Peer Review，PR）的同义词，即使在紧密工作的小型团队也是如此。在这些情况下，许多开发者渴望从实践真正的 CI中获得相同的流畅感。我们调查了几个试图减轻 PR 审查过程痛苦的工具，包括gitStream和Github 合并队列。我们还讨论了诸如stacked diffs之类的技术，这些技术通过使集成过程更精细化，有望与 CI 的核心原则保持一致。除此之外，我们还探讨了从 PR 中提取度量的方法，以识别软件交付过程中的低效和瓶颈。工具在这个领域会起到巨大帮助，因为整体趋势是朝向生成式 AI 编程的。随着 AI 编码助手的出现，编码吞吐量增加，导致倾向于创建更大的 PR。这给异步代码审查过程增加了更大的压力。尽管我们仍然更喜欢原始的 CI 实践，但我们鼓励那些由于外部约束而无法使用 CI 的团队寻找方法，从而提高集成准确性和反馈周期速度。 本期雷达 本期雷达 技术 平台 采纳19.CloudEvents 采纳1.检索增强生成（RAG） 试验 20.云上 Arm21.Azure Container Apps22.Azure OpenAI Service23.DataHub24.基础设施编排平台25.Pulumi26.Rancher Desktop27.Weights & Biases 2.自动生成 Backstage 实体描述符3.将传统 NLP 与 LLMs 相结合4.持续合规5.边缘函数6.安全标兵7.Text to SQL8.追踪健康债务状况 评估 9.人工智能团队助理10.对 LLM 对话进行图分析11.基于大语言模型的 ChatOps12.大语言模型驱动的自主代理13.使用 GenAI 理解遗留代码库14.VISS 评估28.Bun29.Chronosphere30.DataOS31.Dify32.Elasticsearch Relevance Engine33.FOCUS34.Gemini Nano35.HyperDX36.IcePanel37.Langfuse38.Qdrant39.RISC-V 用于嵌入式40.Tigerbeetle41.WebTransport42.Zarf43.ZITADEL 暂缓 15.广泛集成测试16.过度热衷使用大语言模型17.急于冲向大语言模型微调（fine-tune LLMs）18.适用于 SSR 网络应用程序的 Web 组件 暂缓 语言和框架 工具 采纳44.Conan45.Kaniko46.Karpenter 采纳 试验84.Astro85.DataComPy86.Pinia87.Ray 试验 47.42Crunch API Conformance Scan48.actions-runner-controller49.Android 模拟器容器50.AWS CUDOS51.aws-nuke52.Bruno53.Develocity54.GitHub Copilot55.Gradio56.Gradle Version Catalog57.Maestro58.Microsoft SBOM 工具59.开放策略代理（OPA）60.Philips's self-hosted GitHub runner61.Pop62.Renovate63.Terrascan64.Velero 评估 88.安卓适应性89.Concrete ML90.Crabviz91.Crux92.Databricks Asset Bundles93.Electric94.LiteLLM95.LLaMA-Factory96.MLX97.Mojo98.Otter99.Pkl100.Rust for UI101.vLLM102.Voyager103.WGPU104.Zig 评估 65.aider66.Akvorado67.百川 268.Cargo Lambda69.Codium AI70.Continue71.Fern Docs72.Granted73.LinearB74.LLaVA75.Marimo76.Mixtral77.NeMo Guardrails78.Ollama79.OpenTofu80.QAnything81.System Initiative82.Tetragon83.Winglang 暂缓105.LangChain 暂缓 技术 采纳 1.检索增强生成（RAG） 试验 2.自动生成 Backstage 实体描述符3.将传统 NLP 与 LLMs 相结合4.持续合规5.边缘函数6.安全标兵7.Text to SQL8.追踪健康债务状况 评估 9.人工智能团队助理10.对 LLM 对话进行图分析11.基于大语言模型的 ChatOps12.大语言模型驱动的自主代理13.使用 GenAI 理解遗留代码库14.VISS 暂缓 15.广泛集成测试16.过度热衷使用大语言模型17.急于冲向大语言模型微调（fine-tune LLMs）18.适用于 SSR 网络应用程序的 Web 组件 技术 1.检索增强生成（RAG） 采纳 检索增强生成（Retrieval-augmented generation，RAG）是我们团队提高大语言模型（LLM）生成响应质量的首选模式。我们已经在包括Jugalbandi AI Platform在内的多个项目中成功使用了它。通过 RAG，相关且可信的文档（如 HTML 和 PDF 格式）的信息被存储在支持向量数据类型或高效文档搜索的数据库中，例如pgvector、Qdrant或Elasticsearch Relevance En