它的发明者Linus Torvalds，知道的人就更少了。

他本人也很低调，深居简出，很少出席公众场合或接受媒体采访，通常只在专业开发者的邮件列表中发言。提起他的名字，人们的第一反应往往是"哦，传说中那个22岁就发明Linux的芬兰大学生……"，其他就一片空白了。

他的自传《Just For Fun》出版于十年前（2001年），已经几乎被遗忘了。

星期六下午，我在硬盘里偶然翻到这本书（中译本），不经意地读了第一页。Linus Torvalds正在谈他的写作计划：

"我们可以在第一章里对人们解释生命的意义何在。这样可以吸引住他们。一旦他们被吸引住，并且付钱买了书，剩下的章节里我们就可以胡扯了。"

我觉得有点意思，接着往下面读。他继续谈生命的意义：

"人类的追求分成三个阶段。第一是生存，第二是社会秩序，第三是娱乐。最明显的例子是性，它开始只是一种延续生命的手段，后来变成了一种社会行为，比如你要结婚才能得到性。再后来，它成了一种娱乐。"

我心里嘀咕，这个理论有点离经叛道啊，不过看上去似乎有道理。但是，它跟Linux有什么关系呢？

"技术最初也是为了生存，为了生存得更好。现在技术大体上还处于社会的层面，但正在朝娱乐的阶段发展。……（Linux的开发模式）为人们提供了依靠兴趣与热情而生活的机会。与世界上最好的程序员一起工作，是一种无与伦比的享受。"

我被吸引住了，整个周末都在读它，越读越入迷。此书极其有趣，一点不枯燥，充满了各种好玩的笑料，以及对技术和软件的严肃思考。如果你是一个程序员，我高度推荐此书。

我从没料到Linus Torvalds是一个如此幽默有趣的人，我摘录了一些他的妙语，请大家欣赏。

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

1. 关于幼年

"出生后，我的摇篮是一个洗衣筐，幸好我沒留下什么记忆。"

2. 关于外貌

"我有一个祖传的大鼻子，据说眼镜可以让鼻子显得小一点，于是我就带上了，任何时候都不摘下来。"

3. 关于姓氏

"我祖父发明了自己的姓，全世界现在总共有十八个姓Torvalds的人，他们之间都有血缘关系，都得忍受我祖父带来的这种混乱。"

4. 关于服装

"我从小不太讲究穿衣，长大后，又突然要由别人来决定我的穿衣，这些人主要是某些高技术公司的销售人员，我就穿他们在会议上免费发送的T恤和夹克。"

5. 关于成长

"妈妈对她的一些朋友们说，我是个非常好养的孩子。她只要把我放在一个黑咕隆咚的储藏柜里，再配上一台电脑，偶尔朝里扔一些意大利面条，我就会感到格外高兴了。她的话不无道理。"

6. 关于入伍

"在那里手拿武器，上了一个月的操练课后，我便觉得有生之年完全有资格从此一动不动，享受平静的生活了。惟一可做的事情就是在键盘上打代码，或者手里端着一瓶啤酒。"

7. 关于退伍

"我的服役期在1990年5月7日结束。我妻子会告诉你，我连我们的结婚纪念日都记不住，但我却不大可能忘记我离开部队的日子。"

8. 关于芬兰人

"芬兰人有沉默的传统，人人都沉默寡言。他们常常站在一起，但一句话也不说。德国作家布莱希特二战时曾在赫尔辛基住过一段时间，他在描绘火车站一家咖啡馆里的顾客时曾说，那些人"会讲两种语言却沉默不语。"所以后来他一得到机会就逃出了芬兰。"

9. 关于诺基亚

"既然芬兰人不喜欢面对面地交谈，整个国家就成了移动电话最理想的市场。"

10. 关于打工

"我一贯喜欢室外运动，曾经一度当过邮差，但送的不是报纸而是垃圾邮件。"

11. 关于暑假

"那年夏天我做了两件事。第一件事是什么都没做。第二件事是读完了719页的《操作系统：设计和执行》。那本红色的简装本教科书差不多等于睡在了我的床上。"

12. 关于赫尔辛基大学

"学校为VAX微型机买了16个使用许可，但是却规定《C语言和UNIX》课程的选修人数为32名。我想学校的想法是16个学生白天使用机器，另外16个学生晚上使用。"

13. 关于理查德·斯托曼

"1991年，理查德·斯托曼到芬兰赫尔辛基理工大学演讲，我在生活中第一次见到了典型的留着长发、蓄着长胡子的黑客。这样的人在赫尔辛基不多。"

