Browsed by
标签: agile

“单元测试要做多细?”

“单元测试要做多细?”

这篇文章主要来源是StackOverflow上的一个回答——“How deep are your unit tests?”。一个有13.8K的分的人(John Nolan)问了个关于TDD的问题,这个问题并不新鲜,最亮的是这个问题的Best Answer,这个问题是——

“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.”

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

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

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (30 人打了分,平均分: 3.90 )
Loading...
持续部署,并不简单!

持续部署,并不简单!

感谢 @常新居士 投递此文 】

这几年,持续集成随着敏捷在国内的推广而持续走热,与之相伴的持续部署也一直备受关注。自前两年,持续交付这个延续性概念又闯进了国内IT圈,慢慢开始在社区和会议中展露头角。许多不明真相的群众跟风哭着喊着要“上”,而许多前CI的半吊子玩家换件衣服就接着干,有的甚至衣服都来不及换……。国内的这些土财主如果不巧请了某些所谓的战略家,除了建了一堆持续集成环境,以及每天嚷嚷着要这个要那个,混乱的状况在根本上没有得到改善。本文无意费力探讨持续集成和持续交付的概念,而是打算谈谈对于大型软件企业,以持续集成为基础实现持续部署(交付)时,所要面对的问题以及可行的解决方案。地主老财们,夜黑风正猛,山高路又远,注意脚下……

And God Said, Let there be light: and there wa— GENSIS, Charpter 1, King James

一、起步

先来讲个故事……

几年前,一对留美的夫妇通过朋友找到我,让我帮忙在国内组建一个开发团队,该团队负责为其开发一款基于社交网络的客户关系管理软件,(暂且称之为项目A)。这个项目除了尚不清晰的需求范围和很紧的期限外,作为业内人士的老公Richard根据眼下流行的软件开发过程还提了诸多额外的要求:

  • 功能要及早交付(以便拿去和潜在的投资人洽谈)
  • 功能在部署到生产环境前要先部署的一个测试环境(Richard要试用后给予反馈)
  • 功能必须经过测试(长期作为软件外包的甲方,对质量要求严格)
  • 要减少后期维护的工作(美国人精贵,少雇一个是一个)
  • 支持协同开发(以便维护人员及早介入)
  • ……

这正是持续集成所要解决的典型场景。针对Richard的要求,我们只要建立一个基于Hudson(现在叫Jenkins)+Maven +SVN 的持续集成环境(再加上持续集成所要求的测试和过程)就可以很好地满足上述要要求,此方案的结构如下:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (28 人打了分,平均分: 4.04 )
Loading...
Test-Driven Development?别逗了

Test-Driven Development?别逗了

这篇文章来源于Peter Sergeant在Write More Test 博客上的《Test-Driven Development? Give me a break…》,在原文和Reddit 上有很大反响。这篇文章里的很多观点在《TDD并不是看上去的那么美》和《再谈敏捷和TW咨询师》里都出现过(我个人觉得我的观点比其更全面一些)。就像我转的《Scrum为什么不行》 和《Bob大叔和Jim Coplien对TDD的论战》一样,从这些贴子我们可以看到——这是一个全世界的问题,并不是只有在中国才有的问题

很多敏粉都在说我在是喷敏捷,黑敏捷,向敏捷泼脏水,我只想对这些人说——你们这样的见解很肤浅也很敏感,你们根本就没有认识到——争论,反思和不同观点的意义,你也就无法了解你们所信仰的敏捷!你们只是在肤浅和盲目地信仰和教条敏捷中的许多名词、方法和标准答案罢了

——————————————正文开始——————————————

对于程序员来说有些事有非常危险的信号(red flag)。当我听到有人开始信仰Test-Driven Development 是 One True Programming Methodology(唯一正确的编程方法论),这就是危险信号(red flag),我开始假设你是一个劣等、没有经验的程序员,或是某些敏捷咨询师。

