博客园_博文视点官方博客

IT行业博客网站创新与创新（一）ITeye、CSDN、cnblog、ITpub博客网站的比较

2011-07-19T03:22:00Z

此次进行比较的四个博客网站：

ITeye博客频道:http://www.iteye.com/blogs

CSDN博客频道：http://blog.csdn.net/

cnblogs(博客园) ：http://www.cnblogs.com/

ITpub博客频道：http://weblog.itpub.net/

1.基本功能及扩展功能对比

1.1网页访问速度

根据YSlow的评测，四个博客首页的性能评分分别为：

--ITeye: Grade B

--CSDN: Grade C

--cnblogs：Grade C

--ITPUB: Grade C

可见，各个博客首页在性能上都有待优化之处，ITeye是做得最好的博客首页。

1.2基本功能要素

	ITeye	CSDN	cnblog	ITPUB
1.RSS－博客订阅功能	首页无RSS订阅按钮。博主首页可进行订阅	首页可订阅全站精华。也可订阅某一博主的全部博客	同CSDN	同ITeye
2. Trackback-引用通告	´	´	Ö	´
3. Permailink-永久链接	Ö	Ö	Ö	Ö
4. Comments-评论功能	可插入代码、引用、表情	可插入代码、表情	可添加引用、粗体、链接、缩进、代码、图片	可插入表情
5. Archive-文章归档	按照分类及月份进行归档	按照分类及月份进行归档	按照分类及月份进行归档	按照月份进行归档
6. Calendar-日历功能	´	´	´	Ö

经过以上对比可知，CSDN和cnblog在基本功能上实现得更为全面，其界面设计也更加友好。

2.扩展功能

	ITeye	CSDN	博客园	ITPUB
1.RSS订阅功能	首页无RSS订阅按钮。博主首页可进行订阅	首页可订阅全站精华。也可订阅某一博主的全部博客	同CSDN	同ITeye
2.Catalog－分类	ü	ü	ü	ü
3.Search－搜索	ü	ü	ü	ü
4.Statistic－统计	首页不显示在线人数，博主首页显示访问次数，每篇文章的浏览和评论次数均有统计。	同ITeye	首页不显示在线人数，但在底端汇集有“博客、随笔、文章和评论”的总条目数。	首页只显示在线人数。博客文章显示有浏览和留言的次数。
5.Links－链接	无友情链接	无友情链接	设置有Java博客、C++博客等链接	无友情链接
6.Favorite－收藏	ü	´	ü	´
7.Roll－交换链接	´	ü	ü	´
8.Tag－标签	首页有热门tag，博客文章下也有相应的tag	首页和博文内均无tag显示	首页左栏处有专题tag，博文内无tag	首页和博文均无tag
9.AutoLink－自动链接	´	´	´	´
10.Album－相册	有相册功能	博客本身没有相册功能，而个人空间里有这项功能	无相册功能	无相册功能
11.SN－社会化网络	无这项功能	通过“个人空间”的形式承载了这项功能	“我的园子”也实现了这个功能，但是就功能性而言，不如CSDN丰富、实用。	无这项功能

扩展功能中的数据统计一项在这四个博客中均没有得到完整地实现，主页上如果集中显示出用户注册人数、在线人数、访问次数这些核心数据，会直接体现出本博客的影响力，也能够给用户提供一个可供选择的价值评判。

3.网站互动与SNS

	ITeye	CSDN	cnblog	ITPUB
1.微博分享功能	新浪微博、腾讯微博	新浪微博、腾讯微博	´	´
2.好友关系	Ö	Ö	有粉丝与被关注，关系比好友要弱	´
3.小组/群组	Ö	Ö	Ö	Ö
4.短消息	Ö	Ö	Ö	´
5.相册	Ö	Ö	Ö	Ö

从以上分析可看出，ITeye、CSDN都很重视网站用户之间的互动以及与社交每天的交互。Cnblog每篇博文没有分享到微博上的功能，实在是可惜。而ITPUB在这方面做得就比较差了。

4.用户体验与用户服务

	ITeye	CSDN	cnblog	ITPUB
1.反馈邮箱	Ö	Ö	Ö	Ö
2.问题报告论坛	Ö	Ö	Ö	Ö
3.功能改进建议论坛	´	´	Ö	´
4.微博互动	´	粉丝：23696	粉丝：4148	粉丝：364

在用户体验上，有如下问题：

CSDN：

1）label重复的现象，比如第二级的label“好友”与第三级的label“好友”所指向的内容一致，这样会在层次关系上给用户以误导；

2）另外，同一级别下的label功能区分并不明显，如第二级别的label中，有首页、个人主页、我的博客、好友、随便看看、消息。第三级别中有主页、迷你博客、博客、资源、相册、分享、话题、留言和好友。第二级别和第三级别中的“个人主页”和“主页”、“好友”和“好友”两个label属于重复，不明白为何要同时处在这两个层级当中；

3）在我的博客栏目中，有两种目录排列方式：目录视图（只显示目录，不显示文章摘要）和摘要视图（同时显示摘要）。对比了两种目录形式，前者和后者在功能上唯一的差别就是后者提供样章摘要，读者可以查看部分文章内容。既然后一种目录格式的功能要比第一种的强，这就没法将二者的差异性凸显出来，也就让我怀疑起提供这两个目录的必要性了。

Cnblog ：

1）对比CSDN，博客园的博客做得相对简洁清爽得多，各种label不像CSDN那样看上去丰富，其实重复的居多，也给读者的使用带来了不必要的误导。

2）就层次而言，博客园对文章的归类给人的感觉也有模糊之感。比如在“管理”一栏中，有如下label：随笔、文章、新闻、日记等。其中，“随笔”和“文章”两个概念在层次上不应该并列，而是归属，即“随笔、新闻、日志”属于“文章”。

5.创新点

四个博客分别有自己的一些渐进式创新，分别列举如下：

1)ITeye:ITeye有博文下载排行榜。是将博主所有精华文章整理制作成pdf供下载，根据下载量形成的排行榜，对读者来说非常实用，是很不错的渐进式创新。

2)CSDN:CSDN博客专门开设推荐专家板块，权威性更强。

3)cnblogs:cnblogs专门开设了编辑推荐的板块，以区别根据读者阅读量和推荐量形成的推荐板块。

另外，cnblogs每篇博客的浏览界面还提供了简洁板式的浏览，采用简洁版式的浏览方式，可以去掉侧边栏的信息及大部分广告，提供更加良好的阅读体验。另外，博客园的评论功能中添加了“订阅回复”的功能，可以订阅自己关注的回复，是实用的创新点。

4)ITPUB: ITpub还提供了按时间阅读博客的功能，点击之后，按照日历形式展开，可选择阅读某天发布的所有博主发布的博客。是颇为实用的新功能。

6.综合评价:

（5分为满分）

	ITeye	CSDN	cnblogs	ITPUB
1.基本功能	5	5	5	4
2.扩展功能	4	5	4	3
3.网站互动与SNS	5	5	4	3
4.用户体验与用户服务	3	4	4	2
5.创新点	4	4	5	3
6.总得分	4.2	4.6	4.4	3

后记：

这篇博文发布以后，与同事又进行了探讨。博文有如下不足：

1）文章更新后，舍弃了一些基本内容的对比，如博客发布、浏览页面的基本功能等。

2）用来对比的基本功能和扩展功能是查找资料后得到的独立博客应具备的一些功能，用于这些门户性质的博客网站也有部分不合适。

3）另外，主要是进行了列表对比，文字深入阐释分析不多，使得作业的价值大打折扣。

本文链接

暗时间

2011-07-15T07:45:00Z

刘未鹏，Mindhacks帮主，在这块自留地上笔耕不辍了八年。他从2003年在《程序员》杂志上发表第一篇技术文章，并开始在CSDN写技术博客。起初的博客较短，也较琐碎，并夹杂着一些翻译的文章，后来才慢慢开始有了一些自己的心得和看法。八年来，虽然平均每个月写1篇或者更少，但他从未停止。写博客这件事情，给他带来的最大体会就是，一件事情如果你能够坚持做8年，那么不管效率和频率多低，最终总能取得一些很可观的收益。而另一个体会就是，一件事情只要你坚持的足够久，“坚持”就会慢慢变成“习惯”。原本需要费力去驱动的事情便成了家常便饭，云淡风轻。

六月底，一本刘未鹏八年博客文章精选而出的文集《暗时间》即将出版。他说：“善于利用思维时间的人，可以无形中比别人多出很多时间。”这里的“思维时间”，即他所谓的“暗时间”。

作者：刘未鹏

如果你有一台计算机，你装了一个系统之后就整天把它搁置在那里，你觉得这台计算机被实际使用了吗？没有。因为CPU整天运行的就是空闲进程。运行空闲进程也是一天，运行大数据量计算的程序也是一天，对于CPU来说同样的一天，价值却是完全不一样的。

大脑也是如此。

善于利用思维时间的人，可以无形中比别人多出很多时间，从而实际意义上能比别人多活很多年。我们经常听说“心理年龄”这个词，思考得多的人，往往心理年龄更大。有人用10年才能领悟一个道理，因为他们是被动领悟——只有在现实撞到他脸上的时候才感到疼，疼完了之后还是不记得时时提醒自己，结果很快时过境迁抛之脑后，等到第二次遇到同一个坑的时候早忘了曾经跌过跟头了，像这样的效率，除非天天摔坑里，否则遗忘的效率总是大过吃亏长的记性。善于利用思维时间的人则能够在重要的事情上时时主动提醒自己，将临时的记忆变成硬编码的行为习惯。

每个人的手表都走得一样快，但每个人的生命却不是。衡量一个人生活了多少年，应该用思维时间来计算。举一个极端的例子，如果一个人从生下来开始就呆在一个为他特殊建造的无菌保护室里，没有社会交往，没有知识获取，度过了18年，你会不会认为他成年了？

认为时间对每个人是均等的是一个错觉，认为别人有一天，我也有一天，其实根本不是这样。如果你正在学习一门专业，你使用自己所投入的天数来衡量，很容易会产生一种错觉，认为投入了不少时间，然而其实，“投入时间”这个说法本身就是荒唐的，实际投入的是时间和效率的乘积。你可以“投入”很多时间在一件事情上面，却发现毫无进展，因为你没有整天把你要做的事情，要学习的东西常驻在你的大脑中，时刻给予它最高的优先级。你走路的时候吃饭的时候，做梦的时候心心念念想的就是这件事情，你的CPU总是分配给它，这个时候你的思维时间就被利用到了极致，你投入的时间就真正等于了实际流逝的时间，因为你的CPU是满载的。

如果你有做总结的习惯，你在度过一段时间之后总结自己在某某领域投入了多少时间，建议千万不要粗略地去计算有多少天下班后拿起书来翻看过，因为这样你也许会发现书倒是常翻，但领悟却不见得多深，表面上花的时间不少，收益却不见得那么大。因为看书并记住书中的东西只是记忆，并没有涉及推理，只有靠推理才能深入理解一个事物，看到别人看不到的地方，这部分推理的过程就是你的思维时间，也是人一生中占据一个显著比例的“暗时间”，你走路、买菜、洗脸洗手、坐公车、逛街、出游、吃饭、睡觉，所有这些时间都可以成为“暗时间”，你可以充分利用这些时间进行思考，反刍和消化平时看和读的东西，让你的认识能够脱离照本宣科的层面。这段时间看起来微不足道，但日积月累将会产生庞大的效应。

能够充分利用暗时间的人将无形中多出一大块生命，你也许会发现这样的人似乎玩得不比你少，看得不比你多，但不知怎么的就是比你走得更远。比如我就经常发现一些国外的牛人们为什么不仅学习牛逼，连“业余”玩儿的东东也都搞得特牛逼，一点都不业余（上次在《How We Decide》上看到斯坦福的一个牛人，理论物理学博士，同时是世界扑克大赛的前六名保持者，迄今累计奖金拿了六百多万刀），你会奇怪，这些家伙到底哪来的时间，居然可以在不止一个领域做到卓越？

斯坦福牛人Michael Binger，世界扑克大赛的前六名保持者

程序员们都知道，任务切换需要耗费许多额外的花销，通俗地来讲，首先需要保存当前上下文以便下次能够顺利切换回来，然后要加载目标任务的上下文。如果一个系统不停地在多个任务之间来回倒腾，就会耗费大量的时间在上下文切换上，无形中浪费很多的时间。

