技术雷达

在我们的会议中，关于许可证引发了两类讨论。首先，多年来，开源软件开发生态系统依赖于一组由开源倡议组织（Open Source Initiative, OSI）编录的许可证，大多数情况下仅使用流行的几种。然而，最近发生了一些变化。一些知名工具，最近因为其维护者突然从开源模式切换到商业模式而受到了一些负面评价。当然，我们愿意为软件付费，并且认可对于额外功能使用商业许可证的常见模式。只是我们觉得，当这种转变出现在一个受众广泛的工具的核心功能上，尤其是当一个生态系统已经围绕该工具发展起来时，这是有问题的。其次，另一个有趣的转变出现在一些自诩开源的软件上，其基本功能只有在消费者支付订阅费或其他费用后才能使用。尽管这种商业模式以前就存在，但似乎在许多闪亮的新 AI 工具中被更多地利用了——它们提供了一些在细则之下过于隐藏的惊人功能。我们建议特别关注许可证问题。在使用中要提起警惕，并确保存储库中的所有文件都受到顶层许可证的覆盖。

显然，人工智能目前正在讨论中占主导地位：技术雷达中约有三分之一的类目与之相关。我们不仅讨论了面向开发者的人工智能工具，如GitHub Copilot， Codium AI， aider和Continue，我们还探讨了如何在整个团队中全面使用 AI、以及如何利用人工智能改变软件开发的各个方面。这其中包括一系列最终未能入选的工具，例如Warp这样的人工智能辅助终端，将截图转换为代码的能力、由 LLMs 支持的 ChatOps以及许多其他主题。尽管开发人员工具正在发展的日臻成熟，但我们始终对于“软件开发的所有方面都可以从人工智能和相关工具的务实使用中受益”抱有怀疑，我们正在积极跟踪相关领域的创新。与此同时，在人工智能带来近乎神奇的新技能时，相关的质量与安全风险也在涌现，这需要团队保持警惕，包括让非开发人员意识到潜在的风险。

在技术领域，“模式”因为能够为特定问题提供一个简洁的解决方案名称而受到欢迎。随着大语言模型（LLMs）的日益普及，我们开始看到支持常见上下文的特定架构模式不断涌现。例如，我们讨论了NeMo Guardrails，它允许开发人员围绕 LLM 的使用建立治理政策。我们还讨论了像Langfuse这样的工具，它们能够更好地观察 LLM 的输出步骤，并知道如何处理（并验证）充斥着生成代码的臃肿代码库。我们讨论了如何使用检索增强生成（RAG），这是我们偏爱的模式，以提高 LLM 输出的质量，在企业生态系统中尤其有效。此外，我们还讨论了使用低能耗（和成本）大语言模型产生材料，然后由更强大（也更划算）的大语言模型选择性审查的技术。模式为技术构建了一个重要的词汇库，随着生成式 AI 继续渗透软件开发，我们预计会看到模式（以及不可避免的反模式）的爆炸式增长。

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 的团队寻找方法，从而提高集成准确性和反馈周期速度。