2012 年有一篇很火的博客：pHp: a fractal of bad design。作者在文中對 pHp 大張撻伐，幾乎就差說這是反人類的設計了。第一次讀到此文時，我正在一個惡心的地方處理很多遺留的 pHp 項目。讀完文章時，我開始思考是否要辭職去做一些與編程完全不同的事情。

幸運的是，此后不久我就換了工作，而且 pHp 從 5.* 開始也成長了很多。今天，我想對那些不再使用 pHp 編程，或者被遺留項目困擾的人說點什么。

Spoiler：pHp 跟其他編程語言一樣，都有點自己的小毛病。很多核心函數的方法簽名不一致，配置設置仍然不清不楚，仍然有很多開發人員在寫蹩腳的代碼——因為他們必須這樣做，或者說，他們沒有更好的方法。

但今天，我想說的是 pHp 好的一面：看看 pHp 的成長，共同探討一下如何編寫干凈且可維護的 pHp 代碼。希望大家可以暫時把偏見放進肚子里，哪怕只有幾分鐘。等我說完，你可以把它們再拿出來，但是你一定會驚訝于過去幾年里 pHp 的成長。

快速閱讀

• pHp 每年都在積極開發新版本

• 自 pHp 5 時代以來，性能至少翻了一番，甚至有可能是曾經的三倍

• 有極其活躍的框架、包和平臺生態系統

• 過去幾年增加了很多新特性，語言也在不斷發展中

• 像靜態分析器這樣的工具已經成熟，并且會越來越多

更新:有人讓我展示一些代碼示例，這當然可以！下面有兩個例子：一個是我比較喜歡的項目，是用 pHp 和 Laravel 語言編寫的；還有一個是我們辦公室維護的幾百個 OSS 包的列表。代碼地址如下：

• https://github.com/brendt/aggregate.stitcher.io

• https://spatie.be/opensource/packages

那我們開始吧。

歷史背景

首先，我們快速回顧一下 pHp 的發布周期。現在的 pHp 版本是 7.3，預計 2019 年底將發布 7.4，然后下個版本將是 pHp 8.0。

自 5.* 時代之后，其核心團隊努力保持著一年一版本的發布周期，并在過去四年中成功做到了這一點。

一般來說，每一個新版本都有兩年的有效支持期，然后再用一年來做「安全修復」。這么做的目的是鼓勵 pHp 開發人員盡可能使用最新版本，因為每年的小升級比從 5.4 跳到 7.0 版本要容易得多。

pHp 的版本時間表如下：

其中，pHp 5.6 是 5.*時代的最新版本，它的下一個版本就是 7.0。如果您想知道 pHp 6 發生了什么，可以收聽 pHp 圓桌播客 ：

https://www.phproundtable.com/episode/what-happened-to-php-6

了解這些之后，我們可以進一步探討關于 pHp 的常見誤解了。

pHp 性能

5.* 時代的 pHp 性能充其量也不過是平均水平，但是在 7.0 中，pHp 核心的大部分內容都被完全重寫，性能也因此提高了兩到三倍。

光說不練假把式，我們用基準測試結果說話。有人對 pHp 的性能進行過基準測試，這些測試被很好地記錄在了 Kinsta 上：

https://kinsta.com/blog/php-benchmarks/

自從 7.0 出現以后，pHp 的性能一直處于上升期。pHp web 應用的性能與其他語言的 web 框架相當 (在某些情況下甚至更好)。不信可以看看這個通用基準測試包：

https://github.com/thebenchmarker/webframeworks

pHp 框架雖然沒辦法做到比 C 和 Rust 更好，但是它比 Rails 或 Django 要好得多，并且可以與 ExpressJS 相媲美。

框架和生態系統

說到框架，pHp 已經不再只是 Wordpress 了。作為一名專業的 pHp 開發人員，我想說的是：Wordpress 根本不能代表現在的生態系統。

一般有兩個主要的 web 應用程序框架和一些小框架，比如 Symfony 和 Laravel。當然，還有 Zend、Yii、Cake、Code Igniter 等，但是只有這兩種主要的框架才能代表如今的 pHp。

這兩個框架都有一個包含大量包和產品的生態系統。從管理面板和 CRM 到獨立的軟件包、CI、profiler，眾多如 web sockets 服務器、隊列管理器、支付集成這樣的服務...... 可以拿得出手的東西太多了。