测试只是一个工具来帮助你,而不是用来证明谁比谁更虔诚,或是我的屌比你的要大,等这种愚蠢的行为。测试是用来让程序员得到有帮助的、更快的反馈,从而找到正确的路径,如果你搞坏一些事,其还可以用来给后人一些警告。这根本就不是一个神秘的有魔力的方法其可以让你的代码变得更好……

整个Test-Driven Development的概念是麻痹和信奉,从而让其成为你的人生观。相反的:Developer-Driven Testing,它给你和你的同事一些有用的工具来解决问题,来支持你自己,而不是那种以工具或方法为中心的让你假设其应该是那样的测试。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (17 人打了分,平均分: 3.12 )
Loading...
“品质在于构建过程”吗?

“品质在于构建过程”吗?

感谢@weidagang (Todd)向酷壳投递的这篇精彩的文章。原文

今天在微博上看到几位敏捷爱好者探讨敏捷测试和质量保证问题,我忍不住也加入了讨论:

Z先生原帖:我刚才看到一个大会演讲稿,谈到敏捷测试六大指导原则:1.仅靠测试人员不可能获得高质量的软件,质量是整个研发团队的责任;2. 场景是不可穷举的,测试活动必须是风险驱动的,关注于高风险的场景;3.分层自动化测试是唯一出路;4.在正确的位置进行恰当的测试是自动化的关键;【待续】

S先生回复:品质在于构建过程。检验贯穿构建过程,提供及时反馈。

我回复:什么样的构建过程才能出Unix这样的品质呢?迭代?快速反馈?TDD?

S先生回复:据说stroustrup听到重构时的反应是,我们从七十年代就这样做了。推荐《UNIX编程环境》,了解大师的编程方式。

我回复:您偷换了概念。不能说大师用了重构,C++和UNIX的品质就是靠重构或某种构建过程得来的。厨师做菜用到了勺子,不等于菜好吃是因为勺子。

S先生回复:我没有概念。我们看到一个果,就问因是什么。其实是泛因果,无因果,一切是机缘凑巧。

我回复:“品质在于构建过程”难道不是一个明白的因果描述吗?

S先生回复:品质在于构建的人。我说话时没因果,你看到了因果。

我回复:欢迎敏捷爱好者围观!

很高兴几个回合讨论下来S先生修正了先前“品质在于构建过程”的观点。什么重构、TDD、迭代、快速反馈等等构建过程都不是Unix品质的核心要素。我不但不认同“品质在于构建过程”、“测试是最好的设计方法”这类机械式的观点,而且也不满意把软件优劣归结于“人是根本”的简单回答。我们需要探索一个既非机械式,也非简单地归结为某种理念的答案。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (30 人打了分,平均分: 3.90 )
Loading...
在新浪微博上关于敏捷的一些讨论

在新浪微博上关于敏捷的一些讨论

自从我发布了“Scrum为什么不行”,并被CSDN推成首页头条后,我在我的新浪微博上就经常被敏粉们@去讨论他们的一些话题。他们似乎想要从我这里听到一些不同的声音,我很喜欢他们的这种态度,在这里先赞他们一个。既然,让我来评论他们的东西,我就不客气了,板砖自然是少不了的。 我觉得我在微博上的观点比较散,所以在这里做一个汇总。我在所有批评敏捷的文章里都重复说过我的立场,这里还要再说一遍,因为那群人很敏感——“我承认敏捷中有一些东西我是认可的,但对敏捷社区的推广和思维方式我持否定态度”。

敏捷词汇表

我被@吴穹adam邀请进入了一个敏捷词汇表的微群,这个群就是想明确的定义一下敏捷的各种词汇,比如,他们想把TDD定义成就是UT。呵呵。我对这个群仅保持了30分钟的热度,我在里面发了一个“你们不想讨论技术吗?”的帖子,就再也不想关注了。因为我的观点如下:

  • 我不知道干这件事有什么意义。标准化还是洗脑?One World, One Agile?  – horse shit!
  • 你能定义地好吗?定义好了大家都能干好了? – 幼稚!
  • 理解不同又有什么关系?价值观不同又能怎么样?为什么不能正视并接受世界的不同呢? –  固执!