14. 关于Unix

"你在UNIX上完成的大部分任务都是通过六个基本操作完成的，它们被称作"系统呼叫"（system call）。第一个基本操作是"创建子进程"（fork），一个程序把自身完全复制出来，这样你就有了两个相同的拷贝。第二个基本操作是复制出来的程序， 再用一个新项目替换自己。其他四个基本系统呼叫–打开、关闭、读和写–都是为了访问文件的。这六个系统呼叫便组成了UNIX的简单操作。然后，你只需 在程序之间创造出交流渠道（pipes），就能解决复杂的问题。"

15. 关于编程

"对于任何编程的人来说，编程是世界上最有趣的事，比下棋有乐趣得多，因为你可以自己制订游戏规则。而你制定什么样的规则，也就会导出与此规则相符合的结果。"

16. 关于操作系统

"创造操作系统，就是去创造一个所有应用程序赖以运行的基础环境。从根本上来说，就是在制定规则：什么可以接受，什么可以做，什么不可以做。事实上，所有的程序都是在制定规则，只不过操作系统是在制定最根本的规则。"

17. 关于Linux的发明过程

"这花费了我大量的精力：编程――睡觉――编程――睡觉――编程――吃饭（饼干）――编程――睡觉――编程――洗澡（冲冲了事）――编程。"

18. 关于Linux的第一个观众

"我（把Linux）显示给我妹妹看，她盯着显示器看了大约五秒钟，看着上面是一串A和一串B，说了声"很好"，便没什么感觉地走开了。我意识到，这犹如你指给别人看你铺设了一条长长的柏油马路，但想向别人解释这条马路的意义是完全不可能的。"

19. 关于Linux的攻击者

"安德鲁·塔南鲍姆不断攻击我的Linux取代了他的MINIX操作系统。他只穿着件T恤就浑身冒火，能怪谁呢？"

20. 关于姑娘

"在那个时候，只要一想到姑娘，Linux系统就变得不再重要了。在某种程度上，今天也还是这样。"

21. 关于成功

"Linux所取得的许多成功，其实可以归结为我的缺点所致：1、我很懒散。2、我喜欢授权给其他人。"

22. 关于Linux 1.0版

"许多人认为，1.0版的发行是件大事，主要是那些出售Linux的软件公司，他们希望1.0版对发行有所帮助。在他们看来，1.0这个数字的心理 意义要远比其本身的技术含量更为重要。我对此倒没有什么异议，因为事实就是如此，以0.96版的序号销售操作系统确实比较糟。"

23. 关于26岁

"我开始观察镜中的自己，我的发线正在一点点向上面爬升，脸上也开始密布着细纹。我已经二十六岁了，平生第一次觉得自己老了。而这已经是我在大学里度过的第七个年头，我想抓紧人生，快一点毕业。"

24. 关于超时工作

"Linux不是靠牺牲宝贵的睡眠时间换来的。事实上，如果你想听真话，那我就要说，我更喜欢睡觉。"

25. 关于网络口水仗

"它们的全部存在意义就是不遗余力地宣传什么东西，也就意味着还要贬损其他的相关物。你在那里经常看到的通常只是些"我的系统比你的系统更好"之类的废话。我们可以把它们看作是某种形式的在线手淫。"

26. 关于微软

"突然间，到处都是微软的产品了，被蝗虫入侵了似的。我并不是说蝗虫是坏蛋，我喜欢所有的动物和昆虫。"

27. 关于开源软件的商业化

"我认为它带给我们更多的机会。比如，有些技术人员担心没法养活自己的孩子，他们现在就有了选择的余地。你可以仍然一如既往地保持理想主义，或者你 也可以选择成为某个新的商业类型。你让自己多了一个新的选择，并不会让你失去任何东西。在此之前，你除了保持纯洁之外显然没有任何其他的选择。"

28. 关于理想主义者

"我一贯认为理想主义人士很有趣，只是有点沉闷，甚至有些吓人。为了坚持一个非常强有力的意见，你不得不排除其他意见。那就意味着，你不得不变得不近情理。"

29. 关于互联网泡沫

"那情况也是前无古人的，你在任意一辆出租车内摇下窗户，随便向路边挺胸走过的妓女提问："主题演讲几点开始？"她都能告诉你答案。"

30. 关于比尔·盖茨

"比尔·盖茨作了一次主题演讲。威尼斯饭店那个足有7个宜家仓库大的舞厅里，挤满了站着听讲的人。"

31. 关于移居加州

"现在是十一月，我还穿着短裤，如果是在芬兰，我早就没命了。"

