Browsed by
标签:agile

TDD并不是看上去的那么美

TDD并不是看上去的那么美

春节前的一篇那些炒作过度的技术和概念中对敏捷和中国ThoughtWorks的微辞引发了很多争议,也惊动了中国ThoughtWorks公司给我发来了邮件想来找我当面聊聊。对于Agile的Fans们,意料之中地也对我进行了很多质疑和批评。我也回复了许多评论。不过,我的那些回复都是关于中国ThoughtWorks咨询师以及其咨询的方法的。我对Agile方法论中的具体内容评价的不是很多,所以,我想不妨讨论一下Agile方法论中的具体的实践(以前本站也讨论过结对编程的利与弊)。

那么,这次就说说TDD吧,这是ThoughtWorks中国和Agile的Fans们最喜欢的东西了。我在原来的那篇文章中,我把TDD从过度炒作的技术剔除了出去,因为我还是觉得TDD有些道理的,不过,回顾我的经验,我也并不是很喜欢TDD。我这篇文章是想告诉大家,TDD并没有看上去的那么美,而且非常难以掌控,并且,这个方法是有悖论之处的

TDD简介

TDD全称Test Driven Development,是一种软件开发的流程,其由敏捷的“极限编程”引入。其开发过程是从功能需求的test case开始,先添加一个test case,然后运行所有的test case看看有没有问题,再实现test case所要测试的功能,然后再运行test case,查看是否有case失败,然后重构代码,再重复以上步骤。其理念主要是确保两件事:

  • 确保所有的需求都能被照顾到。
  • 在代码不断增加和重构的过程中,可以检查所有的功能是否正确。

我不否认TDD的一些有用的地方,如果我们以Test Case 开始,那么,我们就可以立刻知道我们的代码运行的情况是什么样的,这样可以让我们更早地得到我们实现思路的反馈,于是我们更会有信心去重构,去重新设计,从而可以让我们的代码更为正确。

不过,我想提醒的是,TDD和Unit Test是两码子事儿。有很多人可能混淆了自动化的Unit Test(如:XUnit系例)和TDD的软件开发过程。另外,可能还会有人向鼓吹“TDD让你进行自顶向下的设计方式”,对此,请参阅本站的《Richard Feynman, 挑战者号, 软件工程》——NASA的挑战者号告诉你自顶向下设计的危险性。

TDD的困难之处

下面是几个我认为TDD不容易掌控的地方,甚至就有些不可能(如果有某某TDD的Fans或是ThoughtWorks的咨询师和你鼓吹TDD,你可以问问他们下面这些问题)

  • 测试范围的确定。TDD开发流程,一般是先写Test Case。Test Case有很多种,有Functional的,有Unit的,有Integration的……,最难的是Test Case要写成什么样的程度呢。

    阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (29 人打了分,平均分: 4.55 )
Loading...
那些炒作过度的技术和概念

那些炒作过度的技术和概念

StackExchange.com上有一个贴子在评论着最近20年来被炒作过度的技术,对于出现的结果,大多数赞同,也有一些不赞同。下面我从前15名挑了10个(Java的WORE我去掉了,TDD我也去掉了,因为我觉得他们应该没有炒作过度,而且都不错),按原贴的顺序罗列如下:(后面的一些评论是我加的,欢迎大家讨论)

Top 10 过度炒作的技术和概念

  • Unified Modeling Language (UML) – UML是一个程序员交流想法的不错的工具,但是他离程序员真正需要的设计工具还差得很远,比如:设计是否符合需求、架构设计、数据流等等。只有为数不多的程序员使用这个工具交流想法,而没有用在具体工作中。
  • Sharepoint – 现在N多的公司都在用微软的这个东西做公司内部的Intranet。不过安装和维护起来,代价相当的大。但是其市场做的很成功,不对技术上来说对技术人员来说,相当的蹩脚。Sharepoint的设计没有认真地分析过业务流程,仅仅是一个文档存储地。看上去我们似乎可以做任何的事,但是如果你要用其来管理你的项目和track你的项目问题,你会发现其是无比的难用。
  • eXtensible Mark-up Language (XML) –  XML嘛,以前说过很多了(XML1 XML2)我们用他来做和程序数据封装,用来做配置文件,用来做网络传输格式。我们的程序处理起XML来,又慢,又不经济,没有工具,几乎无法维护XML文件。XML用来做数据封包真是很不经济,Yaml和JSON那个不比它简单?用XML来做程序配置文件不知道是谁想出来的主意,相当的愚蠢,看看Unix/Linux下的配置文件,简单易读,相当容易维护。真是高科技啊。
  • SOAP, XML-RPC, WSDL 的 Web Services – 这个东西前几年炒的很凶。所有人都相信,这是程序员的未来。可惜的,其中的复杂和不一致,相当的令人恶心。SOAP的那个S居然还是Simple!看来,扯上XML的都不会是什么好的东东。不过,个人认为,CORBA比他更恶。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (27 人打了分,平均分: 4.26 )
Loading...
一些杂项资源

一些杂项资源

以前给大家介绍过一些非常有意思的杂项资源,今天再给大家介绍一些。(虽然没有上次的多,也算是一个新年礼物吧)

  • 首先,如果你想在你的web页上做一个小提示,你不妨到http://projects.nickstakenburg.com/tipped上看看,各种各样的提示风格,很不错。而且兼容于四大主流浏览器——Chrome, Firefox, IE, Safari。

image_thumb47

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (8 人打了分,平均分: 4.38 )
Loading...
为什么敏捷方法能在软件开发中行之有效?

为什么敏捷方法能在软件开发中行之有效?

文章来源 – Martin Fowler 和 Neal Ford 在 Paris – USI 2010 的演讲

有很多的书籍讨论敏捷方法是怎样工作的(How it works?),在这个主题演讲中,Martin Fowler 和他的同事 Neal Ford 讨论了敏捷方法能够在软件开发项目中行之有效的原因(Why it works?)。作为敏捷方法的发起人和传道者,Martin Fowler 和 ThoughtWorks 一直试图从理论层面证明敏捷方法的可行性,同时不厌其烦地解答着客户们的各种困惑,正如他们所说,敏捷方法中的很多概念不是特别的直观,除非人们真正实践过一段时间,否则有些概念很难从字面上去完全理解。

Martin Fowler 谈到一个有意思的现象,那就是今天许多人们口中谈论的敏捷方法,和最初的敏捷方法大相径庭,他把这种现象称为“语义扩散(Semantic Diffusion)”,大意是某种思想在传播的过程中,在逐渐扩散的同时,其语义也渐渐变得模糊。在敏捷开发领域里,“语义扩散”导致的一个问题是,在一些使用敏捷方法的项目或者公司中,我们甚至无法辨别出敏捷方法的影子,原因是很多人没有真正地理解敏捷方法,也就不能够正确地运用和实践,从而也就无法真正了解自己是否能够从敏捷方法中获益。

以下是为什么敏捷方法行之有效的原因:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (14 人打了分,平均分: 4.71 )
Loading...
结对编程的利与弊

结对编程的利与弊

cccpairprogramming结对编程(Pair-Programming)可能是近年来最为流行的编程方式。所谓结对编程,也就是两个人写一个程序,其中,一个人叫Driver,另一个人叫Observer,Driver在编程代码,而Observer在旁边实时查看Driver的代码,并帮助Driver编程。并且,Driver和Observer在一起时可以相互讨论,有效地避免了闭门造车,并可以减少后期的code review时间,以及代码的学习成本。

阅读全文 Read More

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