过去几周中， Joel Spolsky 和 Robert C Martin （又称 Bob 大叔）之间有一场论战。它起源于 Jeff Atwood 和 Joel Spolsky 在 Stack Overflow 广播的第 38 期播客 ，Joel 提到别人经常给他这样的建议，说他应该把单元测试加到 Joel 测试：改进代码的 12 个步骤 之中，成为第 13 步。而 Joel 不同意这样，他解释说:
对测试驱动开发有一些争论……应该给所有东西都写单元测试吗，诸如此类的东西……许多人读了 Joel 测试之后向我写信，说：“你应该有第 13 步：单元测试，所有代码要有 100% 的单元测试。”
对我来说这有点太空洞，好像你根本不需要的一些东西。敏捷编程总的观点就是不需要就别做，需要时再引入。我觉得很多时候对所有东西写自动化测试并不能对你有所帮助。
Joel 基本上有两个异议，第一个是你把时间花在什么上面了：
但我觉得即使团队的单元测试覆盖率达到 100%，依然会有一些问题。他们可能花费了相当多的时间编写单元测试，然而质量未必能得到相应的提高。我是说，质量可能提高一些，他们也有能力修改一些代码并有把握不破坏任何东西，但仅此而已。
Joel 的第二个异议是测试套件非常脆弱：
但是我发现单元测试真正的问题在于，随着代码改进，你想修改的内容可能会破坏一定比例的单元测试。有时你修改了代码，不知何故，有 10% 的单元测试 失败了。因为你修改了某些设计…你移动了一个菜单，现在所有依赖菜单的东西仍然存在…而菜单移到了别处。所以这些测试都失败了。你必须能够重写这 些测试，以反应代码新的实现。
讨论继而转向了 Bob 大叔搜集的面向对象设计的SOLID 原则，Bob 大叔和 Scott Hanselman 在 Hanselminutes 最近的一期节目中对此做了回顾。Joel 再次说道：
这是面向对象的设计，而他们把它叫做敏捷设计，实际上它真的，真的不是。这只不过是一些怎样设计类，类应该怎样工作的原则。坦白来讲，当我听到这些原则时，感觉就像官僚之极的设计，一定是没写过多少代码的家伙想出来的。
但是 Jeff 和 Joel 显然没有了解清楚 Bob 大叔和他与敏捷的关系。Bob 大叔是达成敏捷宣言那次大会的发起者，几乎从 Jeff 和 Joel 出生时他就靠写代码谋生了。他还写了相当多公开的代码，所以 Bob 针对博客上的内容发表了他的想法。
我不认为 TDD 很神圣。我认为它是一个值得遵守的规则。我不会事先编写所有的测试。有一小部分测试在编码后再写只会更方便。甚至有一些代码我根本不会写测试，因为不值得写。但是这些都是例外情况。大多数代码我会先写测试。（不，Joel，这没有浪费我的时间。）
Bob 也决定在敏捷上盖过 Joel：
Joel 说 SOLID 原则不是“敏捷”。（唉）。任何一个人和他的大叔都认为自己知道单词“敏捷”是什么意思。但是是我召集了那次会议，挑选了单词 “敏捷”。自从词组敏捷开发被创建以来，我一直在写关于敏捷开发的内容。我认为我知道什么是敏捷，什么不是。我也认为我有权力在这方面盖过 Joel。 Joel，SOLID 原则是敏捷的。
对 Joel 经历的修改代码会破坏 10% 的测试的情况，Bob 大叔写道：
Joel 继续抱怨测试脆弱的问题，说一旦修改了代码，一些测试自然失败了。Joel 还引用了统计数据 10%。这太傻 x 了，说明 Joel 对 TDD 了解 浮浅，根本没有学到任何东西（典型失败的书呆子）。如果你设计的测试有 10% 因为单点变化而失败，那你应该换个工作了。测试设计，与软件设计的任何其它部分一样，也需要解耦。
随着辩论继续，Atwood 写了一篇博客，他称之为 The Ferengi Programmer ，他说即使他赞成 SOLID 原则从表面上看没有异议，但是确实有这样一种危险，就是过于依赖规则。
规则、准则和原则是从实践中提炼出来的宝藏，值得研究和尊重。但是它们决不能替代对你工作的认真思考。
Jeff 所写的无可置疑。不仔细思考事情就不会有好的软件，大家写书、规则或者方法通常是意识到这样一种风险，大家奴隶般遵守你的建议，而没有意识到环境的不同，但是避免这些风险并不容易。总结起来就是 http://www.infoq.com/cn/articles/better-best-practices ，以及读者阅读建议时达到的技能级别。听从 Jeff 的建议意味着如果以德莱弗斯的衡量标准，你是想在那项技术上从高级初学者或者精通级别转到胜任。这种变化可以认为是你必须有意去做一些事情才能达到，并非随着时间流失就能够自然达到。
在更多公开的争论之后，大家决定 Bob 大叔应该去 Stack Overflow 播客广播，该期内容已于最近广播。 Bob 大叔得以有机会描述SOLID 原则背后的想法，Joel 问了一些关于它们什么时候有用的问题。当Joel 问道为什么该原则重要的时候，事情有了小小 的转机，Bob 举例说能够分开部署组件，Joel 继续问这个原则是否只在那些需要分开部署的大项目中才有用时，Bob 声称他在这一点上同意Joel。
当谈到质量和TDD 时，他们的分歧更加清晰起来（即使好像大家都接受测试像文档一样有价值这个观点）。Bob 解释了创建测试套件的重要性，这些测试套件不能像Jeol 经历中的那样脆弱，不要一点修改就破坏10% 的测试，Bob 还介绍了怎样做到这一点，比如通过逻辑和呈现层的分离、在界面显示内容之下 正确地测试。Jeff 提出Unix 社区通常是这么做的，首先写一个命令行程序，然后在其上封装一个UI 来驱动它。
播客的最后，Jeff、Joel 和Bob 再次谈到了遵守建议的风险，以及编程社区的技术水平，他们一致认为太多的开发者根本不关心自己在做什么。总之，他们都认为多动脑筋是很有必要的，但感觉他们对开发软件的方式尚未有一致意见。他们三人都承认对变化做出响应很重要，但是要想做到响应变化，需要对设 计和测试投入多少是他们分歧的核心，也是整个行业普遍存在的分歧。变化是永恒的，我们如何处理变化却差别甚大。
这次讨论自然而然地在博客圈内引起了大量的讨论，论坛上的信噪比也下降很多。 Dhananjay Neneto 发表了与学习相关的一个想法深刻的评论，用以回应 Jeff 的这个帖子──The Ferengi Programmer，Dhananjay 说道：
我认为这个帖子带来的大麻烦是，它的建议对初级程序员带来的害处要比好处更多。它可能鼓励他们做出取舍──甚至在学会做取舍的代价和含义之前。它也可能让他们远离此旅──仔细而明智的应用（需要在早期投入相当多的精力），并能帮助他们内化吸收那些原则。
这是一场可能永远持续下去的争论，也是一场杂音太多没什么意思的争论，但是仍然有一些有趣的东西，这些东西不仅仅是爱好的问题。它还引出了这样几个问题：
- 有些东西经验丰富的人已经了然于心，我们怎样让新丁学习，并且学习时不要过于艰难呢？
- 我们怎样应对变化，从哪一点开始为应对变化而预做准备的投入会大过产出，界限在那里？
- SOLID 原则只适用于复杂项目吗？什么时候该用，什么时候不该用呢？用和过度使用之间的分界线是什么呢？
查看英文原文： Spolsky vs Uncle Bob
评论