32. 关于软件专利

"我同时怀有两种心情――好的和坏的，但坏的成分更多。"

33. 关于攻击者

"有人声称，作为Linux领头人所产生的压力，已经使我从一个电脑迷变成了一个混蛋。他错了，实际上我一直是一个混蛋。"

34. 关于GPL许可证

"GPL为每个人都提供了机会，成绩卓著，这是人类的一个巨大的进步。可是，所有创新都应纳入GPL吗？ 这他妈的完全不可能，应由开发者自行决定是使用GPL还是使用其他保护版权的方法。令我几乎发疯的是，理查德·斯托曼认为非黑即白，别无它途，由此产生了 不必要的政治划分。"

35. 关于成名

"当人们开始过分认真地对待你时，就为你设下了一个温柔的陷阱。"

36. 关于律师

"那些将人类的创造结果称之为是"财产"的人，不用说，便是律师了。"

37. 关于知识产权

"许多要求加强知识产权立法的讨论是基于这样一种观点，即给创造者和艺术家以更多的"保护"。而人们似乎不曾、或者说是从未意识到，这样一种强有力 的权利导致一些人剥夺了另一些人的权利。如果你得出我认为版权实际上是有害的结论，那么你错了。恰恰相反，我热爱版权。我只是认为没必要将版权所有者的权 利无限扩大。不要扩大到将消费者的权利都被剥夺殆尽。"

38. 关于Java语言

"不要试图以技术来控制用户，那是决不可能成功的，最终要对公司造成损害，而且也会阻碍人们对于该项技术的接受。Java就是一个例子，它现在已经 远没有其初期那么富有吸引力了。Sun公司原本想要控制Java，但却基本上已经失去了它。Java现在依然运行得很好，然而却显然没有充分发挥其潜 力。"

39. 关于人类不再登陆月球

"因为月球被证实是一个很单调的地方，基本上没有夜生活，这有点像圣何塞。于是人们并不想再回到月球上去了。"

40. 关于电子邮件

"我喜欢电子邮件的众多理由之一是，它如此方便又如此容易被忽略。你可以轻松地对某些邮件不加理睬。"

41. 关于生活哲学

"寻找乐趣，做一些有趣的事情，增加财富和提高名声。"

42. 关于未来

"当你谈及技术的未来时，真正有意义的是人们想要什么？一旦能够描绘出这一点，剩下的事情就是如何大规模地生产它，并使它足够便宜，以便人们能够在不牺牲另外也想要的东西的同时获得它。除此而外，没有任何事情真正有意义。"

（完）

原文出处：酷壳 – CoolShell.cn 作者：陈皓

这篇文章主要来源是StackOverflow上的一个回答——“How deep are your unit tests?”。一个有13.8K的分的人（John Nolan）问了个关于TDD的问题，他说——

“TDD需要花时间写测试，而我们一般多少会写一些代码，而第一个测试是测试我的构造函数有没有把这个类的变量都设置对了，这会不会太过分了？那么，我们写单元测试的这个单元的粒度到底是什么样的？并且，是不是我们的测试测试得多了点？”

八卦一个答案

StackOverflow上，这个问题的答案是这样的——

“I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. I do tend to make sense of test errors, so I’m extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.”

老板为我的代码付报酬，而不是测试，所以，我对此的价值观是——测试越少越好，少到你对你的代码质量达到了某种自信（我怀疑这种的自信标准备要高于业内的标准，但这种自信也可能是种自大）。如果我的编码生涯中不会犯这种典型的错误（如：在构造函数中设了个错误的值），那我就不会测试它。我倾向于去做那些有意义的错误测试，所以，我对一些比较复杂的条件逻辑会异常地小心。当在一个团队中，我会非常小心的测试那些会让团队容易出错的代码。

Different people will have different testing strategies based on this philosophy, but that seems reasonable to me given the immature state of understanding of how tests can best fit into the inner loop of coding. Ten or twenty years from now we’ll likely have a more universal theory of which tests to write, which tests not to write, and how to tell the difference. In the meantime, experimentation seems in order.”

不同的人有不同的测试方式，在如今这种不成熟的时期，这些能够适应于内部编码的测试方式对我来说都比较合理。也许从今后十年或二十年，我们会对“什么要的测试需要写，什么样的不需要”达成更广泛的共识，并且我们可以知道这两者的区别。与此同时，各种实践都在各自发生中。

这个问题并不新鲜，但是这个回答对TDD似乎有一种否定，最亮的是这个问题是由Kent Beck，Kent是XP和TDD的创造者，是敏捷开发实践方法的奠基人。以致于还有人调侃到——

