PHP 至少是一门有趣的编程语言。这门语言和用它构建的程序通常属于两种设计哲学。在这里，我所说的并非软件开发生命周期，如瀑布或敏捷，而是关于软件应该是什么样的基本思想。这些思想被称为“正确的方式”（The Right Way）和 “更糟就是更好”（Worse is better）。

PHP 又是一门相当奇怪的编程语言。当人们抱怨这门语言“很槽糕”时，他们并没有说错。这门语言确实有很多不好的地方。

搁在以前，这门语言还有更多糟糕的问题。嘲笑 PHP 的博文《全面解析 PHP 的槽糕设计》（PHP: a fractal of bad design）确实有几个正确的观点，即使这些观点在九年前发表时就已经过时了。

然而，与此同时，开发人员却可以利用 PHP 创建结构上“正确”的软件，并从其他语言中引入被视为良好实践的哲学。

像 Laminas 和 Symfony 这样的框架就使用了面向对象编程的最佳实践，使开发者可以用这些框架编写结构正确的代码。

PHP 是怎么做到这些的？这是因为 PHP 是最糟糕的编程语言。

设计软件

1991 年，Richard P. Gabriel 发表了一篇文章《Lisp：好消息，坏消息，如何赢得大》（Lisp: Good News, Bad News, How to Win Big）。这篇文章的论点是，在软件设计和寿命方面，“更糟就是更好”的哲学将是更好的选择。

他之所以得出这一结论，是因为他意识到出现了两种不同的程序设计流派，他分别将之命名为“麻省理工学院 / 斯坦福风格”（MIT/Standford Style），或者“正确的方式”，以及“新泽西风格”（New Jersey Style）或者“更糟就是更好”。

这两种哲学的目标相似，但在关键领域却有所不同。两种风格都侧重于哲学理念的四个关键领域：简单性（Simplicity）、正确性（Correctness）、一致性（Consistency）和完整性（Completeness）。

麻省理工学院风格是这样描述的：

简单性：设计一定要简单，不论它的实现还是接口，都一定要简单。相较而言，让接口保持简单更重要。正确性：在所有可以观察到的方方面面，设计一定要正确。不要妄想做一个不正确的设计。一致性：设计一定不能是不一致的。为了确保一致性，你可以略微牺牲简单性和完整性。一致性和正确性同等重要。完整性：设计一定要尽可能多地涵盖重要的情况。所有符合预期的情况一定要被覆盖到。完整性优先级应该高于简单性。

至于新泽西风格，Gabriel 说，它将其目标定义为：

简单性：设计一定要简单，不论它的实现还是接口，都一定要简单。而相较而言，让实现保持简单更重要。简单是最重要的，其他的特性都不如保持简单更重要。正确性：在所有可以观察到的方面，设计一定要正确。但是可以为了简单而轻微牺牲正确性。一致性：设计一定不能太过不一致。某些情况下，为了保证简单可以牺牲一致性。如果将某个不常见的情况引入设计，会导致实现变复杂或者不一致，那么就不要考虑这种情况。完整性：设计一定要尽可能多地涵盖重要的情况。所有符合预期的情况一定要被覆盖到。完整性可以为任何其他特性让步。实际上，一旦威胁到实现的简单性，完整性必须要被牺牲。如果为了保持简单，可以牺牲一致性来实现完整性；尤其是接口的一致性。

这场争论的关键是用 LISP 和 C 作为例子来说明为什么“更糟就是更好”。对于 LISP 程序员 Gabriel 来说，LISP 是一种比 C 更好的语言，速度和 C 一样快，而且 Common LISP 的设计、开发和标准化已经花了很多年。

定义该语言的规范吸取了所有不同的 LISP 的精华，而现代开发环境对于 LISP 开发者来说是最好的。

LISP 是正确的方式

LISP 代表了软件开发的“正确的方式”。LISP 易于交互，你可以通过各种方式与它交互。希望从 Fortran 中调用 LISP？

