PHP是一門有趣的編程語言。語言與利用語言構建的程序通常屬于兩種設計理念。這里我指的不是瀑布式或敏捷之類的軟件開發生命周期，而是軟件管理的基本思想。有人將這些思想稱為“正確的方式”以及“Worse is Better”。

PHP包含一些奇怪的問題，很多人由于這些問題而貶低這門語言，但他們也沒有錯。這門語言有很多問題。有人嘲笑PHP糟糕的設計，還提出了一些正確的觀點，盡管這些觀點是九年前提出的，但它們依然是正確的。然而，開發人員卻可以利用PHP創建結構“正確”的軟件，而且還引入了其他公認好評的實踐。你可能接觸過Laminas和Symfony之類的框架，它們擁有最佳面向對象編程實踐，開發人員可以利用這些框架編寫結構正確的代碼。為什么會這樣？因為PHP是最糟糕的編程語言。

設計軟件

1991年，Richard P. Gabriel發表了一篇題為《Lisp： Good News，Bad News， How to Win Big”》的論文。該論文的論點是，對于軟件的設計和壽命，“Worse is Better”，也就是說越糟越好。他之所以得出這樣的觀點，是因為他意識到程序設計出現了兩種截然不同的流派，他稱之為“MIT/Standford Style”（學院派）和“The Right Way”（正確的方式，又稱新澤西風格，即后來的Worse is Better）。

這兩種理念的目標相似，但對關鍵領域的看法不同。兩種風格都側重于四大關鍵思想領域：簡單性、正確性、一致性和完整性。學院派的風格描述為：

簡單性：設計必須簡單，無論是實現還是接口。接口的簡單性比實現的簡單性更重要。

正確性：所有可觀察方面的設計必須都是正確的。絕對不允許錯誤。

一致性：設計不能出現不一致。為了避免不一致，允許設計稍微削弱簡單性和完整性。一致性與正確性同樣重要。

完整性：設計必須盡可能涵蓋重要情況。必須涵蓋所有合理預期的情況。不允許簡單性過度降低完整性。

至于新澤西風格，Gabriel認為的目標是：

簡單性：設計必須簡單，無論是實現還是接口。實現的簡單性比接口的簡單性更重要。簡單性是設計中最重要的考慮因素。

正確性：所有可觀察方面的設計必須都是正確的。但是簡單性比正確性略微重要一點。

一致性：設計不能過于不一致。在某些情況下，為了簡單性，可以犧牲一致性。盡管如此，為了避免引入實現的復雜性或不一致，最好放棄設計中不太常見的情況。

完整性：設計必須盡可能涵蓋重要情況。必須涵蓋所有合理預期的情況。但是為了其他目標，可以犧牲完整性。事實上，一旦危及實現的簡單性，就必須犧牲完整性。如果可以保持簡單性，則可以犧牲一致性來實現完整性，接口的一致性尤其沒有價值。

爭論的關鍵是以LISP和C為例，討論為什么越糟越好。Gabriel 是一名 LISP 程序員，他認為LISP比C更好。LISP 不僅和C一樣快，而且Common LISP花費了數年時間進行設計、開發和標準化。定義語言的規范充分利用了各種不同版本的LISP的優點，而且LISP是最好的現代開發環境之一。

LISP 是正確的方式

LISP代表了軟件開發的“正確方式”。LISP易于交互，你可以通過各種方式與之交互。想通過Fortran調用 LISP？你可以通過Fortran調用LISP并傳入輸入數據，反之亦然。在處理遺留代碼時，你可以奢侈地享受 LISP 的所有現代特性。LISP的規范保證了設計的一致性。

看一看Python之類的現代語言就會發現，規范對于提供多個后端和編譯器提供了很大幫助，所有解釋或編譯代碼的方式都相同。LISP的工具是一流的，1991年的LISP就擁有我們至今仍在享受的各種“福利”，比如逐步調試、數據檢查和精美的編輯器。作為一種語言，LISP是完備的。它具有先進的面向對象編程層、多重繼承、一流的對象以及函數和類型。LISP似乎是開發人員心中所想的編程語言。

1991年是LISP這門編程語言的最佳時期。這種技術上的正確性并不是由實際使用來證實的。LISP的開發正在走下坡路。多年的負面新聞和定位失誤影響了 LISP 的外部聲譽，不再被視為向最終用戶提供軟件的一種方式。在開發方面，LISP提倡的很多思想與“預先做大量的設計”不謀而合。如果你曾使用過諸如瀑布模型之類的設計方法，就能看出一些問題。“正確的方式”非常強調一致性、正確性，并確保考慮到所有可以想到的問題。

LISP本身也不止一種語言，它有一個語言家族。雖然 Common LISP是標準，但 LISP 本身也可用于實現各種基本的功能。Lockless Inc網站上的一篇文章認為，這種分化是LISP最終失敗的決定性原因之一。即使LISP堅持軟件設計的“正確方式”，但這種分化導致代碼維護和可移植性均受到了影響。

C 和 Unix 是錯誤的方式

與此同時，多虧了Unix，C成為了開發軟件的首選語言。C是為Unix設計的，而 Unix是從C設計出來的。C的開發人員采取的設計方式與LISP不同。1972年，C還是一門非常簡單的編程語言。到1991年，C發生了一些變化，但基本原理沒有改變。功能都是根據開發人員的需要和 Unix 的需要添加的。編寫編譯器和程序很容易，因為語言本身非常簡單。雖然你也可以利用C編寫復雜的程序，但與LISP相比，估計C只擁有程序員想要的50%～80%的功能。然而，C的便攜性非常驚人。

與通常用于LISP軟件和環境的硬件相比，C還可以在能力有限的硬件上運行。因此，C能夠在更廣泛的機器上編譯和運行軟件。C 軟件和Unix非常容易運行，Gabriel認為Unix和C會像病毒一樣流傳開來。C的開發始于 Dennis Ritchie 設計和構建Unix時。由于貝爾實驗室不被允許正式進入計算機領域，因此 Unix 很容易分發給其他的各種用戶。這些用戶為了滿足自己的需求給Unix打補丁。

Dennis Ritchie能夠根據需要合并這些補丁，而不必提前想好這些需求。與LISP不同，C至今仍被廣泛使用。雖然PHP、JavaScript和Python等高級語言和解釋性語言是許多開發人員的首選，但許多高級語言都是用C開發的。盡管如今出現了像Rust這樣的競爭對手，但在小型低功率設備上運行仍然是C的優勢。

PHP最糟糕

首先，越糟越好的軟件會被接受；其次，用戶的期望更低；第三，這些軟件可以被改進，直到接近“正確”的程度。—— Richard Gabriel幾年后，Rasmus Lerdorf開始致力于創建個人主頁/表單解釋器（Personal Home Page/Forms Interpreter），即我們現在所說的PHP。PHP/FI的誕生是因為Lerdorf 需要維護他的主頁，并與表單和數據庫進行交互。PHP/FI的設計甚至稱不上編程語言，而是作為C之上的腳本和函數層。

PHP 很簡單

設計必須簡單，無論是實現還是接口。實際上，PHP底部使用了C語言，我們認為這是“最糟糕的”。然而，這帶來了一些優勢，最重要的是，簡單的底層語言更加方便擴展。雖然 Hack/HHVM 采用了更多的C++方法，但PHP本身仍然是C語言。

你可以在短短幾個小時內學習 PHP 語言的內部結構。Elizabeth Smith 曾發表過一個關于 PHP 擴展的精彩演講（https://www.slideshare.net/auroraeosrose），其中介紹了大量關于 PHP 的內部工作原理。PHP借鑒了其他C風格的語言，不僅方便閱讀，而且還可以切換成C風格系列的其他語言。PHP的大部分接口或標準庫都很簡單，因為大部分核心功能只不過是對各種C庫進行了包裝，然后原封不動地公開了。雖然這會導致接口的不一致，但也為C或C++開發人員提供了一個熟悉的環境。

PHP語言主要用于Web開發。你可以很容易地從該語言中找到某個HTTP的概念。想要獲取請求的標頭？可以直接使用get_headers（）。想要獲取請求信息？只需讀取全局變量$_GET 和 $_POST。PHP的接口很簡單，而且內部結構也非常簡單。

PHP（幾乎）是正確的

所有可觀察方面的設計必須都是正確的。簡單性比正確性更好。此處，在簡單性與正確性的選擇中，PHP更傾向于“簡單”。在HHVM出現之前，并沒有任何關于PHP的外觀或功能的規范。Zend解釋器本身就是規范，而且該語言的行為方式始終是“正確的”（不包括實際的 bug）。

如果你想替換掉PHP 引擎，則需要實現該引擎的所有怪癖。許多核心函數的參數和返回類型都不是特別嚴格，主要目的是讓系統更易于使用。例如strpos（）等函數的返回值可以是整數或布爾值，這比嚴格設計的返回整數或拋出異常的方法更容易使用。看看PHP語言的發展，幾乎所有新功能都是以開發人員的需求為基礎，而不是追求“正確”。更多地關注嚴格的類型和異常錯誤是一種更正確的方式。

盡管如此，短箭頭函數、屬性和枚舉之類功能才是開發人員希望簡化對代碼。

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的長盛不衰以及廣泛使用證明了這樣一個事實：“正確的方式”未必比“最糟”更好。如果有人抱怨你使用的框架，也無需在意，從長遠來看這無關緊要。更重要的是，選擇一種舒服的設計理念，并告訴自己“越糟越好”。

責任編輯：haq