往事回响：SDD 与已知范围的错觉

超现代的智能体时代最引人注目的方面之一是早期试图驯服软件开发的种种尝试正在回归。最新复兴的趋势被称为规范驱动开发Spec-Driven DevelopmentSDD。SDD 的显著之处在于它复兴了一种信念代码只是一种附属品。本文通过一个经历过过去建模时代的人的视角来探讨 SDD。我承认这次可能不同但我将把我的担忧集中在实现只是已知范围的执行这个有缺陷的观念上。实际上实现是发现过程本身不可或缺的一部分。我们离它越远就越困难。1、快速回顾什么是 SDDSDD 的核心思想是将预期行为捕捉在一个结构化的规范中。然后让编码智能体执行由此产生的任务并在过程中生成设计文档等。然而正如 Birgitta Böckeler 指出的那样SDD 似乎有多种形式。它可以是从相对轻量级地驱动智能体的方式到规范本身就是事实真相的强形式。我关心的是后者。风险在于 SDD 成为一种古老的经理梦想的最新迭代让你的高级人员指定要构建什么然后将其传递给看似简单的实现同时假装这一步是可预测的且不那么重要。在 1990 年代实现意味着一个被蒙在鼓里的编码团队。今天显然是智能体。这个过程当时运作得并不好。由于软件交付的节奏和期望现在提高了几个数量级我对这次 SDD 能运作得有多好持怀疑态度。不是因为瀑布思维——许多 SDD 从业者迭代地演进他们的系统——而是因为问题解决的本质。2、驱动力对可预测性的需求软件开发正处于一个十字路口。智能体革命最好的可能结果是我们提高了软件工程的门槛。我们知道什么对我们有益强大的自动化测试套件、持续交付、小的增量、模块化架构和一流的代码质量。我们也知道生成式 AI 是随机性的。但是一群人类协作开发软件也是如此。如果历史教会了我们什么的话解决方案不仅仅是更好的输入还有更快的反馈循环。让我通过回到模型大战的时代来详细说明。3、皇帝的新可执行衣裳SDD 与几十年前幸好已经远去的模型驱动架构Model-Driven Architecture、可执行 UML 和辉煌的 Rational 统一过程RUP有着强烈的相似之处。在我职业生涯的早期我在两家不同的公司使用过这些技术。在第一家我们有一个有效的设计评审流程。作为开发者我基本上会把软件设计勾画为 UML 类图用一些序列图补充动态行为然后为我的同行做一次走查。是的这个过程很慢。但我们设计的通常能作为实现方向的指导。真正的优势是由此产生的 UML 图很好地服务于入职培训和扩展。很容易获得解决方案的高层视图这在后来深入代码时很有帮助。到目前为止还不错。然后工具供应商来了。我的意思是如果你已经勾画出了你的设计为什么不把它完成一个闭环从那个草图生成所有代码呢毕竟代码只是一个实现细节对吧所需要的只是用一种动作语言来扩展 UML以捕捉那些细节。在实践中效果如何哦第一个牺牲品是被记录的设计。可执行图表变得如此臃肿和冗长以至于完全无法理解。毕竟新的受众是编译器不是人类。变更和扩展变得痛苦。你看我们习以为常的所有那些强大工具——构建管道、命令行实用程序、IDE、代码检查器等——在供应商的设计工具中都不存在。想象在 Microsoft Word 文档中编码。那就是那种感觉。4、强规范的认知陷阱工具只是模型驱动灾难的一部分。更大的问题是当时的流程思维方式。敏捷是全新的除了狭窄的程序员圈子之外很少有人熟悉这个运动。几乎我合作过的每家公司都在瀑布模式下运作。然而那时对软件交付的期望完全不同。今天每日部署成为标准我们承受不起在反馈上反应迟缓。人类的问题解决本质上是迭代的由行动中的反思驱动。我们在做中学。用代码表达一个想法测试它观察学习。这个循环扩展了我们对试图解决的问题的理解。然后这种改进的理解被转化为对程序的修改我们反过来从中观察和学习。周而复始。我们无法绕过这个过程。不我不是说我们不应该在早期深思熟虑。我们应该。我们也应该把东西写下来使之更加具体并引发对话。这也有助于思考。但我们需要把那份文档视为一个不完美的起点而不是成品。5、代码最被低估的方面需求爆炸如果我们基于一个规范来工作仿佛问题已经被理解了主要挑战就开始了。原因是需求爆炸的概念。这个术语由 Robert Glass 首次提出。Glass 认为问题复杂度每增加 10%软件解决方案的复杂度就会增加 100%。换句话说规范中的每个需求将导致数十个需要解决的隐含设计需求。我们不能把那些留给智能体去猜测。要让 SDD 发挥作用我们必须提供指令让智能体解决所有这些隐含需求中的很大一部分。那么我们不能用详细的解决方案模型来补充我们的规范吗我们可以。但那将使我们面临三个主要障碍自由文本缺乏精确性。是的我们可以在文本中解释约束等但那会变得冗长且难以检查。即使是结构化散文和检查清单也留有歧义的空间。这就是我们有编程语言的原因。它们非常适合捕捉旨在给机器的精确规则。我们无法提前知道解决方案需求。记住我们在做中学。如果我们不做而是让智能体替我们做决定那么推导和捕捉解决方案需求就会变得困难几个数量级。想想逆向工程一个遗留代码库。那就是我们将处于的位置。不断地。用实现细节和契约扩展需求规范会使模型模糊这是在 MDA/UML 时代打击最大的一点模型开始变成实现并失去了作为概览、不同抽象层次的价值。代码需要另一个层次的精确度。当模型成为实现的那一刻它就不再是一个好模型了。6、另一条前进之路SDD 是我会继续观察但目前不会参与的东西。然而这并不意味着我不重视结构和一定的可预测性。只是意味着我们应该在其他地方寻找这些品质。可预测的进展建立在领域专业知识、意图揭示的软件设计、代码及其行为的自动化保障措施和快速的视觉反馈之上所有这些都由一支高技能团队放大。这些能力比编写规范更难培养。但它们也更有价值。无论有没有 SDD。原文链接往事回响SDD 与已知范围的错觉 - 汇智网