background image

在 Web 开发世界里,PHP 是最流行的语言之一,从 PHP 里,你能够很容易的找到你所需的脚本,遗

憾的是,很少人会去用 最佳做法 去写一个 PHP 程序。这里,我们向大家介绍 PHP 的 10 种最佳实践,当然,

每一种都是经过大师们证明而得出的。

1. 在合适的时候使用 PHP – Rasmus Lerdorf

没有谁比 PHP 的创建者 Rasmus Lerdorf 明白 PHP 用在什么地方是更合理的,他于 1995 年发布了 PHP 这

门语言,从那时起,PHP 就像燎原之火,烧遍了整个开发阵营,改变了互联网的世界。可是,Rasmus 并不

是因此而创建 PHP 的。PHP 是为了解决 web 开发者的实际问题而诞生的。

和许多开源项目一样,PHP 变得流行,流行的动机并不能用正常的哲学来进行解释,甚至流行得有些孤芳自

赏。它完全可以作为一个案例,一个解决各种 Web 问题的工具需求所引起的案例,因此当 PHP 刚出现的时

候,这种工具需求全部聚焦到 PHP 的身上。

但是,你不能奢望 PHP 可以解决所有问题。Lerdorf 是第一个承认 PHP 只是一种工具的人,并且 PHP 也有

很多力所不能及的情况。

根据工作的不同来选择合适的工具。我跑了很多家公司,为了说服他们部署和使用 PHP,但是这并不意味着
PHP 对所有问题都适用。它只是可以一个解决大部分问题的 front-end 脚步语言。

作为一个 web 开发者,尝试用 PHP 解决所有问题是不科学的,同时也会浪费你的时间。当 PHP 玩不转的时

候,不要犹豫,试用一下其他的语言吧。

2. 

 – 

使用多表存储提高规模伸缩性

Matt Mullenweg

没有人愿意质疑 Matt Mullenweg 在 PHP 方面的权威性,他开发了这个星球上最流行的 blog 系统,(依靠

一个强大的社区力量支持)  

: WordPress. 创建 Wordpress 以后,Matt 和他的团队启动了

WordPress.com 平台,一个基于 WordPress MU 的免费 blog 站点。现在,Wordpress.com 已经拥有大

约 400

 

 

万用户, 这些用户每天提供超过 140,000

 

篇的日志。 (要查看更多 Wordpress.com 的统计情况,

请点击这里.)

如果有人知道如何让网站的规模伸缩自如,这个人一定是 Matt Mullenweg。2006

 

年的时候 Matt 对

Wordpress 的数据结构进行了前瞻性的改进,并且解释了为什么 Wordpress MU 对每个 blog 使用独立的
MYSQL

 

表格, 而不是把所有的 blog 数据都塞进一个巨大的表格。

我们测试过这个方法,但是发现如果要扩展它的伸缩性,代价太高。如果用一个整体的数据结构,在大流量

面前,你将会面临服务器硬件的问题。在 MU 里面。用户们都被分布到独立的表格当中,并且可以轻易地组

织起来。举个例子,WordPress.com 把用户的数据分散存储到 4096 个数据库中,这些数据库可以分散大

规模的数据访问,实现流量和压力分流。

数据表的可迁移性让代码(blog)可以运行得更快,并且让系统具备更强的伸缩性。依靠强大的缓存策略

 

和灵活的数据库运用策略, Matt 向人们展示了时下最流行的 Facebook 和 Wordpress.com 都可以在
PHP 下稳定运行,并且处理惊人的访问量。

3. 

 – 

千万不要相信用户

Dave Child

Dave Child 是 Added Bytes (previously ilovejackdaniels.com) 网站的核心人物,这个网站

以他出色的《cheat sheets for many programming languages

 

》而闻名。 Dave 为很多英国的公

司服务,并且已经在编程世界里树立起相当的权威。

Dave 为 PHP 开发者提供了很多深谋远虑的建议,并总结成了《writing secure code in PHP》:千万

不要相信你的用户,他们甚至可能会伤害你。

有一条 web 开发的基本原则,我重复多少遍都觉得不够,那就是:千万不要相信你的用户,同时要假设你

网站中的每个数据单元都是从用户那里收集来的恶意代码。很多时候,你必须用 javascript 在客户端检

 

验表单提交过来的内容, 如果你习惯了如此,那么,这是一个好习惯。如果安全性对你来说很重要,这就
是最重要最需要学习的原则。

Dave 目前正致力于为它的《Writing Secure PHP》系列书籍整理实例,书的最后他说:

最后,变得偏执一点吧。除非你认为你的站点永远不会受到攻击,否则就正视所有的问题,当问题真正发生