The world does not think that Kent Beck would say this! There are legions of developers dutifully pursuing 100% coverage because they think it is what Kent Beck would do! I have told many that you said, in your XP book, that you don’t always adhere to Test First religiously. But I’m surprised too.

只是要地球人都不会觉得Kent Beck会这么说啊！我们有大堆忠实程序员在追求着100%的代码测试覆盖率，因为这些程序员觉得Kent Beck也会这么！我告诉过很多人，你在你的XP的书里说过，你并不总是支持“宗教信仰式的Test First”，但是今天这么说，我还是很惊讶！

后面还有一些不人同意Kent， 我一下子从这个事中想到了《fight club》里的那个精神分裂者创建了一个连自己都反对的地下组织。呵呵。

其它答案

八卦完了，我们还是来认认真真地看看这个问题中其它的其它答案。

第二个答案：值得借鉴

• 开发过程中，单元测试应该来测试那些可能会出错的地方，或是那些边界情况。
• 维护过程中，单元测试应该跟着我们的bug report来走，每一个bug都应该有个UT。于是程序员就会对自己的代码变更有两个自信，bug 被 fixed，相同的bug不会再次出现。

第三个答案：给敏捷咨师看的答案

这个答案在说，我们只注意到了TDD中的T，而忽略了第一个D，就是Driven…… bla bla bla… 又这扯这些空洞的东西了，国内的各种不学无术的敏捷咨询师最好这一口了。

第四个答案：致那些什么都要测试的人

如果我们需要测试一个像 int square(int x) 这样的开根函数，我们需要40亿个测试（每个数都要测试）。

事实上这种情况可能还更糟糕，如果有这样一个方法 void setX(int newX) 不会更改其它的成员变量，如：obj.z, Obj.y，那么，你是不是还要去测试一下别的变量没有被改变？

因为，在国内也有很多很多人在问这类的问题——单元测试究竟要做多细？

细心的iOS 6.0 Beta版本用户可以发现今天的App Store “搜索”界面已经启用了全新卡片式界面，不再是以前列表式的排序界面，新的界面非常美观亦更加符合触控屏的使用习惯，不过弊端在于这样不容易快捷找到自己 想到的App，因为一个界面只显示一个APP的简介和预览图，而在之前Beta版中的相同界面则会显示至少4个Apps。

不知道这个是否只是暂时测试，后续到底会如何变化，让我一起期待9月12日iOS6.0 的正式发布吧【舅舅都说9月12日…_(:з」∠)_】

近日爆发的搜索引擎大战，昨晚已经从百度和360之争，演变成为百度、360与搜狗的“3SB”大战。搜狐公司董事局主席兼首席执行官张朝阳31日晚对外宣称：“搜狗必须参战！”

9月1日消息 近日爆发的搜索引擎大战，昨晚已经从百度和360之争，演变成为百度、360与搜狗的“3SB”大战。搜狐公司董事局主席兼首席执行官张朝阳31日晚对外宣称：“搜狗必须参战！”

在张朝阳表态的同一天，搜狗也正式发布搜狗高速浏览器4.0版，该版本浏览器首次实现IE8和Webkit两个内核的独立封装，可以提高网页打开速度达30%以上，安全性提升90%。而此前由于搜狗浏览器的协同作用，搜狗搜索已经成为仅次于百度的搜索引擎。

此前在360推出搜索业务后，搜狗CEO王小川曾发布内部邮件，就360进军搜索一事作出表态，王小川认为，因为360的进入，搜索进入了百度、搜狗和360的“新三国时代”，搜狗与百度和360“亦敌亦友”。

王小川表示，搜狗的策略是“挑战百度，防范360”。但搜狗已设定360占据搜索市场份额临界值，一旦360超过这一临界值，搜狗将会展开反击。（完）

上周我收到了一份邮件，一份让我心绪不宁的邮件。

邮件的作者基本上认为我在博客里和Pluralsight视频节目里谈论的都是非常浅显的话题，但发现我却虚伪的倡议面试内容应该设计的复杂些，应该为“真正的程序员”或超级程序员而设计。

这份邮件基本上表达了这样一种观点：开发应用程序的都不是“真正的程序员”，“真正的程序员”编写的是有难度的东西，跟复杂的数学算法相关的东西。

真有超级程序员吗？

我并不认为这种对编程和软件开发的认识和理解是他独有的，或是个别现象。甚至IT精英Scott Hanselman也称呼自己并且认为自己是欺世盗名的骗子。

