PHPをご存知ですか？

　　PHP 的初期

　　我在大约 10 年前开始开发 PHP。那时在名词“开放源代码”出现且 GPL 和自由软件广为人知之前很久。正如许多已经变得流行的开放源代码项目一样，动机决不是哲学上的或者甚至是自我陶醉。它纯粹是因为需要一种工具来解决现实中与 Web 相关的问题。在 1994 年，当提到 Web 开发工具时，选择相当有限。我发现当我自己在用 C 或 Perl 为 Web 站点编写动态组件时，从一个问题到另一个问题的代码重叠现象十分显著。出于性能的考虑，我越来越远离 Perl，而倾向于 C，因为必须将 Perl 作为一个单独的 CGI 运行的 fork+exec 开销限制性太强了。

　　PHP 最早的未发布版本主要是常用 C 函数的一个 C 资料库，我编写了这些 C 函数，以便能够容易地从一个开放源代码项目到另一个开放源代码项目进行重用。我有一个简单的状态机驱动的分析器，它从 HTML 文件中挑出标记，然后调用我编写的后端 C 函数。这些代码最初是作为一个称为个人主页工具 (Personal Home Page Tools) 的程序包公开发布的，这个程序包中的每个工具都是关于如何使用系统来解决关于个人主页的常见问题的一个例子。在之后的某段时间，我从中分出了一部分工具并把它称为 FI，代表表单解释程序 (Form Interpreter)。FI 幕后的想法是，当您接收到一个表单提交的结果时，您需要做一些常见的事情，而它能够处理所有这些事情。一些早期的例子：

Hey, you are using Netscape!

Sorry, that record does not exist

Welcome !

You have credits left in your account.

　　我的 FI 的分析器非常糟糕，这促使我试着去编写一个更好的分析器。我抛弃了 语法，而改用 ，重新将 Personal Home Page Tools 的某些部分和这个新的 FI 工具结合起来，并在 1995 年底将它作为一个名称为 PHP/FI （这个名称有点半开玩笑性质地模仿了 TCP/IP）的程序包对外发布。PHP/FI 在接下来的几年里正好和 Web 一起得到了发展。在 1997 年，两个正使用 PHP/FI 的以色列人 Zeev Suraski 和 Andi Gutmans 问我是否有兴趣使用一个新的分析引擎，他们将为下一个版本的 PHP 编写这个引擎。我召集了其它一些一直在为 PHP/FI 提供补丁和代码的人，我们共同协作在 1998 年中期发布了 PHP 第 3 版。这可能是 PHP 发展期间最关键的时刻。如果这个项目一直是一个人在努力，那么当时它可能已经失败了，如果一群刚刚组合在一起的陌生人弄不清楚如何朝着一个共同的目标去努力，那么这个项目也可能很容易就失败了。无论怎样，我们设法解决了我们以自我为中心的问题和其它的个人问题，这个项目成长了起来。为这个项目做出贡献的人的数量在稳定地增长，现在我们打算在 2004 年上半年的某个时候推出 PHP 5.0 版本。

　　编程语言中的“丑小鸭”

　　关于 PHP 的流行观点可以分为两个极端。语言纯化论者往往不喜欢许多有点随意的特性实施和这些年来出现的一些前后不一致的地方。同时，实际问题的解决者往往喜欢 PHP 似乎已经读懂您的意图，并表现出它就是理想的 Web 问题解决工具。

　　在使纯化论者抓狂的事情中有：函数名称不区分大小写但变量名称区分大小写；内置函数的名称前后不一致；没有强制 PHP 开发人员使用任何真正的结构，从而使得很容易写出凌乱的代码。实际上我不得不同意这些批评意见，但我至少可以试着解释一下我们如何以及为什么到了这种状态。

　　首先，关于函数名区分大小写的问题：这可以回溯到最早的 PHP 版本。在 Web 的早期（XHTML 之前很久），所有的 HTML 标记标签都是大写的是很常见的。但因为这些标签是不区分大小写的，所以人们在这上面并不是非常一致。我希望人们对待具体的 PHP 标签基本就像和对待其它的标记标签一样，这意味着 PHP 的标签也将是不区分大小写的。当 PHP 变得更加高级并且拥有了如变量之类的特性时，使这些新的特性区分大小写并没有什么害处，因为它没有破坏对已有的 PHP 页面的向后兼容性。回过头去，突然处理最初的简单标签（这些标签实质上只是函数调用）时，区分大小写将破坏那些页面，并使它们在更新的 PHP 版本中不可用。无论如何，人们不应该拥有只是名称大小写不同的函数。尽管如此，回想起来，当相对少的人在使用 PHP 时，尽早地打破向后兼容性是个好主意；但在那时，没有人预料到 PHP 的惊人成长。

