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

大型系统上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同样是一个更好的选择。