要构建可靠的软件，程序规范很关键。没有良好定义的规范，很难诊断软件系统的异常行为。但是很多软件系统的程序规范定义得很差劲。而且更糟的，是许多软件系统根本就没有规范。
直观的看，程序规范是对程序行为的一种描述。它可以采取许多形式，但无论采取何种形式，都有一条主线贯穿所有实例：必须有某种类型的系统规范，因为您得依靠它来判断系统是否运转正常。
规范可以形式化也可以松散地定义，这取决于开发中系统的稳定性和危险程度，还与开发完毕后修改系统的容易程度有关。
我们将通过讨论规范为什么重要、为什么会经常被忽略以及如何改善这种情况来开始我们的这次“旅程”。
平衡精度的成本和收益
在微处理器设计世界中，系统部署在各种规模的应用上，从个人计算机到担负重任的医疗和军事系统。在这个领域中有一个普遍的、牢不可破的规则：在部署之后修改芯片设计的成本是极其昂贵的。
因此，通常会将微处理器的规范形式化，这也就不足为奇了。一个正式的规范有巨大的好处，因为能够自动地解释和分析它。就微处理器而言，设计的许多方面可以自动地被验证无误。
软件类比：编程语言
在软件世界中，在部署和危险程度方面，最类似于微处理器的事物是编程语言。一种普及的编程语言被用来编写无数的程序，它们被用于各种危险程度级别不同的系统中。
和芯片一样，在投入使用之后修改语言设计的成本是相当昂贵的，因为所有现有的程序都必须修改和重新编译。因此，与其它软件系统相比，编程语言的规范通常是相当正式的。
对于语法，这种形式化尤其重要。事实上，所有现代编程语言都拥有正式定义的语法。大多数解析器是通过使用自动的解析器生成器构造的，生成器读入这些文法并产生完整的解析器作为输出。
不幸的是，语言语义并不倾向于作这样严格的规定。这并非因为不能做到这样严格。
象 ML 这样语言拥有形式化的语义，并因此证明了许多关于它们的法则，用于验证其正确性的某些方面（譬如，它们的类型系统的完善）。但是象 ML 这样的语言是特例。我们可以确定造成这种情况的两个原因。
首先，因为证明关于编程语言规范的特性实际上比硬件设计更难以驾驭，所以不太需要正式的规范。相反，许多语言是用叙述性文字规定的。这些文字规范对于大多数实际使用语言的人（譬如编译器作者）来说已经足够了。实际上，编译器作者通常着迷于不太正式的规范，因为它给了他们更多优化程序的空间。另外，有些时候语言的使用者是程序员，他们中的大多数很欣赏非正式规范，因为这样他们可以轻松地理解规范。
第二个理由是，许多语言是由单独的开发人员作为“业余爱好”开发的，而他们往往并不专长于编程语言领域。遗憾的是，这些开发人员常常并不了解为规定编程语言语义而开发的形式体系。
模棱两可的成本的示例
然而，语言规范中的模棱两可或不一致造成的成本可能是相当昂贵的，会导致可移植性、可靠性的降低，甚至会造成安全性漏洞。通过研究一些当前广泛使用的语言，可以发现它们的规范中相对的精确程度是如何影响它们的。
C++ 语言的规范有许多模棱两可的地方，甚至在语法级别也有。此外，规范的许多部分是变成依赖于实现的。结果是：C++ 程序通常很难在多种平台上按预期的那样运行。
Python 语言规范遗留了许多依赖于实现或未定义的细节。结果，诸如 Jython 和 CPython 之类的实现，在提供与另一方相同的行为这个方面，面临着巨大难题。如果不是因为 Python 语言相对比较简单（并非贬义），这一问题还会更糟。
尽管 Java 语言没有正式的规范（类似于 ML 那样的），但是在精确的非正式规范的开发上投入了很多努力。该语言通常编译成由 JVM 解释的字节码，而 JVM 本身具有良好的规范（尽管通过正式分析在该规范中发现了一些模棱两可的地方）。此外，Java API 都作为 JVM 的一部分规定。这使得 Java 代码具有空前程度的可移植性。
我们从中可以得出结论，一份尽可能精确的语言规范会非常有用。但即使在编程语言世界中，规范中的问题也是最昂贵的，精确的规范很少，部分原因在于预先制作一份精确规范很昂贵。
许多公司发现成本更低的做法是先交付产品，以后（或者很可能永远也不会）再充实规范细节。诚然，对于生命周期较短以及部署范围较窄的应用程序，预先定义精确规范确实是太昂贵了。有时可能竞争对手早已交付了系统，而开发团队还未正式确定其系统的规范。
此外，大型规范很少在用户需求更改时更新，并且因此被忽略了。但是如果预先定义规范太昂贵，开发团队应该采取什么方法来规定他们的软件呢？
在回答这个问题之前，让我们考虑一下一个常用的，但也确实是最糟糕的方法吧。