　　至于函数命名本身，我往往是从我熟悉的其它语言和 API 借鉴一些想法。这意味着 PHP 拥有诸如 strlen() 和 substr() 之类的函数，它们如果写成 str_len() 或 sub_str()，那看起来将有点可笑。我增加了如 stripslashes() 之类的函数，这些函数由于长度的原因常常被写为 StripSlashes()，以使其更易于读懂。同时，我模仿了底层的数据库 API，诸如函数 msql_connect() — miniSQL 是第一个被 PHP 支持的数据库 — 它们可使用下划线命名。熟悉这些不同来源的人将非常熟悉 PHP 中的命名。当 PHP 作为 Web 服务器和您想要挂在 Web 服务器上的所有不同后端工具之间的一个接口时，它并不是这样一种独立的语言。因此，今天当人们看到 PHP 作为一种独立的语言，而没有考虑其前后关系的时候，它可能看起来有点前后不一致。

　　关于缺少强制的结构，我能说的是，我绝对痛恨使我限制在解决问题的某种特定方法上的编程框架。这不意味着我不相信结构和框架，但我的确相信人们能够提出他们自己的、与他们的环境相称的方法。在本文稍后我论述各种 PHP 项目的可能体系结构时，将更多地涉及这个问题。

　　所有这些归结为 PHP 从来不打算去赢得任何“选美比赛”。它的目的不是要引入任何新的革命性的编程范例。它的目的是解决单个问题：Web 问题。这种问题可能会相当难看，有时您需要一种难看的工具来解决难看的问题。实际上，虽然一种漂亮的工具也可能解决问题，但常常一种难看的 PHP 解决方案能够更快速地得到实施，并且使用更少的资源。这大概总结了这些年来 PHP 的固执的“功能优于形式”的方法。

　　给设计师的建议

　　PHP 的最流行的部署模式是将它直接和预先分支的多进程 Apache 1.3.x Web 服务器连接起来。和使用 Java 不同的是，不存在独立的过程（如 JVM）。PHP 类似于如 Perl 和 Python 之类的脚本语言，在这些脚本语言中，直接分析和执行脚本。

　　没有中央控制过程是一个特色，同时也是给许多人带来极大挫折的原因。PHP 不共享任何体系结构 — 其中每条请求都完全不同并且可以同其它任何请求分开 — 使这种语言本身具有无限的平行可伸缩性。PHP 鼓励您把可伸缩性问题放到需要它的层次上去。如果您需要共享的数据存储，那么就使用一个支持复制和能够扩展到您需要的层次上的数据库。如果您需要负载均衡请求或将特定的请求分配到特定的服务器上，那么就使用一个支持这种功能的前端负载均衡器。通过消除中央控制过程，PHP 避免了成为系统中的瓶颈。这是使 PHP 区分于人们通常称之为应用服务器的工具的判定特性。

[oarch1.png] 用于高端 PHP 部署的一个非常常见的体系结构

　　在上图中，一个或更多的负载均衡器将进入的请求分配在任意数量的 Web 服务器上。考虑到数据存储，您可能在每个 Web 服务器上部署一个只读的数据库拷贝（如果数据集足够小，允许您那么做的话），或者您可能创建一个单独的数据库服务器树来处理各种类型的请求。

　　增加结构

　　PHP 超过其它许多针对解决 Web 问题的工具的巨大优势之一是，其它的工具往往把这种非常具体的目标问题的解决和从结构上控制用户解决问题的方式的要求联系在一起。PHP 不强制使用任何这种结构，相反选择专注于使问题的各个单独的功能方面尽可能地易于使用。例如，PHP 提供目的性非常强的函数来与后端数据库通信。这些函数是各个数据库专用的，并且不牺牲任何性能来获取和其它后端数据库的统一性或一致性。在文件布局方面，也没有规定的方法来构建 PHP 应用程序的结构。