相比之下，如果只做一件任务，就不会有此损失。这就是为什么专注的人比不专注的人时间利用效率高得多的原因。任务切换的暗时间看似非常不明显，甚至很多人认为“多任务”是件很好的事情（有时候的确是），但日积月累起来就会发现，消耗在切换上的时间越来越多。

另外，大脑开始一件任务的时候必须要有一定时间来“热身”，这个时间因人而异，并且可以通过练习来改变。举个例子，你看了一会书之后，忽然感到一阵无聊，忍不住打开浏览器，十分钟后你想起来还要继续看书，但要回复到当时理想的状态，却需要一段时间来努力去集中精力，把记忆中相关的知识全都激活起来，从而才能进入“状态”，因为你上了十分钟网之后这些记忆已经被抑制了。如果这个“热身”状态需要一刻钟，那么看似十分钟的上网闲逛其实就花费了二十五分钟。

如果阅读的例子还不够生动，对于程序员来说其实有更好的例子：你写程序写得正high，忽然被叫去开了一通会，写到一半的代码搁在那儿。等你开完会回来你需要多久能够重新进入状态？又或者，你正在调试程序，你已经花了二十分钟的时间把与这个bug可能相关的代码前前后后都理解了一遍，心中构建了一个大致的地图，就在这时，呃，你又被叫去开了个会(:D)，开完会回来，可想而知，得花上一些时间来回想一下刚刚弄清的东西了。

迅速进入状态的能力是可以锻炼的，根据我个人的经验，至少可以缩短到3-5分钟。但要想完全进入状态，却是很难在这么短的时间实现的。所谓完全进入状态，举个例子：你看了3个小时的书，或者调试了半个小时的程序之后，往往满脑子都是相关的东西，所有这些知识都处在活跃状态，换言之你大脑中所有相关的记忆神经网络都被激活了，要达到这样一种忘记时间流逝的“沉浸”状态（心理学上叫做“流体验”），不是三两分钟的事情。而一旦这种状态被破坏，无形间效率就会大打折扣。这也是为什么我总是倾向于创造大块的时间来阅读重要的东西，因为这样有利于“沉浸”进去，使得新知识可以和大脑中与其相关的各种既有的知识充分融合，关联起来，后者对于深刻的记忆非常有帮助。

要充分利用暗时间，不仅要能够迅速进入状态，另一个很重要的习惯就是能够保持状态多久（思维体力）。《The Psychology of Invention in the Mathematical Field》上有一段关于庞加莱的思考习惯的介绍，很有代表性。庞加莱经常在去海边休假或者在路上走的时候在脑海中思索数学问题，很多时候解答就在这些时候忽然闪现。虽然我和庞加莱是没法比的，但是常常也在路上想出答案，这真是一种愉悦的体验。

能够迅速进入专注状态，以及能够长期保持专注状态，是高效学习的两个最重要习惯。

很多人都有这样的体验（包括我自己），工作了之后，要处理的事情一下多出了很多，不像在校园，环境简单，生活单纯，能够心无旁骛地做一件事情而不被打扰。工作之后的状况就是，首先需要处理的事情变多，导致时不时需要在多个任务之间切换；另一方面，即便能够把任务的优先级分配得比较合理，也难免在做一件事情的时候心中忽然想起另一件事还没做的焦虑来，因为没做完的事情会在大脑中留下一个“隐藏的进程”，时不时地发个消息提醒你一下，中断你正在做的事情。

因此这里就涉及到最后一个高效的习惯：抗干扰。只有具备超强的抗干扰能力，才能有效地利用起前面提到的种种暗时间。抗干扰能力也是可以练习出来的，上本科那会经常坐车，所以我就常常拿着本大部头在车上看，坐着看或者站着看都可，事实证明在有干扰的环境中看书是非常锻炼专注能力的一个办法:D 另外，经常利用各种碎片时间阅读和思考，对迅速集中注意力和保持注意力都非常有帮助。记得很久以前TopLanguage上大伙曾经有次饶有兴趣地讨论“马桶时间”的利用，包括在卫生间放个小书柜。（估计很多同学心有戚戚焉吧）

本文链接

王泛森：治学经验谈 ── 一些心得，一些反省

2011-02-18T01:16:00Z

新年了，按理该说些什么，可最近一段时间，我总觉得无话可说，能说的以前已经说过了，我也只能说这些，太深的道理我实在说不来，煽情的话我又不乐意说，所以就宁愿不说。不过，新年一点表示都没有，似乎也说不过去，我还是贴一篇演讲，算是送给本博客读者的新年礼物。这篇演讲或许你已读过，但读没读过不重要，重要的是，你是否按照其中一些有益的指引持续地实践过。我以前说过，将所谓的研习方法变成自己的实践技艺的唯一捷径，就是反复地、持续地和有意识地实践。不能付诸实践，读再多这类文章也没多大意思。期末的时候，有同学看到我的“经典导读”结课论文暨答辩印象，给我来信检讨自己的学业，我的回信很简单，“检讨很深刻，行动吧”。我的新年祝愿也就是三个字：行动吧。顺便说一下，刚才温习这篇演讲时，突然想起有几位同学还欠我许诺已久的作业，不知道新春许愿的时候，是否曾许愿能尽快把欠我许久的文章交给我。呵呵。说到这里这段引言也该打住了，否则这份节后的“献礼”，就要变成年前的催债文书了。原文的链接在此。以下是转载内容。

一、簡談我的治學經歷

我是台大歷史系、台大歷史研究所畢業的，後來碩論很幸運的出版，在當時被中研院看中，後來就進入了中研院服務。這在當時是很少的例子，曾經中研院錄取了很多碩士畢業、甚至是學士畢業的人進來，當然這也只有人文學科才有可能，好比今天的英國，依然認為大學畢業就可以大抵看出一個人的程度。但我那時，或許是受到美國學風的影響，大都認為一定要有博士才能夠進中研院，所以我可以說是非常幸運的。後來去了普林斯頓，留職留薪待了五年，又回到中研院服務，直到現在。我研究的重點大抵是明清、十五世紀的一些文化、思想。

二、研究學問的快樂

甚麼時候我們研究學問是最快樂的？那就是當我們發現一個問題，而自己又剛剛好略有所得，也就是你有一點點想法、心得，對這個問題有若干美好的想像，手頭邊又有若干的材料的時候，這時候是做學問最快樂的時候。

三、研究學問最痛苦的時候

有幾件事情，是我覺得是做研究最痛苦的時候。第一就是校對，尤其是完成一篇文章，然後要重讀，並且不斷更改的時候。我在台大的時候，有位老師的名言是：「時間永遠是不夠的」，這句話當我年紀越長，我越有體會。我這個人不怕讀書，不怕寫論文，但我最怕的就是校對，首先它需要很多的時間，加上我這個人有壞毛病，看到不對的地方就會更改，甚至有一本書放了十年才出版，原因就是因為我太怕校對。但是我有兩個方法來解決他，第一就是要限定自己在一個時間內把事情完成，好比我，我每個禮拜會有一到兩次會限定自己晚上九點到凌晨三點，一定要把文章完成，讓時間成為你的壓力，讓你能夠總是在限定時間中完成事情。我以前在哈佛大學讀書，認識了各式各樣的人，一大推很聰明的學生匯集在此，但是有超過一半妳過陣子就看不見他們了，為什麼？因為他們沒有辦法按時繳交學期作業，這是很重要的事情，有一次，跟一位同學一起去逛超級市場，遇到了她的導師，老師跟他說：「許個願，告訴我你甚麼時候把積欠我一年的報告交出來」。這是第一個，在決定時間把事情完成。

第二痛苦就是書寫障礙，有的人很會讀書，很會做研究，但她做完研究之後就會覺得，這有點複雜，不會寫出來。事實上，這也是有解決方法的，一就是你不要急，不要邊看書邊寫，我知道在座各位跟我很不一樣，你們都是用電腦寫文章，我還是在用筆寫的人。我知道很多人都拿著一大堆書，邊看邊寫，我做不來，我覺得那樣也不是很好。論文他是一個有機體，他像是一個生物，你必須讓它自然、協調，互相論證，解決的方法有兩個，一個就是每一天一段一段寫，永遠不要一口氣寫完，這樣你會發現文章有條理，而且不會內容跑掉。第二就是花時間去「呈現」，這是跟自然科學很不一樣的地方，他們都是數據，很簡單的就可以呈現。但我們不同，英文的論文如果你用詞稍一有問題，人家立即給你退稿，除非你的文章非常非常的特別。我希望大家能夠用60%的時間做研究，但用40%的時間寫東西，而不像有些人只用10%。

四、寫論文時要做的事情

第一，有創造性的壓力。這個壓力不可以太大，大到讓你無法正常工作、思考；這個壓力也不可以太小，小到讓你沒有感覺，所以我說這是創造性的壓力。

第二，要有責任感以及罪惡感。你對自己的進度、學問、論文，當你怠惰了，當你沒有以往那麼專注了，要有罪惡感，督促你回到軌道上，而對你所處理的事務也要有責任感。

第三，有意義的問題。這是最重要的，我以前台大的老師曾經說過，寫一個沒有意義的問題，與寫一個有意義的問題，所花費的時間是差不多的，頂多有意義的問題多花費幾成的時間。有意義的問題，才可以使你做學問，做得有興趣，而一個真正有意義的問題，它的特色就是「與其他學科相通」，好的問題就好像一個房間，它裡面有好幾扇窗能夠互通其他學問，往往其他的學科一個念頭，或者一種新的說法，總是能夠互相在某種程度上相通，這就是一個有意義的問題。

第四，材料要適當的集中。以前在讀書的時候，有一位同學，現在姑隱其名，他現在任教於台北的某大學。他碩士論文選了一個題目，很有意義，題目我記得沒錯的話，是魏晉南北朝某個時期北人南來還是南人北來的問題，這個問題很有意義，可以探討南北文化交流。但是史料何其多，而且分散得太大，搞得他晚上睡覺的時候，夢到一個人跟他說，我也是北方南來的，你別忘記我了。這就是材料必須相對集中的意義，這才不會讓你花了80%，甚至更多的時間找資料，把你搞得半死。

第五，別把目光停留在材料上。現在資訊很方便，以前我們要翻檔案，花二十年，但現在花幾秒就可以找到一大堆資料，尤其一大堆漢籍電子資料庫，簡直是太方便了。但是，千萬別停留在材料上，你必須將視角拉高，想想這些材料代表甚麼？而非一股腦地鑽進去研究「裏頭」的東西。

第六，隨時注意新領域。投入新領域通常都比較容易獲得成就，我們看諾貝爾獎的得主，大部分都是開創一個領域的人，而後來加入這個領域，並且順利解決問題的人卻沒有那麼受到重視。因此，隨時注意新領域是很重要的，但是也千萬要注意它是不是已經很「擁擠」了。有的學問在國外都已經發展很久了，你又突然投身進去，實際上收穫並不會太大。

第七，問題要分多個層次看。我是歷史學家，我們都是在解釋歷史現象，在解釋歷史現象的時候，要儘量多分好幾個層次看，但也不能太多，太多就會搞得複雜且也沒有太大的意義。

第八，形成清楚的論證。當你著手撰寫論文，要形成清楚的論證，最好是對整個題目有整體的看法，然後再開始寫，別太仰賴資料庫以及一大堆資料，要儘量有自己的想法。論文題目論證的這種概念實際上是西方在近代引進的，好比中國著名的文學家黃侃，他也寫了許多論著，但根據我的老師(余英時)的說法，他並沒有形成問題意識，圍繞著問題做學問，這也是論證式研究與傳統中國學者之間的差別。

第九，寫的時候就要有出版的決心。這並不是說每個人都一定能夠出版，而是希望大家在寫論文的時候都能夠抱著一顆出版的心，只有這樣，才能夠讓你的決心夠充分，認真把事情做好。

第十，研究、讀書、著述是三回事。我在中研院看到一些人，一輩子就是看書，而且是每天看，但卻很少著述，有時候去中研院餐廳吃飯，遇到他總會問說，最近有甚麼好書可以看？他會丟個幾本書給我，我再去找找。你說他有學問嗎？有，這就是西方說的移動式的倉儲、百科全書，我要告訴各位，研究、讀書、著述三者是不同的東西，但是三位一體，沒有一個可以偏廢。