敏捷宣言

我看到很多人又把《敏捷宣言》拿出来说事,就好象他们把敏捷宣言是软件开发的普世的价值观一样。我对此的评论是——

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (17 人打了分,平均分: 3.18 )
Loading...
为什么Scrum不行?

为什么Scrum不行?

这篇文章的原文在这里(原文链接)(下文不是全译,也不是部分译,我只是把其总结,有我自己的发挥,但是原意大致不变),这篇文章完全是在调侃Scrum的,作者第一段就是一个免费声明,其说他是Scrum和其它敏捷方法的big fan, 他也认为Scrum 100% 对 软件开发可行。作者使用Scrum 5年了,也公开作过几次敏捷的分享会。他觉得写这篇文章只是为了好玩,因为他们戴上Edward de Bono 的 black hat (黑礼帽 – 是6个思考之帽中的一种——负面思考,思考事物的负面因素,这样才知道:它会起作用吗?缺点是什么?它有什么问题?为什么不能做。)

因为本人经常站在Agile的风口浪尖,所以我有必要也来一个“免责声明”。Shit!其实我想来的是“不免责声明” ——下文中的九大原因是对中国的各种Agile实践者咨询师不注重实际只重方法论的批判本人必然要和那种只以流程方法论为中心的软件开发斗争到底。其实我没有那么嚣张,我只是想说,下面的这些东西相当的现实。希望各种Scrum的实践者们认识到这些问题,从而可以让你们明白软件开发中的人的重要性

Reason 1:  Scrum 的基石是相信人。创造一个安全的环境,这样每个人都能相互学习,相互直言。但是,这是不行的,这世上有很多人并不关心这些,而且政治和竞争到处都是,办公室里无小事,你和别人交心,你相信他们,最终受伤的你自己。你真的以为那里有空间让你可以去犯错,去冒险吗?别天真了!你啊,too young, too simple, sometimes naive!

Reason 2: Scrum 认为只要给员工足够多的自由员工就能做得最好。这该死是理论是基于什么玩意?不可能,人的天性是懒惰的,他们才不会把事做好的,他们只会做相应报酬的工作量,还可能基本还达不到其相应的报酬,大多数人都在混日子啊。尤其是和经理比起来,谁不想能尽快地成为经理或Team leader啊,因为那样他们就可以即不干活,又挣得多。另外,你给他们自由,你就会发现,他们会只会做他们感兴趣的事,要么聊QQ,要么打游戏,看闲书,反正不干正事。直到你催了,他们才动一动。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (21 人打了分,平均分: 4.05 )
Loading...
Bob大叔和Jim Coplien对TDD的论战

Bob大叔和Jim Coplien对TDD的论战

今年春节时,我写了一篇《TDD并不是看上去的那么美》,在这篇文章中我列举了一些关于使用TDD的一些难点和对TDD的质疑,后来出现了一些争论(可参见那篇文章的评论),以及Todd同学的《TDD到底美不美》,还有infoQ中文上的那个几乎没有营养离线讨论。今天,有网友给我推来一个英文版infoQ的视频——“Coplien and Martin Debate TDD, CDD and Professionalism”,这是2008年2月18日的视频,视频的主角两个人争论TDD好还是不好,一个是敏捷社区的教主级的人物——Robert Martin(大家称之为“Bob大叔”),另一个是C++,OO,多范式编程的大师Jim Coplien(大家都叫他Cope)。这两个人对TDD的见解有分歧。Coplien的很多观点和我之前的不谋而合,而他自己称他是坚决强烈地站在TDD的对立面上。下面是Jim的原话:

I have adopted a very strong position against what particularly the XP community is calling test driven development.

InfoQ的视频很多时候相当的不给力,就像有前列腺的患者撒尿一样,半天都挤不出一滴。不过,好在那里有这两个人对话的摘录。在这里,我给大家摘要一下:

——————————————————正文分割线————————————————————

Coplien首先让Uncle Bob定义了一下TDD,Uncle Bob说明了他的三个法则:(敏捷的同学一定不陌生)

  1. 一个测试驱动的程序员,其不会在写出一个测试失败的Unit Test前,去写一句可用在生产线上的代码。(没有测试之前不要写任何功能代码)
  2. 在编写用于生产线上代码之前,不写过多的测试失败的Unit Test。(只编写刚好能体现一个失败情况的测试代码)
  3. 在现有代码通过Unit Test前,不写更多的用于生产线上的代码。(只编写恰好能通过测试的功能代码)

Coplien说他有意见的不是这三个法则,而是因为这个三个法则是孤立说出来的。Coplien说他和一些咨询师或是Scrum Master参与过很多的项目,他们发现这些项目都有两个问题:

  1. 他们使用TDD的时候,软件没有一个架构或是framework。当然,Kent Beck说——TDD可以驱使你去做架构。但是,TDD和Unit Test 是一回事吗?Unit Test是一个伟大的事,尤其是当你去写API和类库的时候。今天XP所说的TDD和UT很不一样。如果你使用TDD来驱动你的软件系统架构,那么,基本上来说,三个迭代以后,你开发的软件就会crash掉,而且无法再往前开发。 因为什么?因为连软件团队自己都受不了这三个迭代出来的架构,而且你还会发现,你根本没去去重构。
  2. 第二个问题是,TDD这种方法破坏了GUI(图形界面),就算是Kent也说:“你永远不可以在一个漂亮的界面后面隐藏一个糟糕的架构”,Coplien强烈地相信软件的架构是通过界面来发出其光芒。他觉得如果没有一个好的软件架构,这个会影响用户的操作。

Coplien接着说,如果我们使用Uncle Bob的三条法则,我们也许没有什么问题,但Coplien想告诉大家另一个非常重要的事,那就是软件架构。并说:“我根本不接受TDD是软件专业化实践的论点”

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (11 人打了分,平均分: 3.18 )
Loading...
敏捷水管工

敏捷水管工

本文来自Terazen Technology Inc的创始人+CTO的 David Ing的《Agile Plumbers》(这也墙?),我的其文中的这个帮事翻译过来(和前些天发的SOAP的S是Simple异曲同工)。

也许你会觉得这个比喻不恰当。但我想告诉你的是,这个故事告诉我们,教条主义和以方法论为中心的危险。十条不错的编程观点中第一条—— The only “best practice” you should be using all the time is “Use Your Brain”.

————————————————————

(门铃响……)

事主:啊, Agile 水管工吗? 请进,感谢谢你们这么快就来了——这的确很紧急,我这真是很乱。

水管工1: 先生,没问题,我们就是敏捷的。在我给你做Presentation前,我先给你介绍一下我的两个同事。

事主:Presentation?啊,我们有时间吗?这的水已经流得到处都是了……

水管工1:……先生,我们必需坚持这个。我们只是想保证你能成为动态搜寻解决方法的一份子。你是我们的 champion sponsor,也就是我们团队内的 consultant!你可以提供一个白板给我们使用吗?

事主:我没听懂,你们不觉得这变复杂了吗?我觉得我应该告诉你们这水是从房子哪儿流出来的,就是那……

水管工2:你这有让我脱衣服的地儿吗?

事主:什么?

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (20 人打了分,平均分: 3.40 )
Loading...
再谈敏捷和ThoughtWorks中国咨询师

再谈敏捷和ThoughtWorks中国咨询师

前言说明

