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

技术雷达 针前对沿当指今南科技领域发展的 Volume 30 2024年4月 关于技术雷达3 雷达一览4 贡献者5 本期主题6 本期雷达8 技术11 平台17 工具24 语言和框架34 关于技术雷达 Thoughtworker酷爱技术。我们致力于建造技术，研究技术，测试技术，开源技术，书写技术，并不断改进技术。支持卓越软件并掀起IT革命是我们的使命，Thoughtworks技术雷达就是为了完成这一使命。它由Thoughtworks中一群资深技术领导组成的技术顾问委员会，通过定期讨论Thoughtworks的全球技术战略以及对行业有重大影响的技术趋势而创建。 技术雷达以独特的形式记录技术顾问委员会的讨论结果，从首席技术官到开发人员，雷达将会为各路利益相关方提供价值。这些内容只是简要的总结。 我们建议您探索雷达中提到的内容以了解更多细节。技术雷达的本质是图形性质，把各种技术项目归类为技术、工具、平台和语言和框架。如果技术可以被归类到多个象限，我们选择看起来最合适的一个。我们还进一步将这些技术分为四个环以反映我们目前对其的态度。 想要了解更多技术雷达相关信息，请点击：thoughtworks.com/cn/radar/faq 雷达一览 技术雷达持续追踪有趣的技术是如何发展的，我们将其称之为条目。在技术雷达中，我们使用象限和环对其进行分类，不同象限代表不同种类的技术，而圆环则代表我们对它作出的成熟度评估。 软件领域瞬息万变，我们追踪的技术条目也如此，因此您会发现它们在雷达中的位置也会改变。 采纳：我们强烈主张业界采用这些技术。我们会在适当时候将其用于我们的项目。 试验：值得追求。重要的是理解如何建立这种能力，企业应该在风险可控的项目中尝试此技术。 评估：为了确认它将如何影响你所在的企业，值得作一番探究。 暂缓：谨慎推行。 暂缓评估试验采纳 新的挪进/挪出没有变化 技术雷达是具有前瞻性的。为了给新的技术条目腾出空间，我们挪出了近期没有发生太多变化的技术条目，但略去某项技术并不表示我们不再关心它。 贡献者 技术顾问委员会（TAB）由Thoughtworks的22名高级技术专家组成。TAB每年召开两次面对面会议，每两周召开一次视频会议。其主要职责是为Thoughtworks的首席技术官RachelLaycock和名誉首席技术官RebeccaParsons提供咨询建议。 BirgittaBöckeler BrandonByars SubBrhamaraniam 作为一个综合型组织，TAB能够审视影响Thoughtworks技术战略和技术人员的各种主题。本期技术雷达内容基于2024年2月技术委员会成员在纽约的面对面会议创建。 Rac（heClTLOa）ycock （ReCbTeOccEamPearristao）ns （CMhairetfinScFioewntliesrt） FalcCoanmiCirlliaspim ErikDörnenburg deFlaauTsotorre HaoXu JamesLewis MarisaHoenig MayaOrmaza MikeMason NealFord PawanShah ScottShaw SeNlvaateksuamnar ShangqiLiu SofiaTania VanyaSeth WillAmaral 本期主题 （或许）开源的许可证 在我们的会议中，关于许可证引发了两类讨论。首先，多年来，开源软件开发生态系统依赖于一组由开源倡议组织（OpenSourceInitiative，OSI）编录的许可证，大多数情况下仅使用流行的几种。然而，最近发生了一些变化。一些知名工具，最近因为其维护者突然从开源模式切换到商业模式而受到了一些负面评价。当然，我们愿意为软件付费，并且认可对于额外功能使用商业许可证的常见模式。只是我们觉得，当这种转变出现在一个受众广泛的工具的核心功能上，尤其是当一个生态系统已经围绕该工具发展起来时，这是有问题的。其次，另一个有趣的转变出现在一些自诩开源的软件上，其基本功能只有在消费者支付订阅费或其他费用后才能使用。尽管这种商业模式以前就存在，但似乎在许多闪亮的新AI工具中被更多地利用了——它们提供了一些在细则之下过于隐藏的惊人功能。我们建议特别关注许可证问题。在使用中要提起警惕，并确保存储库中的所有文件都受到顶层许可证的覆盖。 人工智能助力软件开发团队 显然，人工智能目前正在讨论中占主导地位：技术雷达中约有三分之一的类目与之相关。我们不仅讨论了面向开发者的人工智能工具，如GitHubCopilot，CodiumAI，aider和Continue，我们还探讨了如何在整个团队中全面使用AI、以及如何利用人工智能改变软件开发的各个方面。这其中包括一系列最终未能入选的工具，例如Warp这样的人工智能辅助终端，将截图转换为代码的能力、由LLMs支持的ChatOps以及许多其他主题。尽管开发人员工具正在发展的日臻成熟，但我们始终对于“软件开发的所有方面都可以从人工智能和相关工具的务实使用中受益”抱有怀疑，我们正在积极跟踪相关领域的创新。与此同时，在人工智能带来近乎神奇的新技能时，相关的质量与安全风险也在涌现，这需要团队保持警惕，包括让非开发人员意识到潜在的风险。 涌现的大语言架构模式 在技术领域，“模式”因为能够为特定问题提供一个简洁的解决方案名称而受到欢迎。随着大语言模型（LLMs）的日益普及，我们开始看到支持常见上下文的特定架构模式不断涌现。例如，我们讨论了NeMoGuardrails，它允许开发人员围绕LLM的使用建立治理政策。我们还讨论了像Langfuse这样的工具，它们能够更好地观察LLM的输出步骤，并知道如何处理（并验证）充斥着生成代码的臃肿代码库。我们讨论了如何使用检索增强生成（RAG），这是我们偏爱的模式，以提高LLM输出的质量，在企业生态系统中尤其有效。此外，我们还讨论了使用低能耗（和成本）大语言模型产生材料，然后由更强大（也更划算）的大语言模型选择性审查的技术。模式为技术构建了一个重要的词汇库，随着生成式AI继续渗透软件开发，我们预计会看到模式（以及不可避免的反模式）的爆炸式增长。 让PullRequest（PR）更接近正确的持续集成 Thoughtworks一直推崇在软件开发过程中采用快速反馈循环，因此也是持续集成（CI）的大力支持者。为此，我们在20世纪90年代末构建并开源了有史以来第一个CI服务器—CruiseControl。最近，我们的首席科学家MartinFowler在他的bliki上更新了对于持续集成的规范定义，以重申对这一实践的关注。然而，我们许多团队被迫忽视CI/CD中的CI部分，因为他们发现自己处于必须使用PullRequest（PR）的情况。尽管PR的做法最初是为了管理大规模分布式的开源团队和不可靠的贡献者，然而目前已经发展成了同行评审（PeerReview，PR）的同义词，即使在紧密工作的小型团队也是如此。在这些情况下，许多开发者渴望从实践真正的CI中获得相同的流畅感。我们调查了几个试图减轻PR审查过程痛苦的工具，包括gitStream和Github合并队列。我们还讨论了诸如stackeddiffs之类的技术，这些技术通过使集成过程更精细化，有望与CI的核心原则保持一致。除此之外，我们还探讨了从PR中提取度量的方法，以识别软件交付过程中的低效和瓶颈。工具在这个领域会起到巨大帮助，因为整体趋势是朝向生成式AI编程的。随着AI编码助手的出现，编码吞吐量增加，导致倾向于创建更大的PR。这给异步代码审查过程增加了更大的压力。尽管我们仍然更喜欢原始的CI实践，但我们鼓励那些由于外部约束而无法使用CI的团队寻找方法，从而提高集成准确性和反馈周期速度。 18 17 13 14 16 12 11 6 7 8 10 5 15 4 9 3 2 1 暂缓评估试验 采纳采纳 试验评估暂缓 66 65 69 67 68 71 70 72 47 50 7374 49 75 485153 55 56 7677 5254 57 78 58 79 59 61 80 44 60 81 45 62 63 82 46 64 83 28 20 29 21 19 30 22 31 23 32 33 25 34 24 35 26 36 37 27 38 39 41 40 43 42 104 103 87 102 86 101 100 85 9899 97 84 94 9596 92 105 93 90 91 88 89 新的挪进/挪出没有变化 ©Thoughtworks,Inc.AllRightsReserved. 技术 采纳 1.检索增强生成（RAG） 试验 2.自动生成Backstage实体描述符 3.将传统NLP与LLMs相结合 4.持续合规 5.边缘函数 6.安全标兵 7.TexttoSQL 8.追踪健康债务状况 评估 9.人工智能团队助理 10.对LLM对话进行图分析 11.基于大语言模型的ChatOps 12.大语言模型驱动的自主代理 13.使用GenAI理解遗留代码库 14.VISS 暂缓 15.广泛集成测试 16.过度热衷使用大语言模型 17.急于冲向大语言模型微调（fine-tuneLLMs） 18.适用于SSR网络应用程序的Web组件 平台 采纳 19.CloudEvents 试验 20.云上Arm 21.AzureContainerApps 22.AzureOpenAIService 23.DataHub 24.基础设施编排平台 25.Pulumi 26.RancherDesktop 27.Weights&Biases 评估 28.Bun 29.Chronosphere 30.DataOS 31.Dify 32.ElasticsearchRelevanceEngine 33.FOCUS 34.GeminiNano 35.HyperDX 36.IcePanel 37.Langfuse 38.Qdrant 39.RISC-V用于嵌入式 40.Tigerbeetle 41.WebTransport 42.Zarf 43.ZITADEL 暂缓 — 工具 采纳 44.Conan 45.Kaniko 46.Karpenter 试验 47.42CrunchAPIConformanceScan 48.actions-runner-controller 49.Android模拟器容器 50.AWSCUDOS 51.aws-nuke 52.Bruno 53.Develocity 54.GitHubCopilot 55.Gradio 56.GradleVersionCatalog 57.Maestro 58.MicrosoftSBOM工具 59.开放策略代理（OPA） 60.Philips'sself-hostedGitHubrunner 61.Pop 62.Renovate 63.Terrascan 64.Velero 评估 65.aider 66.Akvorado 67.百川2 68.CargoLambda 69.CodiumAI 70.Continue 71.FernDocs 72.Granted 73.LinearB 74.LLaVA 75.Marimo 76.Mixtral 77.NeMoGuardrails 78.Ollama 79.OpenTofu 80.QAnything 81.SystemInitiative 82.Tetragon 83.Winglang 暂缓 — 语言和框架 采纳 — 试验 84.Astro 85.DataComPy 86.Pinia 87.Ray 评估 88.安卓适应性 89.ConcreteML 90.Crabviz 91.Crux 92.DatabricksAssetBundl