第十一，思而不學則殆，學而不思則罔。

五、寫論文時應避免做的事

第一，避免眼高手低。中國近代人物裡面，有一位叫做黃侃的學者。他認為當時的學者都不如他，甚麼胡適、傅斯年，他認為人應該要把大體、細節都掌握清楚了，然後再開始寫東西。他花了一輩子的時間「讀書」，直到他五十歲的時候，他說：「韋編三絕今知命，黃絹初成好著書」，沒想到同年就去世，這就是眼高手低的一個例子，人空有學問，但沒有作品，評價就會不高。

第二，要克服心理障礙。例如前面提到的寫作障礙。

第三，別一直做準備。不要老是花時間看資料、找資料，然後一直打轉，一事無成。我以前在台大的老師(姚崇吾)有一句名言：「騎馬要騎在馬背上，游泳要跳到水裡」，意思就是說想到就要去做！

第四，要知道在哪裡捨棄。我以前在哈佛讀書，最聰明的就是一位荷蘭同學，每個教授都誇他多好多好，對哪個領域多專精這樣。但是後來她寫出來的博論，卻是最差的。為什麼？因為她太了解每個東西了，所以她太注重細節，總是要計較A，又從A追到B，B到C，C到D，他的論文到最後成為一種片段問題的總集合。寫論文要能夠掌握大概，解決一個核心的問題，別拘泥在很多小地方，所以說要知道在哪裡捨棄。

第五，事情的發展與歷史研究是相反的。歷史事件的發生是A > B > C > D，但是歷史研究卻是相反的D > C > B > A，在這種過程裡面，我們往往忽略很多事情。好比近代台灣，戒嚴時期黨外最有名的人士黃信介，哪是黃信介？當時最紅的是康寧祥，多少大學生翹課去聽他的政見發表會，可以說是萬人空巷，它代表了當時溫和改革派的主流，後來黃信介這些人成功了，因此得以留名。現在每個人在寫的時候，就寫黃信介，康寧祥被遺忘了，但是歷史不是回去到著扣，過度簡單的解釋，我們常常因為這樣而把許多論點搞錯。

六、學術研究的精神氣質：性格與學術

甚麼是氣質，這跟做學問有甚麼關係，最重要的就是量材適性，了解自己的才性。中國有一部書叫做《世說新語》，裡面花了很多時間來談論人的才性，以前我不懂，後來我漸漸懂了。就是說人人有適合的地方，好比司馬光，被同時代的邵雍說只是一個資質平凡的人，沒有辦法做哲學性的思辨工作，但他卻編了《資治通鑑》，直到今天我們都還在讀，我想五百年後、一千年後的人也會繼續讀資治通鑑。但又有多少人懂邵雍的哲學呢？並不是說那不好，而是要告訴大家，每個人都有自己適合的才，你要找到並且去發揮他，任何人都可留名，在這個程度上，可以說智商沒有太大的意義了。又好比清代阮元的《十三經注疏》，他們都不是我們說頂聰明，領時代風騷的人，但他們做這種工作卻也可以流芳百世，直到今天我們都還需要使用。因此，了解自己的才性之後，我要告訴大家，要做切實的學問，不要趕時髦，這樣才可以長遠。

七、種種不可少

八、尋覓、困惑、挫折是研究過程中不可少的環節

九、研究社群的塑造

受限於時間，我們跳過幾個，簡單談一下來結束這次的演講。首先我在綱要裡面提到「懶散空間」，這是很重要的，我在哈佛的時候發現，一個好的學術環境都必須讓人能夠適當的「放鬆」，而且能夠讓人跟人互相討論，這是很重要的事情。台灣的學術環境就是太緊了，壓迫得人們很有壓力。第二個要談的就是天才是成群而來的，詳細可以去找中國一個期刊叫做《南方周末》(尚未查證)，裡面有提到，西方做學問是大家一起做的事，故一群人把一個人頂上去。

十、一些反省

最後，我要跟大家分享我的反省。那就是一張紙片不可少，一張卷宗不可少，你隨時想到甚麼，都把他記下來，因為想法都是稍縱即逝的。然後要有膽量，像我做學問就是太保守，另外英文要好，最好是多學好幾種語言，然後要多跟人討論，多參加研討學術會，但不要參加太多，做太多的討論。謝謝大家。

本文链接

追求神乎其技的程式设计之道（十一）- 抽象化与命名

2011-02-17T01:03:00Z

休眠已久的神乎其技系列又復活了！这篇文章其实写很久了，只是一直断断续续到今天才完成它，久到让很多人觉得这系列已经完结了…。但我想只要我还有在写程式，这系列就永远不会结束吧。

简洁、弹性、效率
我一直觉得写程式是一种艺术活动。程式语言是一种要求极度精确的表达方法，只要少打一个字母就可能造成完全不同的结果，但同时却又不限制你要如何达到目标。

程式设计师有极大的自由来让一个程式按照自己的想法「活起来」，不同人针对同样的目标所写的程式也一定不同。有人会用极简主义来把变数命名为a、b、c，也有人会把用匈牙利命名法让变数前后长出鬍子和尾巴；有人坚守DRY原则(Don’t repeat yourself)，只要类似的程式出现两次，就把他们抽象化成一个函数，也有人用copy/paste写程式，不管怎么page up或page down都一直看到一样的东西还能泰然自若；有人写程式把所有东西都塞在main里面，也有人写个Hello world就要搞一个class HelloWorld（虽然有些时候是被啰嗦的J语言强迫的…）；有人没听过Big O也写程式写得很开心，但也有人嫌stdlib的qsort太慢硬是要自己重写一个…。

尽管每个人的信仰和原则不同，但大体上程式艺术家也不过是在「简洁」、「弹性」、「效率」这三大目标上进行一连串的取捨(trade-off)和最佳化。

「简洁」的程式也「易读」，没有多余的叙述或重复的程式码，每个概念都只有唯一的一段码在描述它。如果多了，就容易产生不一致的行为，如果少了，就是没做到该做的事。有「弹性」的程式容易修改和扩充，只要在一个对的地方弹弹手指，不用因为老闆朝三暮四或是需求改变就得把整个程式重新翻修一次。有「效率」的程式会用最适合的资料结构存放每一样资料，用最快的演算法做每一项必要的计算，并去除任何不必要的间接行为 (indirection)。

虽然目标很明确，但程式设计之所以像艺术就是因为大部分时候我们都没办法兼顾这三项目标：为了效率，可能就得牺牲弹性和简洁；反过来说，为了弹性或简洁，也常得牺牲效率作为代价。幸运的是，效率的追求在电脑硬体和编译器技术的进步下已经不像20年前那么重要，只要选对资料结构和演算法，几乎已经没有必要手动做低阶的最佳化。除去效率之外，弹性和简洁其实是比较容易同时达到而又不互相冲突的目标。要达到这目标，其中关键的能力就是今天的主题：「抽象化」(abstraction)。

最简单但也是最难的事情
很多人没听过抽象化这个词，甚至以为自己不会这件事，但其实从我们宣告第一个变数起，抽象化就已经开始了。

「这个变数要叫什么名字？」

帮变数命名时，其实就是在赋予那个变数一个「意义」。人的记忆力有限，很难记住大量且没有意义的资讯。但如果资讯有了一个固定且有逻辑的名字，我们也就有一个容易记忆的符号来代替整个复杂的概念。换句话说，我们可以把非常复杂的概念浓缩为一个容易处理和记忆的小单位，这个过程就叫做「抽象化」。

抽象化可以让程式变得简洁。好的程式设计师会习惯从重复的程式码中找出共同或相似的部份，并且把这个部分提取出来变成一个更通用的概念。任何复杂的概念都可以被抽取出来替换成一个变数、一个函数、一个类别、一个模式、一个模组、甚至是一个系统，并加上适当的命名，就能让这个程式「一看就懂」，任何註解都不需要写。抽象化也能让程式有弹性。经过适当抽象化的程式，每个概念都有一个独立的「单位」（可能是变数、函数、类别、模组、或系统）可以表示，每个概念中包含的细节也被隐藏在适当的范围内，不管要修改或扩充原本的程式都能让需要碰触的地方减到最少。

虽然抽象化是让程式简洁又有弹性的关键，但出乎意料的这是一个容易理解却很难精通的能力。抽象化做得太少，程式会变得凌乱不堪，不同层级的概念和资讯互相交杂在一起，不仅让程式变得难读也难改。抽象化做得太多，就是所谓的over design，明明需求只有印一个Hello World，却用了10种design patterns盖起101大楼以应付根本就不会出现的「未来需求」。

抽象化这个主题可以讲三天三夜讲不完，但今天我只想提其中最简单也最难的事：「命名」。

命名可以说是写程式时最简单但也是最难的事了。这件事没什么人会教，没多少书会写，因为这件事看起来非常容易，即使你把程式里的变数照字母顺序a, b, c, d, e, …命名也是行得通，反正对编译器来说变数或函数的名字不过就是一个没有意义的符号，不管你取什么名字最终都只是对应到一个像是0×08048374这个样子的记忆体位置而已。

简单来说，一个变数是叫「小狗」或是「小猫」，对电脑来说都没有区别，但对人来说，差别可大了。

很多初学者以为程式是写给电脑看的，只要看起来好像能跑出正确结果就好，所以变数位置随便乱放、名字也随便乱取、每个变数都是public、甚至一个函数有几百行，为了在一个画面中塞下更多程式码还把IDE的字型缩小到要瞇着眼才看得见。也有很多人觉得高手写的程式看不懂是正常的，等到自己等级提昇后应该就会看得懂了，但其实事实完全不是这样。我认识的每个高手和大师写的程式码都是干净、简单、易懂，即使是极端复杂的演算法，都能直接从程式码中看懂作者的想法。

Martin Fowler的 “Refactoring – Improving The Design of Existing Code” 一书中有一句话我很喜欢。

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. （任何一个傻瓜都能写出计算机可以理解的程式码。唯有写出人类容易理解的程式码，才是优秀的程式员。)

一段好的程式码是不需要任何额外註解或说明的。如果名字都取得好，每个变数就能适当的解释了自己的角色，每个函式都说明了自己的功能，整个程式读起来就会像在读说明文件一样自然。在这种境界下，只要有了基本背景知识的程式员应该都要能轻易地看懂。英文中有个词叫做explain itself很适合用在这，也就是自己应该要能完美的解释自己的一切，不需要其他的人或文件来帮忙。

但是，命名是很难的一件事，可以说是写程式中最接近「艺术」的一部分了。我说的命名，不是要用大小写混杂的「CamelCase」或是底线分隔的「underscore_separated_style」这种风格问题，而是一个方形到底要叫rectangle或是x的差别。名字取得好，不但自己或其他人未来再回来看这份程式码时容易进入状况，对于正在开发中的程式也可以减少很多不必要的bug。

我之前当一门课的助教时，有个作业是要学生实作一个西洋棋游戏，画面上要有个棋盘，还有该有的棋子。既然是个棋盘，底层很自然的就会用个二维阵列来表示棋盘的状态，例如说我们会有

Chess board[N][N]这样子的一个阵列。接下来，真正的问题来了，程式中势必会有一些两层的for迴圈去对这个阵列做操作，如果是你会把这两个迴圈的index变数取做什么名字？

最常见也最不用脑的index命名就是i和j，在一般没有特殊意义的迴圈中用i是没什么太大问题的，因为大家都知道这只是一个单纯的index。但如果用到j，通常就代表程式可能有些臭味了，至于会用到k、l、m… 那这个程式一定是彻底腐败了。

我看了很多学生的程式，我发现很多有bug的程式都是用i、j，或是x、y来命名，而那些写得很漂亮的程式，几乎都是用row和column来命名（或是他们的缩写r和c，或是row和col）。

用i、j的问题在哪？

问题在这两个名字没有和棋盘的位置有直接关连，看程式的人没办法一眼看出你的i到底是指row还是指column，或是指到宇宙里的一颗星星。即使是正在写程式的作者本人，也得一直在心中做i是row、j是column的转换，但只要精神稍不集中，或是吃个饭休息回来，很轻易就会忘记这些隐晦（implicit）的对应关系。而这种隐晦的对应，就是伤害程式码可读性和造成bug的通缉要犯之一。有的人为了避免自己忘记这些细节，就会把这种隐晦的关系或假设写在程式的註解里。但话说回来，既然要写，直接写在程式码里不是更好吗？

