足够全面的规范并不（必然）就是代码

<p>上周缺席了，抱歉！生病了，然后又忙了起来。</p> <p>本周我想谈谈我的一个心头刺，在这幅漫画中表现得淋漓尽致：</p> <p><a href="https://www.commitstrip.com/en/2016/08/25/a-very-comprehensive-and-precise-spec/?" target="_blank"><img alt="一幅关于业务人员认为详细规范能取代程序员，而程序员则称该规范为“代码”的漫画" class="newsletter-image" src="https://www.commitstrip.com/wp-content/uploads/2016/08/Strip-Les-specs-cest-du-code-650-finalenglish.jpg" /></a></p> <p>“全面且精确的规范”并不必然就是代码。一个规范对应一组<em>可能的</em>实现，而代码是该组中的一个具体实现。只要该组包含的元素不止一个，规范和代码之间就有区别。</p> <p>考虑一个业务人员（bp）提出的需求：</p> <blockquote> <p>我想要一个能将英里转换为公里的工具。</p> </blockquote> <p>这是一个全面的规范吗？也许吧，你可以把它交给 Claude Code，让它做出所有设计决策，它就会给你一个能将英里转换为公里的程序。但同时，这里面遗漏了大量细节。用什么语言？用户体验如何？应该是命令行脚本、移动应用还是企业级 SaaS？正因如此，如果我们把 Claude 的输出交给业务人员，他们很可能会不满意。可能的实现集合中既包含他们想要的程序，也包含大量他们不想要的程序。</p> <p>于是他们现在说道：</p> <blockquote> <p>它应该是一个网站上的文本框。</p> </blockquote> <p>好吧，这排除了很多可能性，但仍有很多东西需要决定。用 React、vanillajs 还是 htmx？输出应该是一个单独的文本框还是一个弹出窗口？应该使用 <code>1.6</code>、<code>1.61</code> 还是 <code>1.609</code> 的换算系数？因此你可以争辩说，这仍然不是什么“全面且精确的规范”。但如果业务人员对 Claude 做出的任何东西都满意呢？那么他们的规范就已经足够全面且精确了，因为他们得到了一个能解决问题的程序！</p> <p>现在，上面的漫画提出了一个更具体的论断：一个规范“足够全面且精确，以至于<em>能生成一个程序</em>”就是代码。这个论断在 LLM 出现之前都不成立。<a href="https://en.wikipedia.org/wiki/Program_synthesis" target="_blank">程序合成</a>，即根据规范自动生成符合要求的程序，是一个活跃的研究领域！据我上次（2019年）的了解，他们只能从类型规范生成局部函数；我不知道随着 LLM 的出现情况有何变化。但这仍然表明，代码和全面规范是两码事。</p> <h3>规范是抽象</h3> <div class="subscribe-form"></div> <p>我要说的是，规范是代码的一种<strong>抽象</strong>。<sup id="fnref:abstraction"><a class="footnote-ref" href="#fn:abstraction">1</a></sup>对于每个规范，都存在一组满足该规范的可行程序。规范越全面、越精确，这组程序就越小。如果 <code>spec1</code> 对应于 <code>spec2</code> 的一个超集，我们就说 <code>spec2</code> 是 <code>spec1</code> 的<strong>精化</strong>。如果一个规范不需要进一步精化，即无论提供何种实现（<em>合理范围内</em><sup id="fnref:reason"><a class="footnote-ref" href="#fn:reason">2</a></sup>），规范制定者都会满意，那么这个规范就是<strong>充分的</strong>。一个规范不需要面面俱到才能算充分。</p> <h3>程序员仍然需要编写规范</h3> <p>这幅漫画还提出了另一个论断：“足够详细的规范就是代码”是程序员不会失业的一个理由，即使我们可以从规范自动生成代码。这个论断仍然成立。</p> <p>我们通常会用形式化语言来表达抽象规范。通常这让我想到 TLA+、UML，甚至 <a href="https://syque.com/quality_tools/tools/Tools104.htm" target="_blank">Planguage</a>，但最常见的例子是测试套件。<a href="https://buttondown.com/hillelwayne/archive/what-is-a-specification" target="_blank">测试也是一种规范！</a>一般来说，让非程序员成功地将东西编码成形式化语言似乎是不可能的。Cucumber 就是一次失败的尝试，它试图让业务人员编写形式化规范。</p> <p>但这是否意味着一个全面的规范就是“代码”？我不同意。用编程语言编码一个规范是可行的（再次以测试套件为例），但这仅仅是一种编码。规范仍然对应一组可能的实现程序，即使我们不将其编码，规范依然有用。将“代码”和“规范”作为不同的概念保留下来是有益的。</p> <p class="empty-line" style="height:16px; margin:0px !important;"></p> <div class="footnote"> <hr /> <ol> <li id="fn:abstraction"> <p><a href="https://www.pathsensitive.com/2022/03/abstraction-not-what-you-think-it-is.html" target="_blank">必点链接</a>&#160;<a class="footnote-backref" href="#fnref:abstraction" title="跳回正文脚注1">&#8617;</a></p> </li> <li id="fn:reason"> <p>即实现方应善意地尝试做出合理的实现。例如，“这个程序将英里转换为公里，同时还挖矿”就不是善意的解读。&#160;<a class="footnote-backref" href="#fnref:reason" title="跳回正文脚注2">&#8617;</a></p> </li> </ol> </div>