不過，這些框架是用于實際開發的。如果你需要純粹的內容管理，像 Wordpress 和 CraftCMS 這樣的平臺只會越來越好。

測試 pHp 生態系統當前狀態的一種方法是查看 packagist，它是 pHp 的主要 package 存儲庫。它呈指數級增長，每天大約有 2500 萬次的下載量。公平地說，pHp 生態系統已經不再是過去的小輸家了。

下面的圖表，列出了包和版本的數量隨時間的變化。

除了應用程序框架和 CMS，近年來異步框架也逐步興起。

這些框架和服務器是用 pHp 或其他語言編寫的，通過這些框架，用戶可以實現真正的異步 pHp。Swoole、Amp 和 ReactpHp 都是很好的例子。

自從我們進入異步世界以來，像 web sockets 和具有大量 IO 的應用程序之類的東西已經與 pHp 世界息息相關。

在內部郵件列表（內核開發人員討論如何開發該語言的地方）上也有關于將 libuv 添加到內核的討論。

語言本身

雖然 async 和 await 功能都還不能用，但是在過去幾年里，pHp 語言本身已經做了很多改進。下面列出了 pHp 的部分新特性：

• Short Closures

• Null coalescing operator

• Trait

• Typed properties

• Spread operator

• JIT compiler

• FFI

• Anonymous classes

• Return type declarations

• Contemporary cryptography

• Generators

除了語言特性，我們也應該看一下語言的發展過程。雖然社區也會提出 RFCs，但一個活躍的核心志愿團隊才是推動語言的發展的根本。

這些 RFCs 會在「內部」郵件列表中進行討論。在添加新的語言特性之前，必須進行投票，獲得至少 2/3 支持的 RFC 才能被寫入內核。

大概有 100 個人有投票權，雖然他們不必對每個 RFC 都進行投票。這些人中必須包括核心團隊的成員，因為他們要維護代碼庫。剩下的投票者主要是從 pHp 社區中挑選出來的，這些人包括 pHp 文檔的維護者、整個 pHp 項目的貢獻者以及 pHp 社區中的杰出開發人員。

雖然大多數核心開發都是在自愿的基礎上完成的，但是作為核心 pHp 開發人員之一，Nikita popov 最近已被 Jetbrains 聘用，成為了全職的 pHp 開發者。另外，Linux 基金會最近也決定投資 Zend framework。這樣的雇傭和收購確保了 pHp 未來發展的穩定性。

工具包

除了程序內核本身，pHp 工具包的數量也在不斷增加。靜態分析器 psalm（由 Vimeo 創建）、phan 和 pHpStan 都是很好的例子。

這些工具可以對 pHp 代碼做靜態分析，并會報告任何類型的錯誤、可能的 bug 等。在某種程度上，它們的功能幾乎可以趕上 TypeScript 了，不過目前這種語言還無法實現源到源編譯，因此不允許使用自定義語法。

盡管這意味著我們需要依賴 docblock，但 pHp 的最初創建者 Rasmus Lerdorf 確實提到了向內核添加靜態分析引擎的想法。這個想法潛力巨大，但這是一項艱巨的任務。

為了像 JavaScript 那樣實現源到源編譯，pHp 開發者們也一直努力在用戶端擴展 pHp 語法。一個名為 pre 的項目就在做這樣的事：將新的 pHp 語法轉換為普通的 pHp 代碼。

雖然 JavaScript 中已經實現了這個想法，但是只有提供合適的 IDE 和靜態分析支持，它才能在 pHp 中工作。這個想法很有意思，但它還需要不斷成長，才有可能成為「主流」。

結語

說了這么多，你仍然可以吐槽說 pHp 是一種蹩腳的語言。雖然它還是有一些缺點和 20 年的遺留問題，但我仍然熱愛這門語言。

以我的經驗來看，我能夠寫出可靠易維護且高質量的軟件。我和客戶對最終的結果也都是滿意的。

雖然使用 pHp 還會有一些亂七八糟的事情，但如果使用得當，我認為它還是一個不錯的網絡開發選擇。

當前文章：網站優化之pHp并發性能性能提升104%調優實戰
URL地址：http://m.newbst.com/news13/294813.html

成都網站建設公司_創新互聯，為您提供外貿建站、微信公眾號、云服務器、網站排名、建站公司、品牌網站設計

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