　　PHP 不强制使用结构的事实并不意味着您不应该以一种井然有序和结构化的方式来构建 PHP 应用程序。当人们问我将如何着手构建一个大型 PHP 应用程序的结构时，我喜欢向他们展示下面这种方法。

   +--------------------------------+
   |     HTML TEMPLATES             |
   |     $DOC_ROOT/*.php            |
   +--------------------------------+
   |     TEMPLATE HELPERS           |
   |     $DOC_ROOT/*.inc            |
   +--------------------------------+
   |     BUSINESS LOGIC             |
   |     /usr/local/php/*.inc       |
   +--------------------------------+
   |     C/C++ CORE CODE            |
   |     /usr/local/lib/php/*.so    |
   +--------------------------------+

　　这个分四个层次的方法解决了一些问题。首先，它将一个典型项目中的内容沿着职责的线索分开。Web 前端开发人员从顶层进行工作，后端工程师从底层进行工作。他们在模板助手层有一点交叠。它还分开了包含 HTML 的任何文件，将它们放到 document_root 中，而将不包含 HTML 的任何文件放到 document_root 外。

　　顶层的模板层一般包含非常少的 PHP — 只是简单的函数调用和偶然的包含。可能一个循环。这些文件通常用一个 HTML 编辑工具来进行编辑。第二层，即模板助手，是定义商务逻辑和布局之间的接口的地方。这一层可能有一些方便的函数（如 start_table()、 show_user_record()）和其它任何可重用的组件，这些可重用组件使得模板制作者的工作更加容易。

　　商务逻辑层完全不包含任何 HTML。这是实施诸如 SQL 查询和任何其它的 PHP 用户空间商务逻辑之类的东西的地方。您可以期望看到一个诸如 get_user_record() 之类的函数在这一层得到实施。这个函数将获取一个 ID，执行相应的 SQL 查询，然后返回包含结果的一个联合数组。然后，该层中的一个函数获取该数组，并为它包装一些 HTML，使它看起来好一点。

　　最后的 C/C++ 层是您安放一个项目所需的任何定制的后端代码的地方。许多人在这一层上没有任何东西，但如果您有一个专用的 C 或 C++ 资料库，您就可以在这里编写一个 PHP 扩展来和资料库接口。有时当一个用用户空间 PHP 编写的商务逻辑函数太慢时，也将使用这一层。

　　招聘和培训 PHP 开发人员

　　PHP 不是一种新的语言。它没有引进任何新的概念。这意味着培训已经了解 C、C++、Perl 或者甚至 Java 中的任意一种语言的编程人员来编写 PHP 代码相当容易。当我找 PHP 开发人员来做一个项目的时候，我倾向于找拥有 C 或 C++ 技能的人，我的想法是招聘经验丰富的编程人员要比招聘必须对 PHP 非常了解的人员容易得多。如果他们能够掌握这些语言，PHP 对他们来说将是小菜一碟。当然，如果他们有两方面的经验，那就更好了。

　　随意部署 PHP

作業に適したツールを使用してください。私は PHP を完全に採用し、あらゆる場所に展開しているいくつかの企業に会いましたが、PHP は、あらゆる問題に対応できる汎用言語になることを意図したものではありませんでした。これは主に Web のフロントエンド スクリプト言語として適しています。 Web サイトのトラフィック量に応じて、大量のバックエンド作業の実行にも使用できます。ただし、場所によっては、最適なパフォーマンスを得るために、コードの一部を C や C++ などの厳密に型指定されたコンパイル言語で記述する必要があります。

PHP はどこへ行くのでしょうか?

よく、PHP はどこへ向かうのかと尋ねられます。 PHP は主に必要に迫られて誕生し、コミュニティのニーズを満たすために進化したオープンソース プロジェクトであるため、これに答えるのは難しい質問です。 PHP5 では、OO 機能と XML との統合が大幅に改善されました。私たちは SQL-Lite と呼ばれる興味深いツールを統合しました。これは、サーバーを必要とせずにファイルに SQL インターフェイスを直接提供します。明らかに、これは実際のデータベースに代わるものではありませんが、それを使用する方が、独自のプレーン テキスト ファイル処理ルーチンを作成するよりもはるかに優れたアプローチであることは確かです。 SQL インターフェイスが提供されるということは、実際のデータベースへの移植 (必要な場合はいつでも) が容易になることを意味します。

PHP5 の変更は重要ではありますが、徐々に行われます。このリリースで PHP の世界をひっくり返すつもりはありません。 PHP4 用に書かれたスクリプトは、基本的に変更を加えることなく PHP5 で動作します。最大の変更点は、PHP5 でのオブジェクトの処理方法が異なることです。 PHP5 で新しいオブジェクトを作成すると、デフォルトでオブジェクトへの参照を取得できるようになり、PHP4 のように参照によってオブジェクトを渡すことを明示的に指定する必要がなく、そのオブジェクトを渡すことができます。 PHP5 では、実際にオブジェクトのコピーを取得したい場合は、それを「クローン」する必要があります。

長期的には、誰かが Parrot エンジンの使用を研究しています。 Parrot は Perl6 バックエンド用のエンジンとして作成されましたが、実際には言語に依存しない汎用スクリプト エンジンです。さまざまなスクリプト言語がすべて単一のバックエンド エンジンに同意し、それが共通の拡張機能とより優れた言語対話の基礎として使用できるようになれば、非常に興味深いでしょう。

他の企業は、JSR 223 を介した Java 接続に取り組んでおり、Java はスクリプト言語の単一の汎用バックエンドになり得ると主張しています。

PHP がどのような将来を迎えるとしても、変わらないことが 1 つあります。私たちは、私たちの多くが中毒になっているように見える複雑さと闘い続けるでしょう。最も複雑なソリューションが適切なソリューションであることはほとんどありません。 Web 問題を解決するための当社の献身的で率直なアプローチは、当初から PHP を際立たせるものであり、周囲の他のソリューションがより大規模かつ複雑になっているように見えたとき、当社は PHP と Web 問題に対する PHP のアプローチを簡素化および最適化する取り組みを行ってきました。