你可以从 Fortran 中调用 LISP 并将数据传入，反之亦然。在使用遗留代码时，你可以愉快地使用 LISP 的所有现代“豪华”特性。

LISP 拥有一致的设计，这得益于它的规范。假如你研究一下 Python 这样的现代语言，规范在提供多个后端和编译器方面有很大的作用，而且它们都以同样的方式解释或编译代码。

这些工具是一流的，1991 年的 LISP 拥有我们今天仍然享受的所有舒适，比如步骤调试、数据检查和花哨的编辑器。

作为一种语言，LISP 是完备的。它具有先进的面向对象编程层、多重继承、一流的对象以及函数和类型。LISP 似乎是开发人员心中想要的编程语言。

1991 年，LISP 这么编程语言可能处于有史以来的最佳状态。这种技术上的正确性并没有被实际使用所证实。

LISP 的开发商正在衰退。多年来负面新闻和错误定位阻碍了 LISP 的外部声誉。人们不再将其视为向最终用户交付软件的方式。

就开发而言，LISP 往往代表着许多与“大规模预先设计”（Big Design Up Front，BDUF）一样的理想。

假如你曾经使用过瀑布模型（Waterfall Model）这样的设计方法，你就会发现一些问题。“正确的方式”非常强调一致性、正确性，并确保考虑到所有能想到的问题。

LISP 本身并非一种单一的语言，而是一个语言家族。尽管 Common LISP 被设计成一种标准，但是 LISP 本身的实现方式是根据需要完成的各种工作而存在的。

Lockless Inc 网站上的一篇文章指出，这种“碎片化”是 LISP 最终失败的决定因素之一。尽管 LISP 坚持软件设计的“正确的方式”，但是这种碎片化导致代码维护和可移植性都受到了影响。

PHP 是最槽糕的

因此，“更糟就是更好”的软件首先会被接受，其次它会使用户期望更少，第三，这些软件将被不断改进，直到接近“正确的方法”的程度。——Richard Gabrie

在这一启示的几年后，Ra *** us Lerdorf 开始研究个人主页 / 表单解释器，也就是我们现在所知的 PHP。

PHP/FI 的诞生是因为 Lerdorf 需要维护他的主页，并与表单和数据库进行交互。PHP/FI 甚至不是作为一种实际的编程语言设计的，而是作为 C 语言之上的一层脚本和函数设计的。

PHP 很简单

设计一定要简单，不论是它的实现还是接口。

PHP 底层使用了 C 语言，我们之前已经说过，这部分是“最糟糕的”。然而，这也带来了一些优势，最重要的是，更简单的底层语言可以让它更容易扩展。虽然 Hack/HHVM 采用了更多的 C++ 方法，但 PHP 本身仍然是 C 语言。

只需短短几个小时就能学完这门语言的内部结构。Elizabeth Smith 发表过一篇关于 PHP 扩展的精彩演讲，其中介绍了大量关于 PHP 的内部工作原理。这门语言本身借鉴了其他 C 风格的语言，不仅易于阅读，并且能够跟 C 风格的其他语言互相转换。

PHP 的大多数接口，或者说标准库，都非常简单，因为大多数核心功能都只不过是包装了各种 C 语言库，然后几乎原封不动地公开出来。尽管这样做会导致接口上的一些不一致，但是它为来自 C 或 C++ 的开发者提供了一个熟悉的环境。

PHP 语言非常注重于 Web 开发。将 HTTP 中的概念提取出来并在语言中找到相似的概念通常非常简单。希望了解一个请求的头信息吗？get_headers() 就能满足你。获取请求信息就像读取 _POST 全局变量一样简单。

PHP 保持了简单的开发者接口，并且尽可能地保持内部结构的简单。

PHP（几乎）是正确的

在所有可以观察到的方面，设计一定要正确。但是可以为了简单性而轻微牺牲正确性。

在这里，PHP 倾向于选择“简单”而不是正确。在 HHVM 出现之前，语言的外观和特性一直没有得到规范。

Zend 解释器本身就是规范，并且这门语言的行为方式总是 “正确”的（不包括实际的错误）。要想用别的东西代替 PHP 引擎，就必须实现现有引擎的所有特性。

许多核心函数的 LAX 函数参数和返回类型都使得系统的工作更容易。像 strpos() 这样的函数返回值可以是整型数或布尔值，相对于严格设计成返回整型数或抛出异常的方法，处理要稍微容易一些。

看 PHP 语言的发展，几乎所有新特性都是建立在开发人员需要的基础上，而不是“因为它错了所以必须修复”的严肃想法。

更多地关注那些严格类型和异常错误是一种更正确的做事方法。然而，还有一些东西，比如简短的箭头函数（arrow function）、属性和枚举，才是开发者想要用来简化代码的东西。

PHP 不需要一致性

设计一定不能太过不一致。某些情况下，为了保持简单可以牺牲一致性。

我甚至不打算假装 PHP 是一致的，但是它的一致性已经足够了。当涉及到数组与字符串函数时，人们可能会抱怨 needle/haystack 参数顺序。

不过，一般而言，数组函数是一致的，而字符串函数也是一致的。与底层 C 库保持一致比在语言中保持一致要简单得多。

PHP 在其他方面也足够一致。正如我在 strpos() 中提到的，PHP 对于遇到错误的函数往往会相当一致地返回 FALSE。这未必是正确的，但它却是一致的。带下划线和不带下划线的函数名通常都会匹配其基础库。

为了简单起见， PHP 语言牺牲了一致性，但是即使没有这个规范，它仍然努力在有意义的地方保持一致。

PHP 的完整性符合所需

设计一定要尽可能多地涵盖重要的情况。

无论何时，在针对 PHP 需求最大的设计任务：编写 Web 应用程序时，PHP 都是完备的。PHP 从未被设计成一种可以适用于编程世界所有问题的语言。

尽管如此，它的简单性还是使它可以用于 Web 以外的场合。PHP 最初的目的就是为 Web 编程提供最基本的功能，这一趋势一直持续至今。

修改核心语言通常是由开发人员的需求驱动。整个社区提出修改意见，然后经由社区投票，决定新特性被拒绝、改变或者接受。该语言的许多创新都源于快速完成工作的需要。

即便我们吸收了其它语言的功能，也是因为它使我们的开发变得简单，而很少是因为其他语言做得“更正确”。

今天，你可以用 PHP 开发 Web 应用程序。五年后，你仍然可以用 PHP 开发 Web 应用程序，只不过会增加一些新特性。

但是，语言本身的完整性已经符合今天所需。如果未来有需要，我们可以随时修改语言或为它添加新功能。

更糟就是更好吗？

Gabriel 承认，“更糟就是更好”的哲学指的是设计看起来很糟糕，也许不应该作为更好的选择。唯一的问题是，当他审视这两种哲学时，与麻省理工学院 /“正确的方式”的设计哲学相比，“更糟就是更好”最终仍然是更灵活的选择，“具有更好的生存特性”。如果我们看一下 PHP，就可以证实“更糟就是更好”这一观点。

这些年来，Gabriel 承认他在哪种方式更好之间摇摆不定。PHP 社区一直在争论我们是应该正确地做事还是继续简单地做事。

我们有像 Laminas 这样的框架，以经典的计算机科学方式构建库，然后我们有像 Laravel 这样的框架，关注开发者的体验和速度。PHP 本身二者兼具。

下次再听到有人骂 PHP 的时候，就随他喷去吧。这门语言确实很糟糕。但从许多方面来看，PHP 的长寿和广泛使用证明了这样一个事实：用“正确的方式”做事并不总是比用“最糟糕”的方式做事好。

当有人吐槽你正在使用的框架时，你要明白从长远来看这并不重要。选择一种你认为适合自己的设计哲学，并欣然接受这一点：更糟的可能实际上是更好。