大型系統上PHP令人不爽的九大原因

我在過去的四年裡一直致力於PHP應用的開發。PHP確實十分容易編寫。但是PHP也有一些十分嚴重的缺陷。

　　下面我會給出我的理由，為什麼PHP不適合於比小型業餘網站更大的網站。

　　1. 對遞迴的不良支援

　　遞迴是一種函數調用自身的機制。這是一種強大的特性可以把某些複雜的東西變得很簡單。有一個使用遞迴的例子是快速排序（quicksort）。不幸的是，PHP並不擅長遞迴。Zeev，一個PHP開發人員，說道：“PHP 4.0（Zend）對密集資料使用了棧方式，而不是使用堆方式。也就是說它能容忍的遞迴函式的數量限制和其他語言比起來明顯少。”見bug 1901。這是一個很不好的借口。每一個程式設計語言都應該提供良好的遞迴支援。

　　2. 許多PHP模組都不是安全執行緒的

　　在幾年前，Apache發布了Web伺服器的2.0版。這個版本支援多線程模式，在這個模式下，軟體一個一部分可以同時運行多個。PHP的發明者說PHP的核心是安全執行緒的，但是非核心模組不一定是。但是十次有九次，你想要在PHP指令碼中使用這種模組，但這又使你的指令碼不能合適Apache的多線程模式。這也是為什麼PHP小組不推薦在Apache 2 的多線程模式下運行PHP。不良的多線程模式支援使PHP常被認為是Apache 2依然不流行的原因之一。

　　請閱讀這篇討論： Slashdot: Sites Rejecting Apache 2?.

　　3. PHP 由於商業原因而不健全

　　通過使用緩衝，PHP的效能可以陡增500%[見基準測試]。那麼為什麼緩衝沒有被構建在PHP中呢？因為Zend——PHP的製造者，它在銷售自己的Zend Accelerator，所以當然，他們不想拋棄自己的商業產品這塊肥肉。

　　但是有另一個可選擇的： APC. （Zend後來推出Zend Optimizer，免費的加速器——譯者）

　　4. 沒有命名空間

　　設想某個人製作了一個PHP模組用來閱讀檔案。模組中一個函數叫做read。然後另一個人的模組可以讀取網頁的，同樣包含一個函數read。然後我們就無法同時使用這兩個模組了，因為PHP不知道你要用哪個函數。 但是有一個很簡單的解決方案，那就是命名空間。曾經有人建議PHP5加入這個特性，但不幸得是他沒有這麼做。現在，沒有命名空間，每個函數都必須加上模組名作為首碼，來避免名稱衝突。這導致了函數名恐怖得長，例如xsl_xsltprocessor_transform_to_xml讓代碼難於書寫和理解。

　　5. 不標準的日期格式字元

　　很多程式員對 日期格式字元 都很熟悉，它是從UNIX和C語言中來的。其他一些程式設計語言採用了這個標準，但是很奇怪的，PHP有它自己的一套完全不相容的日期格式字元。在C中，“%j”表示一年中的當天，在PHP中他表示一個月中的當天。然而使事情更混亂的是：Smarty （一個很流行的PHP模版引擎）的 strftime 函數和 date_format 函數，卻使用了C/UNIX的格式化字元。

　　6. 混亂的許可證

　　你也許認為PHP是免費的，所有的在手冊中提到的PHP模組也是免費的。錯了！例如，如果你想在PHP中產生PDF檔案，你會在手冊中發現兩個模組：PDF 和 ClibPDF。但是這兩個都是有商業許可證的。所以，你所使用的每個模組，你都要確保你同意他的許可證。

　　7. 不一致的函數命名規則

　　有些函數名稱是有多個單片語成的。一般有三種單片語合的習慣：

　　直接拼接：getnumberoffiles
　　用底線分開：get_number_of_files
　　駱駝法則：getNumberOfFiles

　　大部分語言選擇其中一中。但是PHP都用到了。

　　例如，你想要把一些特殊字元轉換成HTML實體，你會使用函數htmlentities （直接拼接單詞）。如果你要使用相反的功能，你要用到它的小弟弟html_entity_decode。由於某些特殊的原因，這個函數名是由底線分隔單詞。怎麼能這樣呢？你知道有一個函數叫strpad。或者他是str_pad？每次你都要查看一下到底這個符號是什麼或者直接等他出現一個錯誤。函數是不分大小寫，所以對於PHP來說rawurldecode 和RawUrlDecode之間沒有什麼區別。這也很糟糕，因為兩個都使用到了同時他們看上去還不一樣，混淆了閱讀者。

　　8. 魔法引用的地獄

　　魔法引用（Magic quote）可以保護PHP指令碼免受SQL注入攻擊。這很好。但是出於某些原因，你可以在php.ini中關閉這個配置。所以你如果要寫出一個有彈性的指令碼，你總要檢查魔法引用是開啟還是關閉。這樣一個“特性”應該讓編程更簡單，而事實上變得更複雜了。

　　9. 缺少標準架構

　　一個成長中的網站沒有一個整體架構，最終會變成維護的噩夢。一個架構可以讓很多工作變得簡單。現在最流行的架構模型時MVC-模型，在其中表現層、商務邏輯和資料庫訪問都分離開了。

　　很多PHP網站不使用MVC-模型。他們甚至沒有一個架構。甚至現在有一些PHP架構同時你都可以自己寫一個，關於PHP的文章和手冊沒有提高架構的一個字。同時JSP-開發人員使用像Struts的架構、ASP開發人員使用.Net，看起來好像這些概念都廣泛被PHP開發人員所瞭解。這就說明了PHP實際上到底是多專業。

　　總結

　　什麼問題?

　　對於非常小的項目，它可以是一個十分符合人意的程式設計語言。但是對於較大的和更為複雜的項目，PHP就顯出他的薄弱了。當你不斷地摸索之後，你會發現我提到的某些問題的解決方案。所以，當解決方案已知之後，為什麼不能修正他呢？另外為什麼這些修補不在手冊中提到呢？ 一個開源的語言十分流行是一件好事。但不幸得是，它不是一個偉大的語言。我希望所有的問題能有一天得到解決（也許在PHP6？），然後我們就將擁有一個開源語言，他既開源，又好用。

　　到現在，當你要啟動一個多於5個指令碼頁面的項目的時候，你最好考慮C#/ASP.Net 或者 Java/JSP或者也許Python同樣是一個更好的選擇。