原文出处：酷壳 – 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 ]