易栈网-膘叔

作為一名苦逼的程序員，他要做什麼？（這張圖來自互聯網：http://www.kuqin.com/upimg/allimg/120127/2003294U9-1.png）



正因為程序員十分苦逼，所以最近就在研究一些關於薪資的事情，發現果然很多人都是這麼理解的。
看看人家：http://www.iheima.com/html/2012/cyjy_0412/554.html
192萬就實現了N多目標，羨慕嫉妒恨啊。

看到这篇文章的的时候，就因为里面有几句话，所以我不得不转，其实在项目中也会遇到这样的症状，只有大声的提出来，才会被人所接受。
请看：
导读：本文是从《What are your list of must know programming proverbs ?  》这篇文章翻译而来。

内容如下：

继Kevin给了我们10条按他的观点的每个程序员必须知道的编程格言。可以看出，这都是不错的格言，而下面是我自己最喜欢的编程格言。

1.保持简单直白(Keep It Simple Stupid)

2.不要自我复制(Don’t Repeat Yourself)

3.能干的人解决问题。智慧的人绕开问题(A clever person solves a problem. A wise person avoids it)– Einstein

4.沉默会被理解为赞同(Silence is construed as approval)( Picked from Kevin blog )

5.没有火就不会有烟(There is no smoke without fire)

6.先想好，后编程(Think first, Program later)

7.永远不要假设计算机为你假设了任何前提(Never assume the computer assumes anything)
-----------------EOF----------
第四条其实很重要，如果遇到问题不大声提出来，到最后其他人都会认为你了解了或者学会了，但这样反而是影响不了了

原文来自：http://www.phpchina.com/?action-viewnews-itemid-38903，居然忘了贴出来

来自cnbeta的一篇文章：程序员那些悲催的事情。。。
原文地址是：http://www.cnbeta.com/articles/138034.htm
很多人看完都觉得好象是自己经历过的，有可能会都会经历过一样两样，据我一朋友说，他有一次喝多了，然后半夜在维护服务器。执行rm -f ./的时候，少打了一个点。然后，就悲催了啦 。

看看cnbeta上那些悲催的故事吧。。。。
新闻来源:酷壳
在StakeOverflow上有这样一个贴子叫“Confessions of your worst WTF moment”（WTF就是What the fuck的缩写），挺有意思的，我摘几个小故事过来，希望大家在笑过之后能从中学到什么——所有的经验都是从错误中来的（我在其中加了一些点评）

我们公司的软件是给警察局用的，那是一个对用来处理被逮捕的人的系统，此系统还需要收集脸部特征和指纹信息，并且，这个系 统和会向FBI的系统提交这些信息。当我们在测试这个系统的时候，我们一般都是用我们自己的指纹，当然，数据库联着的是我们的测试数据库。不过，有一次， 在我们测试完后，我们忘了把系统切换回生产库，于是我们的测试数据库就联上了生产环境，于是我们的指纹信息和照片就散布到了其它系统中……清除我们警察局 这边的还好办，但是，你需要波士顿警察局警司去法院签字才能从FBI的数据库中清除我们的信息。

点评：测试环境和生产环境的数据不要混在一起。

有一次，我需要向新系统中导入一堆数据，因为数据量太大，需要5个小时，只能在夜里来干，在系统需要正式使用前2个小时， 数据导完了，此时是凌晨4点。随后，我需要删除一些数据，于是我在SQL命令地上输入了“DELETE from important_table; where id=4”。是的，我没有看到哪里还有个分号，天啊。

点评：这就是加班工作的恶果。另，在delete之前最好先做一次select。

我把我的管理员口令提交到了一个开源软件的源码里。

点评：1）版本管理器里的东西是删不掉的。2）一些用户和口令要hard code在代码里，所以，不要混用代码使用的权限和管理员的权限，小心管理程序的运行权限，为其注册专门的用户。

我为一个很大的银行开发软件，在我的代码里，我为一段理论上根本不可能执行到的代码加了一个报错信息。有一天，不可思异的 事发生了，这条报错信息显示在了该银行的1800个分行的超过10000个终端上——“如果你看到这个信息，说明整个系统被Fuck了，回家吧，祝你过得 愉快！”

点评：“假设是恶魔”，Assume意为Ass – u – me，意为——搞砸你和我。对于一些关键东西，永远不要做假设。小心你言语中的——“可能、应该、觉得、不应该”等词语，程序可不认这些东西。

我远程登录到服务器上加几个防火墙规则。第一件我想干的事是在不允许任何人的任何连接，第二件是，为某个端口打开访问权限。不过，我在做完第一件事后就把配置保存了，结果其生效了……

点评：这样的事经常发生，做远程网络管理的人多少会有那么几次发生这样的错误。在你将你的网络配置生效前，你得想一想，断线了你是否还能登得上去。改配置不要太冲动，生效前检查几次。

我们的代码中有一个模块完美地工作了很多年了，只是代码太乱了。我说服了我的老板，我可以重写这个模块，于是我花了三个星 期来重写这个模块。今天 ，我还记得，我的老板站在我的后面看着我，而我在在流着斗大的法汗珠去fix被我重写的“超级漂亮”的那个模块中一个接一个的bug。从那以后，我再也不 重写代码了，除非有重大的利益。