Scott Hanselman的这篇文章让我产生了共鸣，因为有时候我也有和他相同的感觉。

有时候，我很怀疑，我是否真的有能力解决真正有难度的问题。

让我斗胆猜测一下，我猜测大部分的程序员在思想里都会某种程度的承认，承认自己只是一个普通的程序员，但这世界上确实有一些超级程序员，他们在做一些诸如控制硬盘缓存或为谷歌建立搜索索引等非常复杂的算法问题。

好吧，不否认，当然会有一些程序员正在写一些代码处理各种你我都不能理解的复杂问题，但他们跟我们这些余下的程序员究竟有多大区别呢？

在一个为企业开发应用的程序员和一个为谷歌写搜索算法的程序员之间，或和一个开发用来控制读写头从磁盘扇区读取数据的物理操作的芯片程序员之间，有真正的不同吗？

在我回答这个问题之前…

让我们花几分钟时间谈谈他们所解决的问题。

你曾经遇到过的需要去解决的最有难度的问题是什么？

你是如何着手去解决这些问题的？

到最后，当你真正的解决了这个问题时，你是否觉得好像不是那么难？

当你回顾这段经历，回头来看这个问题时，你是否会发现，现在看来，它其实是个非常简单的问题？

你有很多疑问，我知道——可是我希望你在继续往下阅读前真正花时间思考一下这些疑问。

理解“认知”和“现实”之间的差距。这是非常重要的。很多的程序员，包括我在内，都经常分不清两者之间的区别。

大家都知道，我们对一个问题的认知经常跟这个问题的真实情况有很大差距。当我们还不理解一个问题时，我们会把这个问题想象的比它本身要复杂。但是，一旦我们理解了这个问题，我们会发现这实际上是一个很容易处理的问题。

让我来给你一个现实的例子。看一看下面这个数学公式。

我们可以把在看这个公式的人分成两类人。

1. 对高等数学有相当了解的人，他们能立即认出这个公式，能马上知道它是干嘛的。
2. 从来都没见过这样一堆符号的人，他们的即时反应会认为这是某种复杂的算法，可能需要几年的时间才能弄懂。

也许我说的并不很准确，但我想说的就是，在“会的人”和“不会的人”之间有一个清晰的分界线。

我可以用你已经熟悉的知识对这些符号做一个简单的解释。

准备好了吗？

这个公式跟下面这段代码是等效的：

var total = 0;for(int i = n; i <= m; i++){   total +=  f(i)}

这说明了什么？

我想说的是，在数学算法中，在编程中，在我们的日常开发工作中，只有少数一些问题能称得上是有难度的问题，而且通常这些比较难的问题都能够分解成更小的问题(有时候需要多次分解)，直到最后你需要处理的只是一个很简单的问题。

我的这个博客的目的，我的Pluralsight视频节目的目的，基本上都是告诉大家要把复杂的事情简单化。我自己的生活也是这样。

如果你想成为一个成功的程序员，你必须自己要学会如何做到这些，它会是你能学到的最重要的一门技能。

那么，现在来回答最初的问题——不，我不相信这世上存在超级程序员。我不认为在企业应用程序员和那些被视作在研究真正复杂问题或“真正的编程”的程序员之间有什么不同之处。

但不要误解我的意思，不要以为我是在说我不相信某些程序员会被其他程序员在技能高出好几个数量级。我敢大胆的说，真正优秀的程序员在效率是会比普通程序员高出10倍甚至20陪。

我想说的是，我们有一个习惯，总是忘记：当问题被分解成更小的问题后，所有的问题都变得如此简单，而且所有的问题都能这样去分解。

我想说的是，这个问题是一种能够阻挡你进步成为一个真正优秀程序员的问题，这是由于你自己的认知上错误导致的，你会把目前看上去复杂东西当作是不可理解的。

我想说的是，当你在开发一个对自己来说似乎是很容易的企业应用时，你可能忘记了，对于那些对编程一无所知的所有你的朋友和家人来说，这是一个多么困难或几乎不可能完成的事情。

仍然不赞同我的观点？

很好，你有这样思考的权利。

但我给你准备了一个难题。你想必一定是知道某位“超级程序员”了。也许你就是其中之一。如果是这样，我们要听你说说。请告诉我们一个非常有难度以至于其他的人有不可能理解的复杂问题。

我并不是在挖苦你。我是很严肃的，如果你能够证明我错了，那就证明给大家看。我至今还未遇到过一个不能分解成简单可理解的小问题的难题。

[本文英文原文链接：The Myth of the Super Programmer ]