除了用i、j的这群人外，还有另外一群用x、y的程式也是让人非常头痛，如果要我比较的话，我会说用xy比用ij还糟糕。为什么？因为这个程式最终要把棋盘画在萤幕上，而所有2D绘图的函式库都是用x、y来表示萤幕上的位置，如果棋盘用xy，萤幕绘图也用xy，这样如何分辨这个xy是棋盘的位置还是萤幕的位置？用xy这群人的解决方法都大同小异，比较懒惰的就是用x1、x2，甚至是x和xx；好一点的会用boardx和screenx，但以index变数来说还是太长太啰嗦了。

与其费这么大力气区分两种xy，如果一开始就用完全不同的名字来存取棋盘和萤幕，不就没事了？以二维阵列来说，用row和column符合natural mapping，不用再心中自己多做一次转换。此外，现代程式语言的多维阵列大多是row-major排列，也就是说A[r]就能取到第r个row，A[r][c]就能取到第r个row的第c个元素；但如果用xy来存取二维阵列，就要把xy反过来，写成A[y][x]才能取到第y个row的第x个column。
（在这个程式中很多用xy的人都把row和column顺序搞反，导致初始化的盘面整个转了90度。）

我以前参加程式比赛时，看过很多经过长期训练的选手因为比赛的时间压力而养成不好的习惯，像是把所有程式码写在main里面，变数不是aa就是bb这种没意义的名字。在程式比赛这种特殊的环境里，每个程式的目的就是解一个有明确输出入规定的问题，加上有时间限制，所以选手们都是尽量用最短的code来实作自己的想法。这种情况下写的程式可以说是用完就丢，只要比赛一结束这个程式的生命也就到了尽头，所以很多人就不会去思考命名的问题。

到大学的时候，我也常帮同学在作业deadline前夕看他们的程式帮忙debug。很奇妙的是，大学课程的期末专题或是作业应该都有充裕的时间可以慢慢「设计」一个程式，但很多人都是在最后一两天才开始动手，于是在作业死线的压力下也没心情去好好设计一个程式的架构，更别提要好好想每一个变数的命名和位置，也就浪费了许多可以好好练习这个命名艺术的机会。

命名和抽象化是一体两面的事情。当你能把一个概念用一个适当的名称来称唿它时，你才有办法把这个概念当成一个基石往上建构更复杂的事物。在此同时，人们也才能用这些简单的名称来讨论复杂的概念或想法。如果你在写程式时常常没办法用很简单的话跟别人解释你的程式，通常也代表你的程式是一团浆煳，没有条理和层次。在这种情况下，你怎么知道浆煳里是不是黏了一堆臭虫呢？反过来说，当你能用简单清晰的白话跟人解释你的程式时，你也一定能把程式写得一样干净漂亮有条理。

如果你现在还在用a, b, c这种变数写程式，不妨先暂停一下，好好想想每个变数的意义是什么，你的程式就会自然的变得越来越简洁和漂亮。

（待续）

2/1 更新：
有朋友提到一篇有趣的相关文章：软体业的重要职缺命理大师!。这文章说软体公司应该有个专门掌管命名的人，才能保持整个project的一致性，并顺便算个命看看这些名字吉不吉利。

这让我想到，其实现有open source程式这么多，我们可以很容易的写一个「命理大师」程式出来。只要到几个project host site，像github、google code之类的地方，把所有project里的程式码token抓出来做一些简单的分析和统计，就可以得到一些有趣的资讯和命名时的参考。例如说，我们可以知道有多少程式里面用Box表示方形，多少程式用Rectangle，多少程式用deleteXXX，多少用removeXXX，他们之间的区别又在哪。甚至在设计library或API时，连function参数的多寡和排列顺序，都可以从此得到参考资讯。更进一步，可以用word net把这些token做clustering，之后我们就可以打一些关键字，甚至打中文，让这个程式建议最多人用的习惯命名法…。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/bvbook/archive/2011/02/17/6190582.aspx

本文链接

堆积式南丁格尔玫瑰图模板（ Nightingale Rose Diagram）

2011-02-16T01:38:00Z

在不等半径扇形图（南丁格尔玫瑰图）日志中，引用了一个比较facebook和twitter的信息图表，很多人询问如何制作。该图是具有堆积特征的玫瑰图，用该日志思路就可以制作出来，只是需要多准备一些数据系列。

我制作了一个模板文件，填入数据即可获得精美的堆积式玫瑰图，本篇日志即介绍这个模板的构建方法。写这篇日志的时候发现，做这个图还算容易，但要把作图原理和步骤描述清楚却真不容易，欢迎大家多提宝贵意见。

【作图思路】

还是使用雷达图来制作，每个扇区的每个堆积部分都是一个雷达图序列。

有人可能会问，雷达图不是多边形的吗，怎么能做成扇形图呢？我们可以这样想，当年祖冲之是怎么求圆周率的？对了，就是用多边形逼近圆形的。现在我们也是用多边形来逼近圆形，只要数据点足够，多边形就变成了圆形。也不要太多，360个点就足够了。

【作图步骤】

1、组织作图数据。

本例的作图难度并不大，关键在于作图数据的组织，其中不乏精巧之处。建议打开模板文件对照阅读。

假设有12个维度的数据，每个维度有不同的分类数，相关数据输入在B6：N20区域。不同维度的分类数可不相同，如性别只有男女2类，收入则可分为6个档次。

雷达图不支持堆积形式，必须自己先对数据进行“堆积”转换。将分项数据转换为逐步累加的累计值，这样某项图形高出前一图形的部分，正好与该项的值对应。

考虑到扇形图中心部分比较小，不便于观察比较，可以在中心留下一个圆心，从圆心外围开始比较数据。因此在转换之前，我们设置一个圆心参数C26，可以自由控制是否需要绘制圆心，以及绘制多大的圆心。

转换区域的公式为：

C29：=IF(C15=0,0,SUM(C$15:C15)+$C$26)，注意堆积数据加上了圆心半径参数。复制到整个转换区域C29：M34。

对第N列的维度12，因为可能要用来绘制圆心，需要做特殊处理：

N29：=IF($C$26=0,IF(N15=0,0,SUM(N$15:N15)+$C$26),C26)

N30：=IF($C$26=0,IF(N15=0,0,SUM(N$15:N16)+$C$26),0)，复制到N34。

也就是在需要绘制圆心时，N29指定为圆心半径，N30：N34指定为0，否则均同前按普通扇区处理。

第36~38行放每个扇区的角度数，起、止角度。可通过这里控制玫瑰图的扇区数，也就是前面维度的个数。甚至还可以通过这里控制做弧度不等的玫瑰图。

现在准备作图数据。数据比较多，可选择另外一个工作表展开。

第5、6行放对维度和分项的索引编号，便于后续引用。共12*6列。

注意第6行的索引编号方法，是逆序的6、5、4、3、2、1。这是因为图表里后面的序列会遮盖住前面的序列，这里将分项的索引号逆序编排，以使同一维度上的多个堆积序列，图形上半径长的在“后面”，半径小的在“前面”，避免相互遮挡。

第8、9行放每个堆积扇区的起止角度数据，根据第5、6行的索引编号引用转换过来：

C8：=INDEX(Data!$C$37:$N$37,作图数据!C5)，向右复制。

C9：=INDEX(Data!$C$38:$N$38,作图数据!C5)，向右复制。

第11行放每个堆积扇区的半径，也是根据第5、6行的索引编号引用转换过来：

C11：=INDEX(Data!$C$29:$N$34,作图数据!C6,作图数据!C5)，向右复制。

从B14往下填充序列1~360，作为图表数据点的判断依据。从C13开始往右填充公式：C13：="f"&C5&C6，作为各序列的名称。

整个C14：BV373区域为作图数据源，共360行*12*6列，输入公式为：

C14：=IF(AND($B14>C$8,$B14<C$9),C$11,0)，即对处于起止角度之间的数据点赋值为相应的值。拖拉复制到整个360行*12*6列区域。

2、用整个360*12*6的数据区域做填充型雷达图。

此时得到的图表黑乎乎的看不清，清除数据标签和数值轴，即可看到堆积玫瑰图的雏形。

3、对图表进行格式化。

根据需要，对各扇区进行颜色填充。若是使用2007以上版本，格式化出老外例图的样式完全没有鸭梨。

4、手工添加标签数据等信息。可使用文本框、链接或拍照等方式。

本例中使用了C36：N36的数据加入图表做饼图，以显示圆形的灰色底衬，以及外围的维度名称标签，有兴趣者自行研究，这里不再细述。

OK，一份堆积式玫瑰图完成了。

此前日志的单层玫瑰图，其实可以看做是这个堆积式的简化形式，就是分类项目只有1个而已。因此本模板也可以取代前一日志的模板。

【模板使用】

本模型设计已经比较完善，现在要做一个玫瑰图，你只需填入数据，调整相关参数，即可自动得到一份精美的堆积式玫瑰图。可适用于Excel2003/2007/2010。使用步骤：

1、在B6：N20填入相关原始数据。模板支持12个维度，多出的可以填0。不足的可以自行扩展，需要了解整个模型的原理。不过太多就不好了。

2、若需要绘制圆心，在C26处填入参数，建议是30%。不需要圆心则填0。

3、根据维度的个数，也就是需要绘制扇区的个数，设置C36处的扇区角度参数。

4、得到玫瑰图，检查其正确性，添加数据标签等信息，完成。

上图即是利用此模板，仿制的那个facebook分析的图表。是不是比原图还要漂亮，相信这是在Excel中完成的吗：）

【注意事项】

堆积玫瑰图的优缺点和适用场合：

优点：可在一个图表中集中反映多个维度方面的百分比构成数据，幅面小，信息量大，形式新颖，吸引注意力，够高级，够给力：）

缺点：非常见图表形式，多数人不易看懂。图形存在误导因素，同样的半径长度，越往外面积越大，但实际是以长度代表数值。

适用场合：适合书面研读，不太适合PPT讲解。适合商业杂志、财经报刊等媒体做信息图表用途，传统工作场合需慎用，可能会给人用力过猛、炫技、夸张的感觉。

制作难度：★★★★★

实用性：★★★

本文链接

磨刀与砍柴

2011-02-16T01:32:00Z

2010年的最后几天，我在CSDN和博客园上同时发表了一篇博文——《软件天才与技术民工》，引发了许多人的关注，不论是在CSDN还是博客园，都有很多网友回贴，《天才是训练出来的》一书作者薛涌先生还通过新浪微博给我发了信息，并在他的博客上全文转载了这篇文章。

事隔一月，我又收到了一位朋友的邮件（内容见下），提出了一个很有意思的问题：

==============================================

金老师：
          请准许我这样称呼你，你好。
          我看了你写的文章《软件天才与技术民工》，写的真的很好，我很有感触，
          我是属于你那里面的最后一种人——家里买不起电脑，更别说上网了，你可能要到大学才第一次接触到电脑……
         从小就是很努力但是怎么都学不好的那一种人，
         我现在工作满差不多2年了，但是觉得2年来没有任何进步，一会觉得基础知识差想补基础知识，一会觉得有新东西要学，又去学新东西。。我发这封邮件其实就想问一下，学技术到底是先学好基础再去学新知识还是学新知识的时候一边补基础。。。
        能不能给我点意见，谢谢您。新年了，祝你身体健康，合家欢乐。

=============================================

以下是我的回信，代表了我的观点。

=================================

你好！

你提的这个问题真的很棘手。

按“正统”的观点：把基础打好，高楼才能盖得起来。但把基础打好是要花时间的，而且基础扎实对个人发展所带来的优越性是慢慢显现的，并非立杆见影。所以打基础的前提是衣食无忧，在肚子问题没解决的时候，说要“打基础”是不靠谱的，你还是先想办法把肚子对付过去了，然后，再回过头来把基础打好。

所以，对于已经工作的朋友而言，我的建议是应付工作是第一位的，工作中需要掌握的东西优先权最高，急用先学，哪怕由于基础不好这些技术掌握得不好，也要先赶鸭子上架，尽可能地先应付过去，以“能完成老板交给的任务”为最高目的。这么做的原因很简单：你不想失业饿肚子。

在基本上能保证温饱之后，你就需要把“打基础”这件事提到日程上来了，这时，通过工作相信你已经比较清楚你哪些地方不行了，那就别说废话了，马上动手学吧！

小结一下：

虽然俗话说“磨刀不误砍柴工”，但在实际生活中还是要灵活处理的。我们不妨暂时先用一把“钝刀”去“胡乱”割些比较容易的“杂草”，目的是能先煮一锅饭对付对付自己的饥肠辘辘，有了点力气就可以去磨刀了，而刀磨得越利，以后砍柴就越轻松，我们就开始走在大路上了……。你说，是不是这么一个道理？

以上观点仅代表个人想法，希望对你有点帮助。

金旭亮，jinxuliang@bit.edu.cn
=====================================

对“磨刀”与“砍柴”的顺序与彼此关系问题，大家的观点是什么呢？有兴趣的朋友不妨妨谈谈自己的看法。

本文链接

我为何爱读代码？你为何也应当爱？

2011-02-16T01:12:00Z

我恨读代码

我发现，许多程序员都讨厌读代码——拜托别掩饰了，承认吧。差不多每个人都喜欢写代码——写代码乐在其中。可是，读代码真是不容易，而且还很烦人，又无可逃避，其他人写的代码总是很垃圾（即便不说，我们心里也这么想的）。即使自己写的代码，过几个小时再看也有点垃圾，过的时间再久点，就更垃圾了。那么，还有什么理由去看别人的蹩脚代码，而是不自己写几手漂亮的？能不能暂且忽略这个问题，花上几个小时看别人的代码，再回头来看自己的是不是还那么漂亮？即便有位大师坐在你面前，如果你不能从他身上学习，你永远也成不了大师。办法之一就是找到这么一位大师，让他手把手地教会你全部知识。有这可能吗？——当然有，只是很难遇到这顶好的运气。不过你也不必奢求那么幸运，做程序员这行就很幸运，因为大师们的所有思想和技艺都凝铸在他们的代码里，供我们学习。你要做的只是阅读代码——当然，如果有人给你一点点地讲肯定更节省时间，但这基本属于痴人说梦。换句话说，要相当个好木匠，得仔细研究大量的精美家具。

我热爱读代码，我总是直观地认为读代码的收获很大，没错，它可能有点讨厌甚至烦人，但你的收益绝对大过这点麻烦。举个例子，你要当大作家，是不是只关心自己写东西就够了？你可以试试看，但是估计不会折腾不出什么名堂。公认的事实是，多数大作家都是会如饥似渴大量阅读的。想写出好的作品，必须先阅读其他大作家的作品，吸收不同的风格，了解他人的尝试，然后才可以培养自己的创造力。这样，你的知识才能逐渐积累，最终你写的东西才有几分成熟，你也才会找到“感觉”。写代码也是这样，如果你不去阅读那些伟大的代码，怎么可能把程序写的漂亮？阅读伟大的代码之于程序员，就如同阅读伟大作品之于作家（我不敢掠美，这句话是Peter Norvig(译注：Peter Norvig是著名的Lisp程序员，现任Google研发总监)说的，他可不是个简单人物，所以好好记住这句话吧）。

即使上面说的你都不信，但有个事实无可否认。要想当个称职的开发人员，能熟练阅读代码是非常重要的。如今，只要不是闹着玩的项目，都是团队协作的成果，所以总会有这样的代码：它不是你写的，但你必须跟它打交道，去修改，或者去扩展。于是，阅读代码很可能就是你身上最重要最常用的能力了，咬紧牙关练好这门本事吧——而且，要快。

要像…会读代码的那些家伙一样…阅读代码
我都说不清有多少次见过这样的事情了：程序员把一段不熟悉的代码上下拖动，几分钟之后仍然一脸迷离。不久他们就宣布，这段代码根本没法看懂，更不必浪费时间了，可以想办法绕过这个问题。我不知道他们真正要做的是什么，一点点弄明白这段代码的意思，还是睁大眼睛等着开窍？阅读代码不靠成年累月死盯着看，你要做的是弄懂它，把它变成自己的。下面说的是我用的一些技巧，但不是全部，不过我觉得这些非常有用。

看代码看到目光迷离

1. 尝试亲自构建和运行程序。通常这一步很容易做到，比如你看的是真正运行的工作代码时（而不是不知来源的古怪代码）就是如此。不过也不是每次都很容易，如果不能很容易地构建和运行，你可以在完成构建和运行的过程中，认识到代码的高层结构。而且，阅读工作代码，你会非常熟悉如何构建项目。构建通常是复杂的，但是了解构建过程，知道代码是如何变为可执行程序的，会大大加深你的理解。

2. 别死盯细节。读代码要做的第一件事，是找到对代码的结构和风格的感觉。开始应当浏览，并且努力找出各部分代码都在干什么。这样你能熟悉整套代码的高层结构，也会明白你正在看的是什么样的代码（重构良好的，还是乱成一团的）。这时候你要做的就是找到入口（可能是main函数，也可能是servlet，controller之类），看看下面的分支是怎么展开的。这一步不要花太多时间，你对全部代码更熟悉之后，随时可以退回来。

3. 确保理解所有构造（construct)。除非你非常精通这门编程语言，否则多半还有些东西是你不知道的。在概略了解代码的阶段，要记下每一个不熟悉的构造。如果这样的构造有很多，下一步就不言自明了。如果搞不懂代码行为的意义，你什么也干不了。即便你不熟悉的只是少数构造，仔细观察推敲没准也是好事。你可能会找到一些以前不知道的关于这门编程语言的知识，我就很乐意为此花上几个小时。

4. 待熟悉了大多数构造之后，就可以搞几次随机的深入探查了。做法类似第2步，快速浏览代码库，但是这次要随机抽几个函数或者类，一行行地看下去。真正的考验现在才开始，但你的收益也是从这一步开始显现。主旨是：真正深入到你所阅读的整套代码的概念体系（组件结构）当中。这又是一个速度快不起来的步骤，但是在这一步，一定要尝试深入理解若干繁杂的细节。和第2步一样，在这一步，每次你多了解了一些上下文再回头看看，你的理解就更深入一些。

5. 前几步中肯定还有你不明白的地方，现在最合适的就是跑几个测试，看看已有的测试。测试很可能会大大打消你的疑惑，加深你对所测试代码的理解。我时常不能理解，为什么有些开发人员在阅读和理解代码时，忽略严密而精巧的测试套件。当然，也有时候是因为没有测试程序。

6. 如果没有测试程序，这时候就该写上几个。这样做有很多好处，它会加深自己的理解，它可以完善整个代码库，在阅读代码的时候也在写代码，这样对已有代码和你都有好处，你也可以真正动手参与进去。即便有现成的测试程序，为了加深自己的理解，你也可以再写一些。测试人家的代码，一般要求换个角度思考，之前你感到迷惑的概念也会变得更清楚。

7. 把弄不懂的部分拿到单独的程序中来。我发现，读代码时这样做，哪怕只是为了调节阅读的节奏，也是非常有乐趣的。即使你不理解代码的底层细节，也可能会对代码的功能有些高层面的想法。那为什么不把一些功能抽到单独的程序中测试呢？如果只运行一小段程序，debug就容易多了，而且这样的过程反过来又会加深你的理解。

8. 代码很乱（dirty）很糟糕（smelly）？那么重构吧。我可不是建议你把整个代码库推倒重来，但是重构一些部分确实可以让你的理解更上层楼。一开始要做的是把你明白了的功能变为独立的函数。在你真正理解之前，重构之前的函数只是看起来没问题，而重构可以把它们变成你想要的样子。依靠重构，你可以把代码变成自己的，而不要全部重写。好的测试程序可以帮上忙，不过如果你没有，就一边测试一边重构吧，而且只改动那些你确认弄懂了的功能。即便测试看起来太少太不完善，也要相信你自己的开发水平，有时候你只管大胆尝试就好（如果确实需要，总是可以回退(revert)的）。

9. 如果上面说的都不管用，就找个同伴跟你一起读代码。能从读代码中受益的可能并不只有你一个人，所以不妨抓住其他人，一起阅读。不过别找专家，他们给你的解释都是高层面的，这样看代码时注意的那些细节就都被忽略了。如果找不到人一起阅读，你又实在看不懂，有时最好的办法就是问别人。可以问你的同事，如果你在读的代码是开源的，也可以在网上问问其他人。记住，这只是最后的办法，不要一开始就这么做。

如果时间很紧张，短时间内必须弄懂某些代码，上面的步骤中只能选一步，我会选择重构（第8步）。你可能没法明白太多东西，但你肯定可以理解真正动过的部分。无论时间是不是紧张，你要记住的是：如果你第一次接触重要的代码库，肯定不能一下子就看懂，甚至不可能很快看懂。你可能需要耐心读上几天，几周甚至几个月——坦然面对就好。即便有专家坐在你身边，也省不了太多时间（我写的关于教和学的系列文章最后一篇就会谈这个问题）。如果你读（或者写）代码的耐心足够，方法得当，你肯定能成为对项目所有方面都非常熟悉的人，也是大家对代码库有问题时出面解答问题的人。你也可以不阅读代码，选择成为那个总想找人来解释的家伙。我想要做哪样的人，我自己很清楚。

抓住阅读代码的机会，别错过
我们都喜欢新写代码，它的诱惑力在于，我们能搞定问题。起码，这次搞不定，下次可以搞定。真相是：你在实践中不断提高，永远不可能一下就彻底搞定。这就是新写代码的价值所在，你在练习，你的水平在提高，但是阅读和改动其他人写的代码也很有价值（至少不亚于自己重新写），从中你学习到的不光是有价值的技术知识，还有关于整个工作领域的知识（毕竟，代码才是文档的最终形式），这种知识通常更有价值。

每一段不遵循传统的，莫测难懂的代码，都是有价值的。你知道我说的是什么，虽然它看起来一团糟，但本意并非如此（也可能因为它是Perl代码:)）。每次我看到这样的代码，我都这么想。不妨把阅读它当作猜谜游戏，想想你能学到什么。是的，这很折磨人，但必须承认，你也希望能动手就能写出这么糟糕的代码。如果你花时间阅读这样的代码，你肯定更可能写出这样的代码——这倒不是说，你一定会写这样的代码，但你肯定希望自己能够。最后要说的是，态度总是非常重要的。如果你把阅读代码看作闲杂事，那它就是闲杂事，而你肯定会逃避，但是如果你把它看成机会，事情就不一样了。

本文链接

知其所以然（续）

2011-02-03T14:06:00Z

查了一下，上篇知其所以然（以学习算法为例）是08年7月写的，现在已经是10年11月，过去了两年零4个月，这说明了三件事情：1，一个问题其实你可以一直放在脑子里面，利用暗时间对其软泡硬磨，时间足够久你总会有一点新的感悟，问题其实就像那句老话说的那样，不怕贼偷就怕贼惦记，聚精会神的思考一天，也许比不上惦记一个星期（据说数学家庞加莱就特别会惦记问题）。 2，事实上，当你感觉懂了的时候，你至少得反问自己一句，真的懂了吗？当你确信自己真的懂了的时候，你至少得讲给别人听，别人听懂了吗？考察你自己是否真懂了的一个很好的依据是，你是否有一种“哦，原来是这样啊，这下再也不可能忘记了”的感觉。3，我其实没有忘记这个博客。如我之前说的，记录只是学习和思考的副作用，只要还在学习和思考，就必然会有新的记录。

我有一个习惯，看定理必看证明。一个你不明白其证明的定理在我看来比不知道这个定理还要糟糕，因它给你造成一种懂了的错觉。在没有明白背后的证明之前，任何一个定理对你来说都是等价的——等价于背乘法口诀（只不过有的长一点有的短一点）。一个原本美妙的定理，把其证明扔掉就是真正的买椟还珠，暴殄天物。

从现实意义来说，去理解一个定理的证明会带来巨大的好处，首当其冲的好处就是你很难再忘掉它。这一点其实很容易解释——在理解一个定理的证明之前，定理对你而言是一堆没有内在联系的词句，而在理解了证明之后，定理就归约为证明它所需的条件加上逻辑，“逻辑”本来就存在于你的大脑里面，而证明的过程中除了公理和用到的常见定理（往往没几条）之外，宽泛地说，需要你去记的，一般来说也只有一个或两个关键的insights，也就是我们常说的证明中的神来之笔，比如几何证明里面的某条看上去莫名其妙的辅助线，一旦你知道了这条辅助线，那么整个证明就毫无难处，那么该定理的信息量便直接缩减为一条辅助线的信息量；虽然看上去这一步信息并没有缩减多少，但是如果你考虑到类似的辅助线不仅会用在这个特定的定理上，往往会在很多地方用到。很多关键的证明手法是通用的。那么其实你就是把所有以这个辅助线为关键证明手法的定理的集合的信息量归约为了这条辅助线。如果你进而甚至能够理解了作这条辅助线的思想精髓，那就更牛逼了，因为解决问题的思路更具有一般性，理解了寻找正确的辅助线的思路，你就根本不需要去记得某条特定辅助线的作法，你就把所有以作一条或几条辅助线为证明核心的定理的集合的信息量归约为了这个“寻找辅助线的思路”。

这是一个树状的知识结构，越往上层走，需要记忆的节点就越少。所谓触类旁通者，其实便是因为他擅长去理解解法背后的更具一般性的东西。所以我还有一个习惯，就是看到美妙的证明和解法总是会去一遍又一遍的去反复揣摩，试图理解想出这个证明的人到底是怎么想出来的，有没有什么一般性的方法可循，很多时候，在这样揣摩的过程中，你会理解到更深刻的东西，对问题性质更深刻的认识，对解决问题的思路更深刻的认识，这些认识不仅对于你理解当前这个定理或问题有极大的帮助，同时也有助于你解决以后会遇到的表面不同但本质一样的问题。

与看定理必看证明类似，看一个问题的解法，必然要看解法所诞生的过程，背后是否隐藏着更具一般性的解决问题的思路和原则。否则一个解法就只是一个问题的解法，跟背口诀一样。即便记住了也无法推广，即便当时记住了也容易遗忘。

举个经典的例子：每本算法书都会讲动态规划，每本讲动态规划的书都会讲背包问题，每次讲背包问题都会讲可重复背包和01背包，我们就拿《Algorithms》这本还算不错的算法书对背包问题的讲解来说吧，重复背包问题的递归公式是这样的：

K(W) = max { K(W-Wi) + Vi : Wi <= W }

这个公式的理解倒是很简单：为了把问题降阶，我们在最终的最优解里面去掉一个元素，对这个元素的可能性进行讨论，它必然是任何Vi之一（前提是Wi <= W，否则就装不下），而在去掉这个元素之后，剩下的元素肯定构成问题 K(W-Wi) 的最优解，于是递归关系出现了。

此外也可以这样来理解：要拿一组最优元素，那么总得开始一个个拿吧，对第一个拿的元素进行讨论，而问题的最优解等于讨论的各个分支的最优解中的最优者；如果拿掉Vi之后，剩下来要怎么拿才能最优呢？这就是一个 K(W-Wi) 的问题了。

01背包问题就大不一样了——每个物品都只有一件，拿掉之后就不能再拿了。我们不妨看看重复背包问题的解法是不是能用到01背包上呢？还是讨论第一个拿的元素，设被拿掉的是第i个元素，问题就归结为把剩下的物品（注意，可拿的物品少了一件）最优地装入容量为 W-Wi 的包里，所以，问题的参数便变成了两个，一个是背包剩余容量 W-Wi，另一个是剩余可拿的物品集合 S\{i} （表示去掉i之后的子集），显而易见第二个参数是物品集合的各种可能的子集，那么其可能性个数就是 2^n ，这就导致子问题的个数是 2^n，由于要依次计算每个子问题，那么算法复杂度显然也是 2^n ，是不可接受的。

那么，《Algorithms》上又是怎么来讲解01背包问题的解法的呢？以下是原文：

Our earlier subproblems now become completely useless. We must therefore refine our concept of a subproblem to carry additional information about the items being used. We add a second parameter, 0 <= j <= n: K(W, j) = maximum value achievable using a knapsack of capacity w and items 1..j: The answer we seek is K(W, n).

首先作者说了，之前重复背包问题的解法在这里完全废掉了，所以我们必须重新定义子问题，并且子问题的条件必须要包含目前拿剩下的物品。以上这些都还不错，关键是接下来就让人吐血了。作者接着说道，我们给子问题加上一个新的参数j…

凭什么啊？

还是让我们回顾一下这样一幅经典的漫画吧：

“我们给子问题加上一个参数j”，这就像你在看数学证明时看到无比邪恶的“我们考虑…“一样，一看到这样的句子，你就知道，这个问题的证明远远不像看上去那么简单，之所以你一路看下去理解上全无困难，那完全是因为作者直接把最重要的一个insight告诉你了，举个很简单的例子，证明素数无最大，谁都会第一时间想到去反证：假设存在一个最大的素数P，那么找到比P大的素数就是证明中最关键的一步，怎么找的？一般书上是不会说的，你会看到书上这样说：假设P是最大的素数，那么我们考虑P’ = 小于等于P的所有素数的乘积+1。那么P’一来显然大于P，二来不能被小于它的所有素数整除，那么P’就成了大于P的素数。

如果你经常注意反证法，你会发现一个有趣的现象，反证法里面经常会有这样一句“我们考虑”，而“我们考虑”后面几乎肯定接着一个天外飞仙一般的 insight。素数无最大这个古老的证明里面的“我们考虑”尚算是比较有迹可循的（我们想要构造一个更大的素数，而素数的等价定义就是“不能被小于它的所有素数整除，为了达到这个目的，构造的方法就较明显了）。但是有非常非常多的证明，其中关键的一步就跟嗑药磕出来做梦做出来走路跌跟头跌出来的一样（不信去翻一翻《Proofs from THE Book》），让你完全不知道他怎么想到的。

话说回来，虽然有很多数学证明的关键步骤是很难逆向工程的（因为很多时候想出那个关键步骤的本人其实也是尝试了各种方法，撞了无数堵墙，在寻求证法的尝试空间中作了N次回溯才“妙手偶得”，与其说是妙手偶得，不如说是绞尽脑汁），但并非全无章法可循，否则陶哲轩也不会写出《Solving Mathematical Problems》这样的著作来，而求解问题也就成了真正的Black Art了。

算法的解法则比精妙的数学证明稍加更容易逆向工程一点。只要你有耐心仔细地去琢磨算法的关键步骤和本质，总能从中窥探到一些更general的思想和思路来。

此外，很多经典问题，算法书上的讲法虽然时时令我们失望，但如果去网上一搜，则通常会发现更优秀的解释来。比如背包问题就是如此。

简单地说，如果你对于每个问题都能真正弄清以下这几个问题的答案，那么可以肯定的是，你的理解，记忆，以及学习的效率都会得到质的提高：

为什么这种解法是对的？
为什么那种解法是错的？
为什么这种解法不是最优的？
证明为什么没有更优的解法。

回到人民群众喜闻乐见的经典例子：背包问题。为什么01背包问题的正确（高效）算法是正确（高效）的。表面的解释是，因为01背包问题的子问题定义是 K(W, j)，其两个维度相乘的可能性一共有nW种，也就是说一共要计算nW个子问题，而计算每个子问题的复杂度是O(1)的。

但是如果仅仅满足于这样的解释，可以说是隔靴搔痒，并没有触及到本质。算法本质上可以看做是在一个解空间当中的搜索问题，所以要分析一个算法的好坏，首先弄清它的解空间的结构，然后分析它是怎么来探索这个解空间的。

弄清解空间的是第一步，例如排序算法，其解空间可以看做是所有可能的下标排列组合，其中有且仅有一个排列是正确的排序排列（简单起见假设元素各不相同）。那么一个算法在探索这个解空间方面的行为就决定了它的效率高低，最简单的，如果一个算法每次只能检查解空间中的一个点，那么这个算法的复杂度就是解空间的大小。对排序算法而言也就是n!。从这个角度来看，我们就会很容易的发现，所有基于比较的排序算法，其复杂度为什么是以O(nlogn)为下界的，因为一次比较操作最多有两个结果，a>b或a<b，既然只有两种结果，那么最多只能将解空间进行2分，如果每次都能完美的2分，那么找到那个唯一点最终需要的步骤就是log(n!) = O(nlogn)。如此就不难理解什么基于比较的排序算法的复杂度最好不过如此了。

回到01背包问题，01背包问题的解空间其实也是类似的。一次选取就是一个01数组，其中每个元素代表其所对应的物品要不要选取。很显然，这个解空间的大小是2^n。在01背包的算法里面，每当我们解出K(W, j)（需要O(W)次计算）之后，解空间就会被折半（排除掉1/2的可能性），一共如此做n次，就能得到最终解。由于每次折半的代价是O(W)，便不难理解为什么算法复杂度是O(nW)了。

那么，为什么每次计算出K(W,j)就能使解空间折半呢？那就需要来看看这个算法是如何探索解空间的，算法探索解空间的方式在其递归公式里面：

K(W, j) = max { K(W, j-1), K(W-Wj, j – 1) + Vj }

也就是说，首先看你要不要选取第一个物品，有两种可能性（两个分支），每个分支都是一个更低阶的子问题，即在其中的任意一个分支下都要决定要不要选取第二个物品（又是两个分支），如此下递归去，可以构建出一棵有2^n方个叶子节点的树，每条从根结点到叶子节点的路径“01..101”就对应一个解，其中每个分叉代表“选”或“不选”当前的物品。

建立在对这个解空间的理解上，我们再来看为什么01背包问题的正确解法能做到O(nW)。（首先你最好将这棵树画在纸上，其中每个节点都是一个子问题K(W,j)，每条分叉都是0或1。）当我们计算出所有的K(W, 1)（需要O(W)次操作）之后，我们容易注意到，所有离叶子节点的距离为1的内部节点K(W, 2)到叶子节点的两个分支都必然只能取其一了，也就是说，有一半的叶子节点被排除掉了（对解空间折半）。当我们进而计算出K(W,2)之后，同样的道理，我们容易看到，到叶子节点距离为2的内部节点的两个分支也只能取其一了，这就进而再次将解空间折半。由于每次折半需要O(W)的复杂度，所以就不难理解算法的总复杂度为O(nW)了。另一种理解的方法是，当我们计算出K(W,j)的时候，从内部节点K(W,j)到根节点的唯一路径便确定了。经过O(nW) 次计算，从根节点到那个唯一解（叶子节点）的路径便完全确定了。

知道怎么做是从正确（高效）解法得到的，而知道为什么必须得那样做则往往是从错误（低效）的解法当中得到的。

然而遗憾的是，绝大多数算法书或教程都只顾一上来就告诉你正确的做法是什么，对于一些常见的错误解法，或者常见的低效解法，却根本不加分析。经验告诉我们，理解错误的做法为什么错误同样甚至更为重要，往往是在理解了错误的解法为什么错误之后，我们才能深刻的体会到为什么正确的解法是如此正确。

还是拿经典的背包问题来作例子，你几乎看不到哪本书会告诉你一个典型的低效解法为什么低效的深刻原因。我们都知道动态规划的核心在于子问题的划分，同样的问题，不同的划分办法得到的复杂度完全不一样。前面已经提到了，重复背包问题的思路在01背包问题上会带来指数级的复杂度，但是为什么呢？如果你满足于说：因为如果拿重复背包问题的思路来解01背包问题，那么子问题定义的第二个维度（物品的子集）（见前文）是指数级的，那么要计算所有子问题，当然是指数级的。那么你只是看到这个问题的表象。

如果从对解空间的探索方式来说，可以容易看出这个现象的本质，我们回顾一下01背包问题的正确（高效）算法：

K(W, j) = max { K(W, j-1), K(W-Wj, j – 1) + Vj }

这个算法讨论的是两种情况，“要”或者“不要”选取第j个物品，这两种情况所对应的解空间是完全不交的，这就有效地将解空间划分为了不重复的两个部分。

而再来看利用重复背包问题思路的解法：

K(W, S) = max { K(W-Wi, S\{i}) + Vi : Wi <= W }

这里讨论的是首先拿掉哪一个物品，还是那句话，讨论的每一个分支都对应了算法对解空间的一个切分，我们容易看出，在“先拿物品i”和”先拿物品j “这两个分支里面，存在大量的重复，因为先拿物品i再拿j，和先拿物品j再拿i对应的是完全一样的一组选取。事实上，如果你将这个递归公式画成树状结构，会发现有n!个叶子节点。n!是什么概念？01背包问题的解空间大小本质上就只有2^n次方，穷举也不过O(2^n)的复杂度，结果这样一切分却变成了 n!，可见这种对解空间的切分方法的冗余度是多么高了。你不妨看看，每一次计算K(W, S)子问题能对解空间排查多少呢？是否能像前面正确的算法那样，每次都能有效排查一半情况？理解了这一点之后，我们便注意到在划分解空间，也就是定义子问题的时候的一个原则，就是在建立递归公式的时候，尽量将解空间进行不交的切分。同时我们便有了趁手的工具去分析一个动态规划的解法的效率。

最后再举一个例子：算法书上几乎必讲的霍夫曼树。你所看的算法书在讲霍夫曼树的时候给了证明吗？讲过霍夫曼树的历史八卦吗？也许你看了霍夫曼树的构造方法之后觉得：“哦，这样啊，显然”。但是你可曾想到，在最优编码这个问题上，连香农本人之前给出的解法都只是suboptimal的，而且霍夫曼本人在得到这个算法之前也是绞尽脑汁几近放弃。如果你10分钟就“理解”了，那么百分之百只是背了课文而已。

本文链接

我与比尔•盖茨的三分钟

2011-02-03T13:58:00Z

2010 年9 月26 日下午，微软公司前主席比尔·盖茨先生微服私访了微软亚洲研究院。研究员和实习生们紧密合作，纷纷拿出了自己的“看家项目”向比尔·盖茨做展示，并期望请盖茨“指点迷津”。

其中，最激动也最紧张的莫过于有幸参与这次活动、零距离接触盖茨的实习生代表们。三周前，他们在毫不知情的情况下，被告知要在导师的帮助下为所负责的项目准备demo ，并将于9 月26 日展示。但，直到展示前的最后一刻，谜底才被揭晓。当洪小文院长告诉实习生们“比尔·盖茨明天要来看你们的demo ！”时，所有人都被震惊了，兴奋之情难以抑制！

尽管每个人只有短短的三分钟时间和盖茨一起探讨项目，但是他们无不被这宝贵的经历所深深的鼓舞。下面，就让我们一起来听听他们与比尔·盖茨零距离接触后的精彩感想吧！

感想一：台上三分钟，台下三周功

作者：丁铎

项目名称：Engkoo 英库（微软“必应词典”前身）

9 月5 日那一天，我的导师Matthew Sco tt 让我准备一个关于我们Engko o 项目的demo ，预计在9 月26 日展示，并且说非常重要。当时我感到十分困惑：“这个demo 究竟有多重要需要我们用3 周的时间来准备？”

虽然带着疑问但我还是十分认真地准备了起来：我起草了3 份不同的海报，4 份视频demo ，并就演讲稿与Matt 进行了反复讨论。在9 月19 日的首次彩排上，我见到了微软亚洲研究院院长洪小文博士，他竟然出现在那里帮助我们准备demo 的预演。我顿时感觉到9 月26 日那个来参观访问的人一定是一位比我设想的还要重要的超级大人物，但我同时也明白我更需要继续准备demo ，并在那一天以最好的姿态展示Engkoo 项目。

谜底直到最后一刻才揭晓，9 月25 日，洪小文博士告诉我们比尔•盖茨要来了！我们一方面感到深深的惊讶，另一方面又无比兴奋，开始期待这一天的到来。

在展示demo 的那一天，我和我的老师提前一个小时到场预备着。终于，激动人心的时刻到来了，比尔•盖茨和我们许多其他的研究员，包括洪小文博士、Harry （沈向洋）博士还有张亚勤博士等一同来到了我的项目前。当看到比尔•盖茨面带微笑向我走来时，我的紧张和兴奋一下子减少了很多。他用眼神亲切地和我交流，并且对我所说的每一个字都予以高度的关注。知道这样一位高级别、高知名度的大人物对我所谈论的事物十分感兴趣，实在是一种难以描述的美妙感觉。同时我也告诉自己要镇定，一定要成功地展示Engkoo 项目，因为它是很多人辛勤工作的成果。我流畅地进行着演讲，并不时停顿一下，看看盖茨的反应。当看到他点头微笑时，我知道他明白了刚才的内容，于是继续讲下去。

演讲结束后，盖茨问了一些有关Engkoo 项目的问题。虽然已经不搞技术很多年，但他提出的问题仍然相当细节，比如我们的视频是如何合成的，我们的数据alignment 如何实现等等。这一点确实非常让人敬佩。之后他还问到了Engkoo 是如何与bing 合作来推进比应词典等产品在中国的发展。当他得知Engkoo 获得Wall Street Journal 2010 亚洲创新奖“读者之选大奖 ” 时，不禁用“super dictionary,” “fantastic” 和“great work” 等词语对其进行了赞扬。

回想这次经历，对我、我的导师、Engkoo 团队以及整个微软亚洲研究院而言，都是一份巨大的荣誉。相信这份美妙的经历一定会在我人生中留下一段特殊的回忆。

感想二：神奇的经历

作者：来自MIT 的越南实习生Anh D. Nguyen 战略技术组实习生

项目名称：My Life – a Windows Phone 7 life-style walking application

对我这样一个从河内前往麻省理工学院，又接着来到北京微软亚洲研究院做VI-A 实习的越南学生而言，这毋庸置疑是一段十分特别的经历。哇，一想到我很快就能和比尔·盖茨见面，实在是太神奇了！

演讲前一天晚上，我10 点就入睡了，这对一个麻省理工学院的学生而言，绝对算早。一睁眼，哈，去见盖茨的时间到啦！我是第五个发表演讲的学生，在我之前还有4 名学生以及他们的导师。当比尔·盖茨在听别的学生演讲并发表一些智慧的见解时，我不禁透过房间好奇的观察他，这一刻，这位显赫的大人物与我是如此之近。

当轮到我的项目时，我首先向他打招呼：“你好，盖茨先生，我是来自越南的Anh ，现在是麻省理工学院的一名学生。”接着，我赶紧抓紧时间介绍我的项目，我的手臂不由自主地上下挥动着，配合着阐述软件的独特设计特征，一个单词、一个单词清晰顺畅地从我的嘴里蹦出来。

另外，由于之前对这些项目接触较多，我得以有时间观察人们听讲时的反应。令我欣喜的是，每个人的眼里都透露出对这个项目的浓厚兴趣，盖茨也聚精会神的倾听到演讲的最后。他还问了我好几个问题，例如一些可能的特征以及我何时完成并发布这款软件的计划，我的快乐并未到此结束，他竟然给予了我宝贵的建议并且肯定了我在应用设计中许多有创意、有价值的想法！这实在太令人振奋了！

感想三：不可思议的任务

作者：段亚娟自然语言计算组的实习生

项目名称：Quickview

早上进公司，气氛有些不同寻常，不由地有些小紧张。今天盖茨来访，公司里组织展示一些研究项目给他看，组里有一个，我负责讲解，这个项目是做social network 的信息挖掘的。从来只在照片中见过其人，不知真人如何。微微有些忐忑，宗师级的人物，又享有技术天才的美誉，什么样的讲解才能引起他的兴趣呢？

下午，提前在展台前准备好。不久，开始了，出乎意料地，讲得异常顺利，比练习的时候讲得还好。讲完，提问，回答，离开，一切都进行地很顺利，绷紧的心放松了下来。想想在准备的时候，久久地纠结于如何讲清楚，如何讲得能够吸引人。看来，这种纠结效果显著，吸引人或许差得远，讲得清楚，的确做到了。深知自己不长于表达，更别说用英文，于是最开始的时候使用笨办法，写下讲稿使劲背，也许是因为不习惯用英文思维，不管背得多熟，讲的时候总有忘词的时候，后来，索性找篇喜欢的英文小说背，奇怪的是，小说居然能背得流畅。细想下，背小说的时候思维跟着情节走，读几遍，已记住情节，复述就变成了讲故事，于是试着把讲解变成讲故事，不求句句百分百与讲稿一致，拟定一个思路，顺着思路讲下来，用词随意，流畅许多。做展示的时候，除了盖茨，还有好几人在旁，气氛很好，让人放松，这也是顺利讲完的原因之一吧。

想想初接到这个任务时，觉得能做好简直是不可思议的事，不过终于做到了，轻松之余，亦有几许兴奋。

感想四：珍贵的一刻

作者：曹阳互联网搜索与挖掘组实习生

项目名称：MindFinder: Finding Images by Sketching

“来了来了…”

本来还在会场上各自忙碌的大家纷纷转过身，目光迎向那唯一的入口，期待着那位超重量级的大人物的到来。

我把demo 又刷新了一遍，确认一切OK 以后，赶紧盯住大家目光汇集的方向，生怕错过了这一历史性的时候。在亲爱的沈向洋先生的陪伴下，他步伐坚定地走了进来。尽管我只从各种媒体渠道上看到过他的样子，但我肯定是第一眼就认出来了，就是他了。那个曾经出现在我中学收到的一本开启我计算机之路的《The Road Ahead 》的封面上，意气风发地站在高速公路上的人，如今与我近在咫尺。

比尔·盖茨先生，终于见到您了。

只见他先走到了排第一的iClipArt 的台前，和她们热情地聊了起来。这时候，我很懊悔我怎么不是第一个讲的。也许等我还没有意识到自己有多紧张的时候，就已经顺利的把演示做完了。不过也不错，我能提前观察一下。果然如传闻中的一样，盖茨先生对学生非常友善，而且会不时地插入一些自己的想法和问题。我内心默默祈祷，但愿我提前准备的那些问答都够用吧…

其实因为是公司机密，我们都是昨天晚上才确认，是盖茨先生亲自要来检阅我们的demo 。回想第一次预演的时候，我刚到会议室，发现竟然是小文院长亲自坐镇。当时就暗自推测，小文已经我们研究院最高的level 了，那当天要来的，一定是非常难得一见的大人物了。联想起近日媒体上天天轰炸式报道的“巴比中国行”，难道，我就要见到微软的精神领袖比尔·盖茨了？不过，第一次预演我表现得不是很理想…因为临时改变形式，准备的一大堆slides 都不管用了，上台完全乱了分寸。现在想起来还很惭愧。小文给了我们很多有用的建议，其中指导方针就是“Talk Less，Show More ”。因为我们的系统 MindFinder 是一个非常容易理解的交互式图像搜索引擎，在仅有的几分钟演示时间内，我们大量减少介绍性语句，直接通过一个个case 来体现MindFinder 的功能和优点。在我的M entor 王长虎（Associate Researcher of Microsoft Research Asia ）和我们的组长张磊（Web Search & Mining Group Lead Researcher ）的悉心指导下，我又准备了一套新的演示方案。并且，在接下来的3 天中秋假期，我每天都抽出时间来，一边憧憬着，一边演练各种突发情况。周六（25 日）晚上7 点，最后一次预演，我来到了实际的场地，信心满满地给小文院长成功地演示了一遍。本以为大功将要告成的时候，小文又给我们提出了很多改进意见。其中包括，舍弃MindFinder 在clipart 数据集上所有的case ，从头到尾只用自然图片集。要知道，这已经是盖茨要来的前十几个钟头了。我又马不停蹄地修改了我的方案，甚至为每个case 都想好了应用场景和铺垫。因为所有的演示query 都需要我真刀真枪地用笔在触摸屏上画一个图形，我只能祈祷，但愿我们系统够robust ，但愿我的画功够好…

转眼间，盖茨先生已经从第二个演示台转身，径直向我走来了。我的心也提到了嗓子眼。不管那么多了，为了留下个好印象，我马上热情地向他打招呼。他也向我问好，并对我报以亲切的微笑。这时，心中的偶像——比尔·盖茨就真正站在了我的面前了。

接下来珍贵的几分钟里，我照着预定计划向他演示起来。现在回想起来，我都不知道自己是如何就突然冷静了下来。几个case 画得非常平稳，我们的系统MindFinder 返回的结果也非常的令人鼓舞。甚至中间还发生了一个小插曲，一阵子网页有点故障，我还当着他的面刷新系统，调试了几秒，让演示顺利地进行。（要知道，盖茨可是每秒赚几百刀的人啊…）轻车熟路地演示到最后，终于到最后一个环节了。尽管我无数次在演练中犹豫过，还是鼓起勇气，把画笔让了出来，对他说： “Do you want to try?” 要知道，虽然我们的系统已经做到领先的水平，但是用户随意涂画可表征的内容可比系统目前索引的2M 自然图片大无数倍啊！谁知道盖茨想画什么呢？虽然我准备了各种说辞，但是，效果不好还是很失望的吧。可又想，不让他亲自试一下系统，我们大概会非常遗憾的吧。盖茨先生在大家的注视中欣然接受了，拿起笔开始画汽车。画完之后还自谦地说，不大擅长绘画。盖茨真迹

