IT牛人博客聚合

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

很多敏粉都在说我在是喷敏捷，黑敏捷，向敏捷泼脏水，我只想对这些人说——你们这样的见解很肤浅也很敏感，你们根本就没有认识

查看全文: http://www.udpwork.com/item/6077.html

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

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

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

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

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

S先生回复：据说stroustrup听到重构时的

查看全文: http://www.udpwork.com/item/6074.html

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

敏捷词汇表

我被@吴穹adam邀请进入了一个敏捷词汇表的微群，这个群就是想明确的定义一下敏捷的各种词汇，比如，他们想把TDD定义成就是UT。呵呵。我对

查看全文: http://www.udpwork.com/item/5636.html

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

因为本人经常站在Agile的风口浪尖，所以我有必要也来一个

查看全文: http://www.udpwork.com/item/5505.html

今年春节时，我写了一篇《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（大家

查看全文: http://www.udpwork.com/item/5357.html

本文来自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 水管工吗？ 请进，感谢谢你们这么快就来了——

查看全文: http://www.udpwork.com/item/4361.html

前言说明

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

我在《那些炒作过度的技术和概念》中批评了ThoughtWorks中国咨询师的咨询方法是以一种接近于教条、炒作、洗脑和电视购物的方法（虽然我心底觉得有时候有时候更像传销），当然，批评是没有意义的，所以我也给了中国ThoughtWorks那些年轻的咨询师们一些我认为有建设性的建议。

我在《TDD并不是看上去的那么美》一文中列举了一些在实际中使用TDD可能会出现的问题和难题，以此来告诉大家在使用TDD时需要注意的东西。就像是在《结对编程的利与弊》说的一样，只有真正知道一件事情的利弊，你才能用好它。

当然，这两篇文章都不可避免得招来了ThoughtWorks咨询师和Agile信仰

查看全文: http://www.udpwork.com/item/4349.html

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

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

最近CoolShell上的一篇《TDD并不是看上去的那么美》引起了敏捷社区的高度关注和激励辩论。今天，InfoQ甚至专门举行了一个“虚拟座谈会”《TDD有多美？》，几位国内敏捷社区的名人专门就此问题展开了深入地讨论。不论结果如何，这个纯技术的探讨

查看全文: http://www.udpwork.com/item/4353.html

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

那么，这次就说说TDD吧，这是ThoughtWorks中国和Agile的Fans们最喜欢的东西了。我在原来的那篇文章中，我把TDD从过度炒作的技术剔除了出去，因为我

查看全文: http://www.udpwork.com/item/4252.html

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

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

Unified Modeling Language (UML) – UML是一个程序员交流想法的不错的工具，但是他离程序员真正需要的设计工具还差得很远，比如：设计是否符合需求、架构设计、数据流等等。只有为数不多的程序员使用这个工具交流想法，而没有用在具体工作中。

Share

查看全文: http://www.udpwork.com/item/4188.html

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

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

如果你想让Java变成一个动态语言，你可以试试这个开源项目：http://code.google.com/p/ductilej/

如果你想把你的Windows蓝屏改成红屏或是绿屏，你可以看看这篇教程：http://blogs.technet.com/b/markruss

查看全文: http://www.udpwork.com/item/3932.html

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

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

查看全文: http://www.udpwork.com/item/2073.html