之所以用了“再”,是因为之前的两篇文章——

  • 我在《那些炒作过度的技术和概念》中批评了ThoughtWorks中国咨询师的咨询方法是以一种接近于教条、炒作、洗脑和电视购物的方法(虽然我心底觉得有时候有时候更像传销),当然,批评是没有意义的,所以我也给了中国ThoughtWorks那些年轻的咨询师们一些我认为有建设性的建议。
  • 我在《TDD并不是看上去的那么美》一文中列举了一些在实际中使用TDD可能会出现的问题和难题,以此来告诉大家在使用TDD时需要注意的东西。就像是在《结对编程的利与弊》说的一样,只有真正知道一件事情的利弊,你才能用好它。

当然,这两篇文章都不可避免得招来了ThoughtWorks咨询师和Agile信仰者们的很多回复,我也有开始沉不住气回复了很多,当然,有一半以上的不是学术上的讨论,而是对我个人的攻击。甚至,在这两篇文章发布后,酷壳(CoolShell.cn)受到持续性的黑客攻击

本来已经过去的事,今天却又发现这两篇文章的访问量和评论又上来了,才发现原来是InfoQ的这篇文章——《虚拟座谈会:TDD有多美?》,加上很多我在评论中的观点,以及ThoughtWorks和InfoQ之前给我的来信中谈到的一些观点。我很不自然地想把我的一些观点总结并罗列在这里。主要分成四块—— 1)我对整个事情的基本观点,2)对于方法论的观点,3)对于TW中国咨询师的观点,4)还有和TW和InfoQ住来信件中的观点

————————————————

基本观点

首先,我想说明一下我的基本观点。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (52 人打了分,平均分: 4.40 )
Loading...
[转]TDD到底美还是不美?

[转]TDD到底美还是不美?

下面的文章转自Todd Wei 的《TDD到底美还是不美?》,对于这篇文章,我个人能过透过作者的观点感受到他的项目中使用TDD的难点,同样可以感受到作者内心的纠结。不管怎么样,我能够感到作者Todd Wei在独立思考,独立思考总是好的,因为那是走向成熟的必要条件。(另,大家可以移步过去看看相关的评论,挺有意思的)

————————————————————————————————————

最近CoolShell上的一篇《TDD并不是看上去的那么美》引起了敏捷社区的高度关注和激励辩论。今天,InfoQ甚至专门举行了一个“虚拟座谈会”《TDD有多美?》,几位国内敏捷社区的名人专门就此问题展开了深入地讨论。不论结果如何,这个纯技术的探讨精神还是非常值得赞赏的。事件实际上可以简单地归纳为“一个有一定影响力的开发人员质疑TDD,一群敏捷社区名人对TDD进行解释和辩护”。现在,就让我坚定地站在CoolShell一边,为对TDD的质疑和批判添砖加瓦吧!

TDD的核心理念是什么呢?第一是Specification by Example,即把测试用例作为表达需求的一种方式。传统的需求表达方式包括文档,Use Case等,而TDD强调通过测试用例来表达需求。另外,TDD的测试用例是黑盒的基于外部接口的,所以,它实际上又是对外部接口的设计。如何看待测试用例是TDD与传统测试的一个重要区别。“不把测试用例单纯地视为测试,而从需求和设计的角度来看测试用例”的理念本身是好的。另外,TDD的第二个理念是Test First,强调测试对于实现的驱动作用,先写测试用例,再实现和重构。在Specification by Example的理念下,Test First的实质是“先理解清楚需求,并做好外部接口设计,把它转化为测试用例,然后再来实现和重构”。

我认为,Specification by Example是不错的,因为测试用例作具有精确性,容易自动化的优点,这是传统的文档和Use Case在表达需求时所欠缺的地方。但Test First理念本身则有很大的问题,尤其“在没有测试用例失败之前,不要写任何一行代码”的极端方式则更是极端的错误。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (17 人打了分,平均分: 3.29 )
Loading...