还好，在我预想可控的范围之内。我马上建议他加一个tag 引入语义信息来改进，就得到了上图的结果（可以看出，盖茨确实不大擅长绘画… ）。虽然query 实在有点抽象，但是我们的MindFinder 还是非常争气地在找到了轮廓相似的图片。然后，我们又愉快地谈论了几个技术问题。（虽然我不敢说我们的system 给盖茨的印象最深刻，但我们一定是唯一一个让盖茨做user study 并亲自通过他认证的系统。）

目送他离开以后，磊和长虎马上高兴地说我终于可以松一口气了。是啊，3 个星期的准备，就是为了这珍贵的几分钟。

感想五：欢乐的展示

作者：吴中视觉计算组实习生

项目名称：simFace: Web Facial-Image Search

开始接到通知要做这么一个demo 时，老实说并没有太多感觉。当时所知道的也只是要在某天用我们做的项目做个demo 而已，对谁来讲、对谁讲、讲多久等都没有概念，第一次排练的时候也没有做什么准备，基本就是上场即兴发挥。后来看到lead 们为了这件事安排了好几次演练，尤其每次演练小文都亲自到场指导，我才隐约地感觉到这个事情的重要性，开始重视和认真准备。

第一次给小文演示demo 时，我还没理清整个演讲的条理性。由于缺乏练习，对演讲时间把握的也不好，以至于花了很多时间在介绍不必要的技术细节上，没留给实际demo 多少时间。虽然演讲得磕磕巴巴，但台下小文还是很nice 地给出了不少改进建议和鼓励。针对这些问题，回来后我的Mentor 袁路对我进行了“特训”。我们一起根据Poster 的内容组织语言，挑选以供实际demo 时用的图片素材，并跟我一起反复演练，以达到对时间的最好控制。练习过程中，袁路还指出了我一些演讲时自己没注意到的下意识动作，比如紧张时把鼠标在屏幕上乱晃、眼神飘忽等问题。闲暇时，同一个demo session 里的同学之间也会交流一下做演讲的经验。比如有位同学告诉我，根据他的经验，练习的时候不要把整句话写到script 里，而应该只放一些能给自己提醒的bullet ，不然就很容易把演讲变成语调和表情都不自然的背书。

传说中的神秘“重要人物”终于在最后一次排练中揭开了神秘的面纱。小文告诉我们，第二天比尔·盖茨会来看我们的demo ！虽然之前坊间就有不少猜测，但这个消息得到确认时，我们还是着实激动了一把。

我们做的demo 是人脸图片搜索，为了配合比尔·盖茨的到来，我们还专门去网上找了一些盖茨的照片，作为明天demo 的素材。

展示当天，我们下午2 点就到5楼longue 设置机器、待命、并各自进行最后的演练。大概下午3 点多，盖茨在沈向洋、小文、亚勤等lead 们的陪同下出现在5 楼longue ，带着他招牌式的笑容。或许是盖茨和蔼的笑容和向洋公布旁边一个实习女生的新婚信息所带来的欢乐效果，在融洽的气氛里我们都不怎么觉得紧张了。

当盖茨来到我的Poster 前面时，我熟练地跟他介绍了我们的工作。过程中他一直面带微笑的听着，尤其是当看到用他的照片搜索出来的一些有趣结果时。demo 结束后，盖茨还提出了不少关于如何把这项技术整合到微软产品中的一些看法和建议。

最后，我们还集体跟盖茨合了影。回来后我们都说，希望尽快拿到这张合照，好保存下来作为以后在任何场合的炫耀资本。

欢迎关注微软亚洲研究院微博 ： http://t.sina.com.cn/msra

本文链接

一言难尽话PHP，兼谈我的编程经历

2011-01-18T09:48:00Z

转自：

http://liut.cc/blog/2010/04/all-about-php.html

有一个人，这个人我已经不记得他的相貌和姓名，但是他曾经影响了我。99年的春天，联想开始做公共网站，我虽然主要工作是做设计，但其实我的兴趣在技术上，喜欢自己找些Perl（当年的CGI程序多数是Perl的，自己在学校学到的那不足千行的C还不知道怎么用在Web上）的留言版或聊天室程序改改代码和界面，用在一个叫“幸福之家”的土得掉渣儿的网站上。大约在秋天或年底的时候，这个据说是北大（也可能是清华）的学生来帮忙做兼职开发新闻系统。我经常正事儿不干，看着他写代码。他的主要开发方式就是连接到服务器上打开Vi开始写。那时我虽然也在Solaris用过VI，但还只会移动光标和保存之类的简单操作，而且并不习惯。这样完全用VI开发还觉得比较新奇。那是我第一次接触PHP，那时的版本是3.0，所以他写的文件扩展名全是.php3。我负责前台的界面和样式，偶尔打打下手写点儿代码。这样边写边测试（完全正式线上服务器环境，现在想想那时真无畏），大概用了一周时间，一个基本的新闻管理系统就上线了。就这样，我也就开始了我的PHP生涯。

这个新闻管理系统运行了不到半年后，就被联想研究院的同事完全用Java重写。我也在合作期间偷偷学了点儿Java语言和 EJB的皮毛。而这位年长于我一两岁的同学，就此失去了联系，不知道他现在在做什么。问题是，我真不记得他叫什么，也没有联系方式，好像我俩都很内向，不问彼此，真是一对奇怪的年轻人。

在离开联想之前，我用PHP写过几个小项目，我现在还记得有一个广告维护和更新系统，主要功能是广告管理、图片上传、和html文本块编辑等。由于之前有研究过Perl的代码，加上一些C的基础，让我对PHP这个脚本语言真真的喜爱有加。你想想看，那个年月，有哪个Web脚本有如此丰富的扩展又有这么简单易学的代码。什么数据库操作啊、图像生成啊——我甚至用它的GD库实现了饼图显示投票的结果（当然饼图的生成算法是抄来的）——、文本操作什么的，好多的扩展，包括数不清的和风格不一的命名，它实在太容易学了，也太好用了，语法自由，又没有像Java那样的强类型约束，我对它实在是爱不释手，这可如何是好哇。后来的几年也确实是PHP高速普及的时期。

联想当年做的那个网站，用的数据库几乎全是Oracle，而且跑在Sun的服务器上，据说还有光纤阵列啥的。多年后有人告诉我，由于无人打理，域名被人抢注了，我记得当时我的心情平静的。据说抢注 FM365.com 的人后来做了个叫 265 的网站。

02年和同样是联想出来的两个朋友去了北大附中网校。当时在线的是ASP环境。那之前还没用过ASP，写了一些模块，发现和PHP差距较大，如果不用Com，很多想法较难实现。这里再啰嗦两句，ASP支持两种语言：VBScript和JScript，我实在是不喜欢VB的语法，后期写的模块我都尽量用JScript实现。而且，JScript支持一种类似Hashtable的Dictionary对象，操作字典类数据很方便。不过，总得说来，ASP还是太弱了，如果PHP是把多功能军刀，ASP只能算是生锈的水果刀。

人的思想是会变的，人又总不满足于现状。约一年后就将整个系统逐步升级到.Net。第一次用C#发现和Java很像，也是第一次开始试着用分层的概念设计系统架构。在这期间的同事有霍炬和戴飞。经常在去饭馆的路上还在和火炬讨论是分三层好还是四层好。

霍炬对我的帮助和影响又更多些，他还送了我两本书《设计模式》和《C++Primer》（前者到是时常翻阅，后者较厚，没怎么看，几次搬家都想扔了）。

坦率的讲，C#真是门集众家之所长的好的语言，相较于PHP这类脚本语言，又足够OO和足够完善。PHP和它相比，实在是太土妞了。加上刚接触到设计模式——这个东西就像火炬说的手里有把锤子就会发现到处都是钉子——这么个超级大锤子。所以我那段时间像同时沉迷两样东西，一个是WoW(还在公测貌似)，一个就是C#。我能从写大段脚本和无数子过程学习并过渡到对象开发和多层架构的设计，这得感谢C#和.Net。

在网校做的最后一个项目是个多用户Blog系统，基于b2的开源改造，又重回到了PHP的怀抱。虽然从个人角度我非常喜欢C#语言，但我仍对Windows平台没有信心（那时Mono还是个实验项目）。

大约04年的时候，或许是受Java的影响，PHP社区也出现了一些开发框架，如CakePHP、Zend Framework、CodeIgniter、Symfony…。但是，在看了这些框架并做了些测试之后，我限入了纠结之中。Cake和其他几位还稍好，最变态的就是Zend，几乎完全模拟强类型语言（如Java），完全的用OO方法设计模块和类。方向和庞杂度直奔Java的屁股而去。

PHP真的要这么写吗？这和Java和.Net有什么区别？这还有PHP的优势么？看烦了各个论坛各种框架之间的口水战。为了防止可能继续误入歧途，我逃离了这些豪华巨轮。但是我限入了迷惘，我要再怎么写的PHP呢，我似乎失去了方向。我各类在各类开源项目和书里寻找答案。随着几次失败的项目和工作单位的变动，思想也有较大的变化。后来的两年多时间，较少关注社区的动向，按照自己对Web开发和结构分层的理解，写一些适合自己用的基础库，谈不上框架，用着倒也趁手。

我也有接触和学习其他的新的语言和框架，例如Python、Django、Ruby。其中Python的语言特性让我很着迷，这是我见过的第一个把清晰（或者说整洁）度作为语法规则一部分的编程语言。也许是我本人爱干净，也许是我的想法变了，我甚至觉得Python的语言哲学：“There should be one– and preferably only one –obvious way to do it.”（有且仅有一种明确的实现方法），是非常完美且正确的理念。我回过头再审视PHP满身的伤疤和陷阱，不禁要问：PHP是不是进步的太慢和太不思进取了。为什么会这样呢？

这里又要感谢一位同学，几年前某天在西南三环某处租房里，郝培强送了我一本Python入门（也可能是我拿在手里一直不放下的原因），那时他还单身，还很纯情，大家在聊着对未来的憧憬和各种的梦想。

就一种语言来说，PHP易学易用，几乎不需要什么基础和背景，适合各类人群（比如被大家臭骂的北大青岛的毕业生），只是代码的质量差距较大而已。然而，人不可能永远在初级状态，人是会成长的，用得越久，越是能感受到它的局限。

前段时间看到有人说PHP很烂，虽然这话难听且观点很武断，但他文中所说的PHP特性包括引用几位老外的观点又都是事实。比如这个，还有这个。

我的朋友老王说，“语言不重要，重要的是思想”，这话不错。但思想的获得何其难，它需要一段时间积累加上一些天分甚至还需要有一点点机缘才能灌输到人的脑子里面。为了实现高质量和可控的代码，我需要写几十页纸的约定和规范，并且还要定期Review，要不然就等着数不清的地雷哪天突然被踩中吧。影响生产力因素有多种，有人的因素，也有语言和工具（包括平台）的因素。如果一种语言可以很容易的实现清晰、明确和严谨的高质量代码，而另一种语言则需要数年经验且小心小心再小心才能达到同样的质量要求，孰优孰劣，似乎不难判断。

其实俺又是个重感情的人(:D)，这么多年一路陪俺走过一个沟又一个坎儿，今儿使劲说嫌弃的话，心里怪不是滋味的(:S)。

现实会给人一些安慰。有数量众多的人用PHP，也有大量的网站运行其上，PHP在实事上占有一席之地。一切在变化中，结局还未可知。

Update：
关于开发速度的问题，要看具体针对的业务需求。PHP由于有大量开源项目（且不论其质量）可以参考使用，加上人力成本相对较低，可以很容易在短期内部署一个适应多种类型的小型网站，确实会比Java要快些。然而，但是，根据前面的描述，你知道我要说什么，你需要有至少一个最好是多个有非常丰富经验的人来控制架构和设计，否则的话，随着用户和访问量的提升，一定会遇到技术上的瓶颈。这些都是有现实教训的例子的。

本文链接