点评：这就所谓的屠宰式编程。这个案例告诉我们两个道理，1）维护代码要用最最最保守的方法来进行。2）重构代码前要像一个商人一样学会计算利益。当然，ThoughtWorks的咨询师一定会告诉你TDD，结对，极限等等方法告诉你如果实践重构。但我想告诉你，一个程序在生产环境里运行好几个年能没有问题是一件很不容易的事，那怕其中的代码再烂，你再看不过去，你都要有一个清醒的头脑明白这几点，1）软件的运行质量是远远大于代码质量的，2）你的测试案例是远远小于生产环境的，3）软件的完美的质量，是靠长时间的运行、测试和错误堆出来的，而不是某种方法论。

相信大家做程序员这一生中也有很多发生在自己身上的悲催的事儿，欢迎分享。我先分享几个我亲身经历过的事。

一个发生在我的领导身上。

我98年刚参加工作的时候，在某单位网络部门，一次，我们整个部门去给下属单位培训Cisco路由器，结果我们发现带去培 训地点的设备少带了集线器HUB，设备连不起来。于是领导很不高兴，质问我们为什么没有带集线器？那几个对领导平时就不满的老员工说办公室里没有集线器 了，都借给别的部门了。领导想了想，问我：“陈皓，我记得上次我给过你个集线器”，我说，“好像没有吧，我记不起来了，什么牌的？几口的？”，领导说： “什么牌子想不起来了，不过我记得那个集线器是一个口的”。“一个口的？！”，我心里嘀咕着，“真敢说啊”。但我不敢接话了。那几个老员工来劲了——“哪有一个口的HUB啊，一个口的怎么联两台电脑啊？”，领导说：“用两个一个口的不就行了”。领导这话一出，全场一片寂静，无言以对……

后来：我们所有的组员都离开了我们的这个领导，我们的这个领导今天还在那里工作。我想告诉大家，很多时候该走的是领导（包括外企，我上一东家正在裁人，不过我觉得该被裁掉的应该是那些经理）。我们的领导经常出这样或那样的笑话，这让我随时随地地警醒自己——“不要当一个被人笑话的经理”，于是，今天我还在努力地学习技术。

另一个发生在我身上

刚刚接触Linux的时候，还不是很懂，那时的PC还只有奔3，编译公司的程序好慢啊，有时候为了调查一个问题，需要不断 地打log，来来回回地编译，很不爽。直到有一天，硬盘不够了，df一下，发现/dev/shm还有空间。于是，把全部程序copy了过去，发现编译起程 序超快无比，爽得不行。于是就把工作环境放在/dev/shm下了，连开发都放在这里了。这一天，开发一个功能，改了十来个文件，加班很晚，觉得基本搞 定，大喜，回家睡觉。第二天一来，发现/dev/shm下空了，一个文件都没有了，问同事，同事不知，同事还安慰我说，上次他的文件也不知道被 谁删了，于是我大怒，告老板！老板也怒，发邮件到整个公司质问大家谁删了陈皓的程序，无人应答。IT部门答，“昨晚唯一的操作就是重启了linux服务 器，什么也没干，不过我们天天备份服务器，可以恢复”，IT部门问我丢的文件在哪个目录下？于是，我reply to all – “在/dev/shm下……”，哎，人丢大发了……

后来：我很感谢我以前犯的这个错，从那天以后，我开始立志学好Linux，这个错误让我努力，让我发奋。所以，我想告诉大家——尤其是刚出道的程序员，你们要多多犯错，要犯错那种丢死人的错，这样你才会知耻而勇。

再来一个发生在我同事身上的

01年，我们开发银行系统，在AIX上开发，RICS6000很贵，只能在客户那里开发，开发进度很紧张，慢慢地硬盘就不 够用了，系统中有大量的垃圾文件，于是需要清除一些文件，于是有一个同事写了一个脚本，可以自动清除的各种不重要的文件，里面有一条命令大致是这个样子“ rm -rf ${app_log_dir}/*”，意为清除程序运行的日志。为了使用这个脚本，需要在root用户下运行，一开始还不错。直到有一天，某人一运行，整 个根就没了。搞得整个团队只能用一周前的备份重写已写好的代码。后来，才发现原因是${app_log_dir}变量为空，于是成了“rm -rf /*”……

后来：这个事后，我的那个同事，把rm命令改了名，并自己写了一个rm命令，把删除的文件先放到一个临时目录下。而我也因为这个事情，到今天，每次当我在root目录下使用rm时，敲击回车的手都是抖的。（另，rm时永远使用绝对路径）这里，我想告诉大家——犯错不可怕，可怕的是不会从中总结教训，同一个错犯两次。

--EOF--

嗯 ，最后一个故事和我那个朋友的事情很像。。。确实，还是用绝对路径安全。千万不要用相对路径。。太不放心了。哈哈。

这是javaeye上的一篇访谈翻译（摘自程序员杂志），里面有一段关于PHP的安全性的话有点意思，用该页面下面的评论来说，搞的就象几个中国哥们在聊天一样。

我是觉得他们就象在一个group里的聊天记录。啥时候我也把QQ群或者MSN群里的聊天记录整理一下，也来个啥啥啥访谈。。。

原文地址：http://www.javaeye.com/news/4143-masters-listening-to-talk-4-php-founder-rasmus-lerdorf-interview-2

原文如下：

《程序员》杂志上连载的《ＰＨＰ创始人访谈录》 的第二部分。


Chris DiBona ： PHP 这个名字代表什么？

Rasmus Lerdorf ：　PHP是 ， 恩 。 Hypertext Preprocessor ， 这名字很蠢， 就是 PHP。  Zee v 与 Andi 是97年中加入进来的， 他们当时使用 php/fi， 在用到深度嵌套中碰到了一些问题， 他们都是计算机专业的， 知道如何写解析器 ， 不像我是通过 hack 状态机这种方式来实现的 ， 我想他们看到我程序的时候，一定对它竟然能工作感到惊奇吧 。

Chris DiBona ： 呵呵，竟然可以工作

Rasmus Lerdorf ： 他们是自愿做这些工作的， 当时我有点太累了，感觉自己像是在给半个因特网写程序， 人们不是给我发补丁来修补程序，而是。。。

Leo Laporte： 这是我的程序， 把 bug 给改了吧。

Rasmus Lerdorf ： 是的 ， 改了这个 Bug,  给我写个程序做这个。 我跟他们说做实现这个很容易，只要这么做， 他们说：“ 好吧，这是最麻烦的， 那剩下那些bug呢”

Chris DiBona ：赶紧把 bug 修复了吧

Rasmus Lerdorf : 我当时的确很郁闷， 简直要把我掏空了。 当时感觉要么我就快要死了，否则我得把它移交到一个更大的 team 来做 。

Leo Laporte： 等等， 在我们继续谈论前，我觉得这是一个很有趣的话题， 这在开源社区并非罕见的情况吧。这种事情常常发生， 人们在说：“我管理不了这个社区了，我不干了，我简直要疯掉了”， chris 你肯定经历过很多这种情形， 这对于开源社区是不是个问题啊。

Chris DiBona ： 是的，实际上我跟Rasmus探讨过这个问题， 每隔五个月，就有人公开在社区挑起这种事端， “天哪，开源项目完蛋了， 有人离开社区了”。 你知道的， 其实有人进入，有人离开这是很正常的。

Leo Laporte：事实上这事最近发生在 Zend Framework 社区了

Chris DiBona ：是啊，让我们来谈谈吧，Rasmus

Rasmus Lerdorf : Zend Framework 是一个分离的项目，实话说，我也不是很清楚 ，你得问问他们，我也不清楚原因。

Chris DiBona ： 从某一方面来说，实际上对大多数社区而言，某些人悄悄地离开了这也没有什么，尽管我不愿意这么说。

Leo Laporte： 对于用户而言，我们有时候的确不太满意所用的产品。

Rasmus Lerdorf ：直到 php 3 ，实际上只有我一个人在做，当某人给我发了个 php 的补丁，我一定会重新写一遍，因为这是我的产品

Leo Laporte： 看来你不擅长移交工作。

Rasmus Lerdorf ：我也不清楚开源的理论，当时也没什么开源的东西，我自己也是后来才想清楚了这些。没过多久，我在多伦多大学找了份工作， 建立一个对话访问系统。我想那大概是 97 年吧，哦，是 96年，偶尔我还能收到一些关于 php 的补丁，有些 bug 是我从来没碰到过的， 我碰到些困难， 有个在日本的程序员给我发了一些补丁，非常酷， 还有有一些在日本的朋友帮我做了咨询方面的工作，但是这并不是经常性的。 一年之后我想通了 ， 我的确需要鼓励这种贡献，人们提交了 patch， 我不能接管然后自己再重写， 我应该接收它， 放弃控制。给他人以权力随心所欲的做自己想做的事情。对于大多数开源的开发者来说，这很难，即便在现在，开源项目是他们孩子， 他们应该控制它，但是对于长期发展来说， 你应该放手， 让其他贡献者做他们要做的事情 ， 你不能做太多限制。

Leo Laporte： 看来，我们作为用户应该更激进一些，呵呵

Rasmus Lerdorf ： 这没关系， 你应该意识到这点，这些人大部分也都是在家里做开源开发的，百分之九十的开源开发者不管他们是做什么。他们把孩子哄上床，为开源项目贡献出两个小时，然后 他们打开自己的邮件，发现一大堆愤怒的信息，全都是"这里有 Bug, 另外这里还有 Bug， 这个 bug 使得我们上百万的电子商务操作无法进行" ， 但他们只能说：“好吧，我已经在晚上贡献了2个小时， 这确实不是我应该太过在乎的事情（你的上百万电子商务程序）"。 所以说，人们对这些开源项目的开发者应该给予一些尊重。

Leo Laporte： 开源是如此繁荣，我想说你们这些人才是开源社区的源动力，我们所能做的就是给予你们以应得的尊重。

Chris DiBona ： 恩， 我发现 Rasmus 的车子有点脏了,呵呵

Leo Laporte： 呵呵,我愿意为他擦洗车子，我欠他的太多了，我在服务器上运行了那么的 php 程序 ，从日志跟踪程序到 drupal .

Rasmus Lerdorf : 你不欠我什么，不欠我任何东西，我们 php 项目现在有 1100个开发人员。

Chris DiBona ： 看来你现在已经把移交工作做的很好了

--------------------------------------------------------------------------------------------

Leo Laporte：  1100 个开发者可不是个小数目啊。

Rasmus Lerdorf ：是的, 如果你修复了 PHP 项目的一个bug, 发来一个不错的补丁, 那么PHP 社区就非常欢迎你的到来。

Leo Laporte：  我知道Perl 社区老早就说起开发 Perl 6 了, 不知道 PHP 6 的号角是否已经吹响.

Rasmus Lerdorf ：我们不太善于做市场方面的工作, 但是 PHP 6 工作的确正在进行了.

Leo Laporte：  跟我们讲点这方面的事情吧

Rasmus Lerdorf ：PHP 6 最大的一部分改进在于对 Unicode 的支持. PHP 6 任何一部分代码都是基于 utf16 编码的.

Leo Laporte：  这大概是 PHP 6 大部分被重写的地方之一吧.

Rasmus Lerdorf ：是的, Unicode 很艰深, 我跟 200 多名懂得 unicode 的开发者开过一个会, 其中包括一些日本的开发人员,他们工作于 IBM 公司, 知道很多 ICU 项目的东西. ICU 是 IBM 的 Unicode 项目, 当时 ICU 项目并不是很好, 它太大了. 它的代码比 PHP 的源码还大, 差不多有10倍了吧.

Leo Laporte：  等等, 你说什么, ICU 项目的代码量是 PHP 的10倍

Rasmus Lerdorf ：它太庞大了, 太让人吃惊了, 而且它不是模块化的, 这意味着你无法从中取出你所需要的部分. 但是现在 ICU 也发展了, 我们可以取出我们需要的部分, 所以如今在 PHP 项目中加入 ICU 支持是可行的, 这使得 PHP 可以在任何地方完全支持 Unicode , 这是 Php 6 最大的改动, 此外的改进还有“命名空间”等其它特点.

Chris DiBona ：那其它的库是否也要因此重写以支持 unicode 呢?

Rasmus Lerdorf ：你说的是库和扩展吧, 有一些函数是要重写的, 基本上涉及到传递字符串或者操作字符串的函数都需要重新审核一下, 是的,这是很大的工作量. 大概在年底会有一个alpha 的测试版发行, 这个版本只是说: 大家看看,测试一下, 看看你现有的代码中有多少因为采用这个版本而无法运行, 估计大多数 Php 5 的代码都不会有什么问题, 我们并不担心, 或许你马上就可以利用它实现一些 unicode 的有趣功能. 如果你正确使用它, 熟悉这个版本的过程中就不会有太多的麻烦, 不过也有可能出现一些我们没考虑到的问题, 所以我们希望尽早发布测试, 而不是像某些语言一下等上5年.

Leo Laporte：  我在自己的服务器上运行的是 php4, 顺便说一句, 非常感谢你们的工作, 开发了这么好的产品. 像很多人一样, 我使用的是 Php 4

Rasmus Lerdorf ：恩, 它的确工作的很好, 如果你没什么必要的话, 也可以不升级...

Chris DiBona ：火是很可怕的( 注解: 5(five) 和 fire 英文发音相同)

Leo Laporte：  哈哈, 是的, 我并不怕火, 呵呵, 我只是不想换版本, 因为它现在工作良好, 是吧?

Rasmus Lerdorf ：是不应该害怕升级的, 直到我们认为完全可以抛弃这个版本之前, 我们将继续提供 php 4 的安全补丁. 对于大多数产品来说, 在 php 4 上良好运行的程序都应该在 php5 上运行. 最困难的是那些大型的 ISP, 它们有成百的用户, 上千个运行的 PHP 程序, 其中若是有几个程序无法运行, 这对他们来说,的确很可怕, 如果没人抱怨升级的问题, 的确没这个必要冒险去升级版本. 但是 PHP 5 的确有一些很吸引人的功能, 比如简单 XML 处理支持, Soap 扩展, 相当快的 Soap 处理, 如果你程序中要处理 Web 服务, 需要解析大量 XML  那么用 PHP 4 来处理就相当痛苦了, 这是我们分支出 PHP 5 版本的主要关注点.

Leo Laporte：  好吧, 为了支持 PHP 5 我要去重新编译我的 Apache 了, 你们两个继续谈.

Chris DiBona ：好啊, 待会见.

Leo Laporte：  Twit.tv 服务器宕机了, 我一会再来.

Chris DiBona ：你可以给 Rasmus 写邮件.

Leo Laporte：  你能给我写代码吗?  Rasmus

Chris DiBona ：奇怪， Drupal 好像运行 Php 5 没什么问题?

Leo Laporte：  我也不知道为什么我要运行 php4, 好像Drupal 最新版本 5.1.4 重新编译支持 php5 , 如果没有什么特别的原因, 是否应该将程序运行从 PHP 4 转到 PHP 5 呢?

Rasmus Lerdorf ：恩 ...

Chris DiBona ：会运行更快一些吗?

Rasmus Lerdorf ：也许不会那么快吧, 有一些程序会运行的很快, 有一些程序的运行速度和原来差不多, 这取决于你的代码做什么, 如果你的代码恰巧使用了我们做大量工作优化的部分, 那么速度就会很快, 否则就和原来速度差不多.

Leo Laporte：  让我们来谈谈人们常常说的 PHP 的一些问题吧, 有一些人经常抱怨 PHP 的性能问题, 我从来没碰到这些困扰, PHP 的扩展性很好.

Rasmus Lerdorf ：你混淆了两个概念, 性能和扩展性没有什么联系。

Leo Laporte：  是吗? 让我们来谈谈这个.

Rasmus Lerdorf ：是的, 性能是单一服务器对单一请求的服务有多快; 而扩展性是指你能扩展的宽度, 比如, 如果你有10万个并发访问, 你如何能将它控制在一定的响应时间之下.

Leo Laporte：  我想两者都很重要,但是扩展性更重要一些

Rasmus Lerdorf ：是的, 但是从某方面说, 性能也很重要, 你可以更换一个更快的CPU, 但是无法并排放大量的服务器, 如果单一请求的响应延迟是半秒钟, 那么并排放500个服务器, 除非你有大量的访问请求, 否则每个请求的响应时间还是半秒钟. 性能问题跟响应延迟有关, 你可以在单一服务器上服务于更多的请求, 扩展性则更多与架构有关, 你要确定你所做的不要和某个服务器紧密绑定, 我们在 PHP 中做的很多事情都有这么一个概念叫做"share nothing"的架构(不共享任何东西), 就像一个 "PHP 黑箱", 你接受一个php 请求, 然后处理该请求, 任何关于这个请求的东西都在这个请求结束后消失, 没有什么东西可以跨越请求存在的, 你要建立一个这样的系统, 每个请求都是相互独立存在的, 因为每个请求可能来自不同的服务器, 你可能在一个负载均衡程序的后面放了 500 个服务器, 那么程序也能将照常运行. PHP 的 Session 机制默认是保存在本地的 tmp 目录中的, 但是我们提供了一个很简单的机制将 session 保存在数据库中, 所以我们在 php 中做的任何事情都保证它是可扩展的, 这也是为什么yahoo 和 flick 的程序员采用 php 的原因. 因为扩展性是内建在 php 之中的. 有人说 php 是不可扩展的, 是因为他们不了解如何去实现扩展性. 就我而言, 我们没有碰到任何扩展性的问题, 所以你可能看不到我们关于扩展性方面讨论的文章. 但你不能说, PHP 不可扩展仅仅因为我们没有讨论它的可扩展性问题

Leo Laporte：  哈哈

Rasmus Lerdorf ：有时候这真让人头疼. 恩, 关于性能的问题, 你能做的事情不多, PHP 像大多数脚本语言一样, 分为两步访问. 首先是将磁盘上的文本编译为 op-code  , 然后将  op-code  传递给执行程序, 这有点像 Java 的字节码. 我们可以把  op-code  放到缓存中, 比如我们已经用了多年的 APC , 还有其它一些产品. 它们将编译好的  op-code  放到共享内存中, 如果第二次请求 php 脚本的时候, 我们将看到, 嗨, 检查一下共享内存,  这是 inode , 我们的共享内存中是否有这个缓存过这个 inode 块, 如果有的话, 我们可以直接执行共享内存的  op-code , 这将会使得代码提速达30至40 倍之多.

Leo Laporte：  这有点类似 python 的 pyc 字节码, 只是你没有在磁盘上保存编译的版本

Rasmus Lerdorf ：是的, 因为性能最慢的地方就是读取磁盘.

Leo Laporte：  这并不能节省多少时间, 是吧?

Rasmus Lerdorf ：是节省不了多少,   op-code 本身就是很小的文件, 500 字节和1000 字节在文件系统中可能都是占用一个块, 你从大小上节省不了什么. 相反你应该避免这种磁盘操作, 任何这类操作都是挺耗费时间的. 不经过任何拷贝操作, 直接从共享内存中执行代码是最快的. 如果我们修改了磁盘上的代码, 我们需要告诉 APC , 可能需要重新启动 web 服务器.

Leo Laporte：  这么说系统需要足够的内存以运行程序了

Rasmus Lerdorf ：所有高性能的网站都会用到缓存的

Leo Laporte：  这么说我们将为运行 PHP 投入更多的内存了.

Chris DiBona ：那么 Zend 提供了些什么, 更好的解析器? 他们确实在销售一些性能优化的产品.

Leo Laporte：  他们也有一些缓存的产品吧

Rasmus Lerdorf ：一样的, 他们本身也没有  op-code   缓存, 他们也提供这方面的缓存产品， 你可以选择.

Leo Laporte：  你有自己喜欢的缓存产品吗?

Rasmus Lerdorf ：我比较喜欢的是 APC , 不是我创建的它, 别人创建的, 我只是帮着他们让其良好运行. 我需要一个缓存得以开始这方面的工作.

Leo Laporte：  习惯上, 如果你运行一个访问量比较大的网站, 通常都会要用到一个缓存系统.

Rasmus Lerdorf ：是的,你应该有一个, 你可以从 Zend 公司购买, 或者试一试开源的缓存系统.

Chris DiBona ：APC  是什么意思?

Rasmus Lerdorf ：Alternative PHP　Cache,  PHP 是开源语言, 所以我们需要一个开源的缓存系统, APC 运行的很好.

Leo Laporte：  不错, 我要在我的服务器上实验一下. 谈谈 PHP 的安全性吧, 你对安全性考虑的有多少?

Rasmus Lerdorf ：这么多年有很多讨论 PHP 安全性的问题, 我觉得有一些是正常的, 大多数批评对 PHP 是很不公平.

Leo Laporte：  有很多不好的实现

Rasmus Lerdorf ：的确有很多很烂的代码, 我们无法把他们都修复了, 有一些错误的确是我们的问题, 我们的程序确实有 bug , 我们会尽量正确地修复它. 但是还有很多是我们无论如何都无法解决的. PHP 比别的语言跟容易出现这种问题, 因为它比其它语言更容易学习, 也就是说越是缺少编程经验的人越容易采用 PHP , 有一些代码的确写的不那么安全, 结构也不好. 而且 PHP 项目的命名也是个问题, 人们总喜欢用 PHP 来命名自己的项目.

Leo Laporte：  是啊, 宝贝, 这可是用PHP写的. 不用其它名字来命名项目了.

Rasmus Lerdorf ：呵呵, 我也不知道为什么我们会有这个问题,  别人就不会起 Python Mailman  这样的名字. 其它语言开发的项目不会起名为 Perl XXX, Python XXX, Ruby XXX , 当然 Ruby on rails 是个例外. 你看, 这么多项目都以 PHP 命名, 他们似乎都想打上 PHP 的标签.

Leo Laporte：  Php Myadmin 也是其中之一, 有很多这种方式命名的项目

Rasmus Lerdorf ：任何一个关于这些项目的 bug 都会归到 PHP 头上, 如果 Mailman 出现了安全性的问题, 你的第一反应不是 Python 出了什么安全性问题, 至少通过名字关联不会这么想, 你最多只是说:"Mailman 这程序太蠢了", 如果 PHP 的项目出了问题, 他们就会说:"PHP 又出问题了, 这个语言的确不安全, 看看这些问题吧"

Leo Laporte： 你有什么类似 perl 的一些措施限制程序员去做正确的编程吗？

Rasmus Lerdorf ： 我们有很多级别的错误报告机制， 你可以打开开关，如果你访问一些未赋值的变量， 就会出现警告等等。

Leo Laporte： 你在 yahoo 工作

Rasmus Lerdorf ：  是的

Leo Laporte： 它们用了很多 php 代码,  你可以说说他们都是在什么地方采用 php 开发的。

Rasmus Lerdorf ：  几乎所有 yahoo 网站都采用了吧

Leo Laporte： 是吗？ 这倒是可以作为 php 扩展性的一个好的典范， 任何人说 php 扩展性不好的，都可以去看看 yahoo . yahoo 的邮件系统也是用 php 写的吧

Rasmus Lerdorf ： 老版本的邮件系统不是基于 php 的。

Leo Laporte： apple 的网站是基于 php 的吗？

Rasmus Lerdorf ： 说实在的，我也不知道。

Leo Laporte：它们大部分都是基于 javascript

Rasmus Lerdorf ：  apple 的网站很多都是基于客户端的技术，我不知道它们有什么地方用到了服务端的技术， 客户端也不是我所关注的技术。

Leo Laporte：我非常喜欢 Yahoo 的邮件系统， 它可是 ajax 技术运用的一个良好示范啊。太感谢你了，Rasmus，给我们提供了这么好的语言， 可以做许多强大的事情。

Chris DiBona ：非常方便

Leo Laporte： 1100 名开发人员， php 社区可真是强大啊， 真让人惊奇。

Chris DiBona ： Pretty Handy Processor （Chris 开玩笑解释 PHP 命名)

Leo Laporte： 哈哈，你又来了， 不过这个解释我喜欢

Rasmus Lerdorf ： 大概是人们讨厌 Perl 吧。

Leo Laporte： 哈哈， 这个理由我接受。

Rasmus Lerdorf ： 对不起，对不起，Larry ( Larry 是 Perl 语言的创始人）

Leo Laporte： 我们确实想采访一下 Larry 。

《程序员》杂志的一位作者袁泳先 生，曾经说过高德纳是一位文艺复兴时期式的天才人物，这说的是他的博学，以及他同时具备的灵巧的编程能力。在分工越来越细致的现代社会，这确实非常罕见， 就像一个人自己制造一架飞机，他既要考虑空气动力学问题，也要考虑飞机上的每棵螺丝钉的固定方式。也确实使我们想到达芬奇，后者创造了享誉后世的《蒙娜丽 莎》，《计算机编程艺术》在计算机领域的影响可以与之媲美，同时也是机器设计方面的专家。从计算机科学史上说，高德纳正是生逢其时。1936年，图灵发表了《论可计算数及其在判定问题上的应用》一文，确立了可计算模型。1953年，巴克斯发明了Fortran语言。从1960年 代起，高德纳以他的博识与耐心开始了《计算机编程艺术》的写作，该书旨在对计算机科学理论的数学背景与历史，做一梳理和总结。现在大学计算机系的《数据结 构》课程的内容基本来自该书。有人更是把它与牛顿的《自然哲学和数学原理》并列，选为对世界历史发生影响的十大科学著作，这不无理由。高德纳本人在36岁时，获得了计算机科学的最高荣誉---图灵奖。从1993年起，他主要专心致力于完成七卷本的《计算机编程艺术》一书。几个星期以前，我们采访了他。使我们特感幸运与欣悦的是，高德纳先 生对我们的采访表现出极大的热诚，在繁忙工作中抽出宝贵时间，细致地回答了我们的问题，并在通信中特别强调希望用他的中文名字。从这里，不难看出他对中国 和中国文化的热爱。这在采访的本文中也有所体现。当我们谈到最早的算法时，他特别提到《九章算术》，这本即使中国人也很少读过的书。或者我们可以将此看作 一种激励，正如高德纳在采访中所说，计算机科学的思想来自世界各个地域、各种文明。可以期待，今天的中国也会产生如刘徽、秦九韶那样的数学高手，对计算机 科学与技术做出独特的贡献。以下是采访的本文:

本刊记者：什么是最早的算法？

高德纳：我想，第一个“真正的”算法可以追溯到大约4000年前，它们以楔型文字记载在粘土板上。我在文章“史前巴比伦算法”中对此有过讨论（我将其翻译为现代注记方式），这篇文章也重印为我的书《计算机科学论文精选》的第十一章。

当然，这些早期的算法并不是很精巧。它们解释了如何以计算的方式解决这些问题，但后来发现使用代数方法能更好地解决它们。最早的“有意义的”算法,它对于今天的程序员们仍然很重要,是最大公约数的求解。其中一个算法被称为欧几里德算法，它被记载于欧几里德几何原本上,尽管它来自于欧多克索斯和其它一些更早期的人物。这种算法基于辗转相除法。另一个算法仅需要除以二，因此非常适合当前的二进制计算机。这个算法可能发源于2000年前的中国——这要取决于我们如何理解经典的《九章算术》中一些句子的隐藏的含义（我在我的书《半数值算法》的340到341页和中文版的309页讨论了这个问题）。

本刊记者：奥运会今年夏天在中国举行，这是对于中国来说是一件很重要的事情，因为它有一些特殊的含义，也许是一个符号，表示中国人能像接受希腊火炬一样接受西方文化。希腊先哲毕达哥拉斯说过“我喜欢作为奥运会的观众胜过成为一个运动员或商人”。现在很多中国人也成为了奥运会观众，我来问个问题：为什么希腊人发现的数学对于人类文明（包括计算机科学）如此重要？

高德纳： 希腊数学家发明的最伟大的东西是严格证明的概念。这个概念将数学与其它知识区别开来，其它知识往往是基于事实的累计、由老师传授给学生的并由社会共识所评 估（举个例子，物理中，并不知道一个假设的真假，而只能等着所谓专家们的想法越来越趋于统一。但是在数学中，很多事情都是无可辩驳的，或者说不存在不同的 观点），纵观人类历史，那些没有遵从希腊方式理解数学的文明把数学认为是应该记忆的规则而不是可以由逻辑推演而来的事实。在这些文明（例如古代中国、日 本、印度和哥伦布发现之前的美洲等）中，人们发现了很多重要的数学原理但是也犯了很多错误，因为学生否决老师是不明智的！这也是为什么我如此感激史前的希 腊数学家教会其他人如何真正的证明问题。

另一方面，我希望澄清一点，我相信所有文明之间都是相互学习的。我为计算机科学这个全世界成千上万的人的共同成果而庆祝，每个人都为此贡献了他们从经验中而来的重要观点。

本刊记者：如何看待数学和计算机科学之间的关系，特别是数学和算法学习之间的关系？

高德纳：你可以参照我对第二个问题的回答，我认为数学对于程序员最重要的意义在于它告诉我们如何证明我们的程序将会在所有情况下正常工作。若非如此，我们就得为此担心，尽管我们的程序通过了已有的所有测试，但或许明天它在处理另外一些新数据时就会出错。

当然，仅仅知道程序能正常工作这一点并不够。有了数学，我们可以证明一个程序比另一个程序快成千上万倍。某些时候，我们甚至能证明程序是“最好的”（best possible）——根据某些标准，没有其它程序会比它好。

本刊记者：这个问题是关于您的书《计算机编程艺术（The Art of Computer Programming）》，写这本书的主要目的是什么呢？您是否试图构建一个算法体系？您是如何选择主题呢？

高德纳：我写《计算机编程艺术》的主要目地是组织和理解一些广泛被各种程序使用的最基础的想法。只要可能，我使用数学给出对于每种基础的方法的对于精 确效率的计量的理解。此外，我尽量叙述每一种方法的历史，因为理解这些方法是如何被发现的有助于我们在现时和今后发明新的方法。

但是，书的主题是1962年 选定的，这时计算机科学还没发展到一个作者无法掌握的规模。因此，没有像操作系统、并行处理、分布式处理之类的资料。此外，我更多地使用整数而不是浮点 数。我把高级数学主题，例如数值分析、计算几何留给别人讨论。我关注的是程序员与机器间的低层次接口，为支持高级应用程序而用于构建库和工具的基础的子程 序。然而，尽管将主题列表做了如此多限制，我这个关于计算科学的一小部分仍旧是一个如此巨大的主题，我需要为剩下的内容工作20年！所以，我希望一直保持健康。

本刊记者：我的很多朋友都尝试过阅读《计算机编程艺术》，但是他们发现这非常困难。我听说一个小说家——詹姆斯乔伊斯（James Joyce），《尤利西斯》（Ulysses）的作者——有人为他的小说写了本书，名字叫《乔伊斯小说指导》，我不知道有没有针对《计算机编程艺术》的类似书籍，比如 《计算机编程导论阅读指导》。您能给《计算机编程艺术》的读者一些建议吗？

高德纳：《计算机编程艺术》不是为所有人写的。大约每50个人中就有一个能发展出独特的看问题的方式，这使他们成为真正的程序员。像你我这样的人，倾向于将知识用特殊的形式在脑中组织以便于更好地利用电脑。每50人中的另外49人不该从事编程这一行，尽管他们可以使用计算机完成一些不需要编程的任务。

对程序员来说，拥有非程序员的朋友是非常重要的，所以对于你所说的你有朋友阅读《计算机编程艺术》非常困难，我并不觉得奇怪。当然，你的朋友也许不应该阅读你看过的所有书籍，你也不应期待能轻易看懂他们的书籍！最好的方法是团队合作，用天分和技巧作为补充。

本刊记者：您认为对最近一些年来说，计算机科学最需要解决的问题是什么?

高德纳：我在所有地方都看到很大的发展的潜能。所以，从这些同样精彩的候选者中我无法选择。机器人、加密、制图（mapping）、动态规划、大量文本或大量DNA序列的搜索等等，都亟待提高。

总 的来说，我认为我期待的主要进步来自于程序员和非程序员的合作。比如，人类能更好地理解动作。我相信很多针对医生、化学家、物理学家、生物学家等的将数据 以动画形式表现出来的工具应该被开发出来。要实现它们，需要优秀的程序员实现动画，与能够理解人类视觉能力的优秀的图形设计师一起工作，与知道哪些数据需 要被理解的优秀的医生、化学家、物理学家和生物学家一起工作。

本刊记者：我听说狄克斯特拉（Edsger W. Dijkstra）曾经试图解决这样的问题：什么是正确的程序？所谓的形式证明？现在在软件工业中，我们主要依靠测试而编写正确的程序。有没有可能在理论上找到一种方法让我们知道程序是否正确，尤其是对大规模的程序？

高德纳：在我回答第二个问题的时候，我提到使用数学去证明（不是重复地测试直到你找不到错误）的重要性。狄克斯特拉和其他人都发展了验证正确性方法，这些方法可以放大,以验证“大”程序。但是，如你指出的，软件工业界并没有真正遵从他们的建议。部分的问题在于——“大”的含义一直在变：当我们有一个可以工作的大程序，人们常常就想写一个更大的，这也就更加难以验证。验证技术从没有跟上人们对于代码体积越来越大的胃口。

我将会试着同时从理论和实践上解释我的态度。拿我的程序TeX做例子，它按照今天的标准来说并不“大”，它只有500页的代码。我并没有完成对于TeX完全的形式化的正确性证明，尽管我非常喜欢数学证明。但是，我已经非常熟悉验证的基础，我知道如何非形式化地使用它们——大体上我知道如何证明正确性，如果我有时间去研究每一个琐碎的细节（grind through the gory details）。

没有这些基础知识，我的程序可能会经常崩溃，像你我知道的一些商业软件一样。有了这些知识，我就能写出非常稳定和好用程序，但也仅是在我测试了它之后！

让我从另一个不同角度再说一遍：没有理论，我不知道程序可被证明的正确是什么意思，我挣扎前进（flounder）。但是尽管有了理论，我也不能确定我的程序是好的，除非我进行了广泛的测试！

为什么？因为在现实中，没有程序能被真正被证明是正确的：假定的“证明”可能包含错误。如果某人给我看一个经过形式化证明的程序，我不得不检查一下验证过程有没有错误。验证过程也许由机器完成，但是机器逻辑也许是错误的，如此这般。这是一个永无终点的循环。

数学展示给我们理想，我们可以检查证明，直到我们认为它们是合理的。但是只有不会犯错的超人能真正得出证明是正确的结论。

进一步来说，证明程序是否满足它的规格说明（specification）的想法也是值得怀疑的，因为规格说明本身可能是不正确的。实际上TeX并没有精确的规格说明，如果有，我也认为它完全没有用处！（不是每个人同意我这个观点，但他们应该设计并实现一个完美排版软件，在我已完成了TeX这个排版软件的时候。）

总之，我认为将“形式证明”和“测试”分裂开来是危险的。最好的做法是正确地同时使用两种方法。我在我的著作《Literal Programming》的第十章和第十一章详细地讨论了TeX的调试（在《Digital Typography》的第三十四章中讨论了后续开发）。

本刊记者：我们的杂志名字叫《程序员》，所以我的最后一个问题是：什么是程序员，您如何看待程序员？

高德纳：程序员选取一个抽象的算法，并将其转化为以某种定义良好的语言写成的程序中的具体形式，程序才可以被机器执行。

“算法”之于“程序”就类似于“信息”之于“数据”： 信息是理想化的抽象的概念，它或多或少可以由某种精确的方法将其编码为数据，以完美地表达。一个算法是一种理想化的可计算的为某些任务服务的过程，它或多 或少可以由某种精确的方法将其编码为程序，以完美地表达。但是程序员事实上不仅仅是写程序的人。真正的任务是编写可以被人们阅读的程序，而不仅仅是编写可 以被机器分析的程序，因为人们会需要验证它（非形式化的）、修改它和维护它。这就是为什么我坚信“作文式程序设计（literate  programming）”——像文学创作那样写程序，写出自己的风格，为他人所欣赏。
原文：http://blog.csdn.net/programmer_editor/archive/2008/12/11/3501111.aspx