BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Spolsky论战Bob大叔

| 作者 Niclas Nilsson 关注 0 他的粉丝 ,译者 张晓庆 关注 0 他的粉丝 发布于 2009年2月24日. 估计阅读时间: 8 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

过去几周中, Joel SpolskyRobert 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 HanselmanHanselminutes最近的一期节目中对此做了回顾。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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

有一句话是值得思考的 by Jeffrey Zhao

有些东西经验丰富的人已经了然于心,我们怎样让新丁学习,并且学习时不要过于艰难呢?

改良的 TDD 与 UDD by Zhang Charlie

Bob 大叔的回答也是不错的:


我不认为TDD很神圣。我认为它是一个值得遵守的规则。我不会事先编写所有的测试。有一小部分测试在编码后再写只会更方便。甚至有一些代码我根本不会写测试,因为不值得写。但是这些都是例外情况。大多数代码我会先写测试。(不,Joel,这没有浪费我的时间。)


前半部分,我很赞同,TDD 不应该成为神圣的教条。Bob 提出的做法其实是一种改良过的 TDD,放宽了原先 TDD 对开发步骤顺序的严格限制。可见,我们(至少在 Bob 所说的例外情况下)并不需要针对所有实现代码,都必须先写测试代码。一个问题是,如果你不是每次都先写测试代码,后写实现代码,怎么叫 test driven 呢?

Uncle Bob 说,大多数情况下,他会先写测试。具体他没说,是那种类型的测试,估计是单元测试。和 Uncle Bob 不同的是,一般我肯定不会首先去写单元测试,除非有绝对的必要,比方这些单元都很重要,而且它们的外部接口、使用方式和依赖关系已经相对稳定了,需要对外发布这些单元等等。

尤其在开发阶段的早中期,在需求和架构都还不稳定的时候,我更不会首先把精力放在写单元测试上。我会尽量根据功能需求(use case)的基本流、扩展流以及架构的重要性等因素来设计测试,即便要做更小粒度的单元测试,也会首先考虑对一组、一群对象联合进行粒度更大一些的测试。我觉得这种方式效率可能会更高。

UDD 认为需求、架构是软件开发的主要矛盾,每个单元相对于整体和全局来说是次要矛盾,当然这是一对辩证关系。所以,由于存在软件开发哲学观点的差异,TDD 更像是 bottom up 的开发,先保证每个单元积木块的正确,再保证整体、全局的正确;UDD 则更像是 top down(architecure-driven)的开发,先保证整体、全局的稳定和正确,再来完善局部细节。在实践中,其实这两者都是可行的。架构重要?还是单元重要?答案是在运动、变化的。

由于任何带有边界的“系统”(包括类、单元在内)都存在 use case,所以 UDD 的单元测试,也借鉴了 use case/scenario 的设计方法。

针对我所了解的国内的情况,UDD 认为:TDD 对开发步骤顺序的刚性规定(“必须”先写单元测试代码,后写实现代码)在实践中是没有必要的,而且很多时候没有必要从单元测试开始写起。另外,大多数代码都应该努力配上自动系统功能测试,以减少人工测试的麻烦。系统测试的完备性比单元测试的完备性更重要。

资深敏捷 OO 教练
www.zhangxun.com

漏掉了Kent Beck同学的反应 by 刘江 图灵

当然,比较简单:Joel Spolsky is wrong about my work
参见www.threeriversinstitute.org/blog/?p=29

不必严格意义上的TDD by yongji zhang

否则就成为了教条。
两种思维方式应该结合起来。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

4 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT