[转]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

好烂啊有点差凑合看看还不错很精彩 (10 人打了分,平均分: 4.50 )
Loading...
Stack Exchange 的架构

Stack Exchange 的架构

近日,Stack Exchange系统管理员blog上发布了一篇关于Stack Exchange的架构一瞥,其包括了Stack Overflow, Server Fault 和 Super User的 Stack Exchange 网络。注意最后一个关于人员的配置。希望能给大家一些相关的参考。

网络流量

  • 每月9千5百万个PV
  • 每秒800 HTTP 请求
  • 每秒180 DNS 请求
  • 每秒55Mb 的带宽

数据中心

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (3 人打了分,平均分: 5.00 )
Loading...
WordPress是怎么赢的?

WordPress是怎么赢的?

一个以前在Six Apart工作4年的产品经理Byrne Reese发布了一篇文章阐述为什么WordPress成为了赢家。其在文章中比较了WordPress和其主要竞争对手产品Movable Type。我觉得其中有可取之处,本想全文翻译的,后来觉得文章太长,翻译太花时间,所以,我把文章中的观点总结如下。

作者例举了如下为什么WordPress会赢的理由:

一、Movable Type许可证,而WordPress是开源的

2004年,Movable Type修改了其许可证,这一举动激怒了所有Movable Type的用户,于是大家纷纷转投Wordpress,这是WordPress最终成为赢家最大的原因。就算是Movable Type有着优越的设计,优越的功能,还有优越的技术支持,但是面对的是一个完全免费的产品也没有办法。因为WordPress是开源的,开源就意味着完全免费,而Movable Type一开始也是免费的,但是其许可证策略有着很不确定的因素。(注:2007年Movable Type发布了开源版本)

二、WordPress很容易安装

WordPress的安装过程很简单,只需要不到5分钟,比起Movable Type来说,这太受用户和推广商欢迎,你几乎不需要去碰后台的那些Web设置。(注:不仅如此,WordPress的升级和安装插件和风格的用户体验也是非常的不错)这就是为什么大家都喜欢WordPress的原因,就算是其功能比Movable Type少了又少。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (6 人打了分,平均分: 4.00 )
Loading...
你会问问题吗?

你会问问题吗?

在工作和生活中,总是会有很多人问题我很多技术方面的问题。有一些时候,问问题的和答问题的总是会有一些不爽的事情发生。如下面的几种情况:

  • 比如:“我的电脑老是蓝屏,怎么办?”,通常这样的问题90%以上的回答是:“重装吧”。这让问问题的人感到很沮丧,但你不能不承认那不是答案。而且有时候让人无法解答,比如:“我的makefiel出错了,你帮我看看我的makfile”,我通常会非反问,报了什么错吗?
  • 另一种情况是,回答问题的人首先先对问问题的人的抱怨,你问的问题就不对,或是,你问的这个问题是什么意思,而导致问问题的人却在不停地解释,结果花了好长时间来讨论问题本身是什么。
  • 还有一种情况是,问的问题太简单了甚至太白痴了,比如你自己试一试或是读读文档就知道了的问题,或是问这个问题直接表明了你的无知或是懒惰。这种问题会相当影响别人对你的印象。
  • 第四种情况是,提问者滔滔不绝,扯这扯那,讲了一大堆,听得听累了。最后都不知道你要干什么。

所以,怎么去问问题,怎么问一个好的问题,是一个很重要的事。你提问的技术直接关系到了你是否能够很快得到你满意的答案。

这里有一篇文章推荐给大家《How To Ask Questions The Smart Way》,中文版在这里《提问的智慧》,我把其中的几个亮点总结如下:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (13 人打了分,平均分: 5.00 )
Loading...
提高编程技能最有效的方法

提高编程技能最有效的方法

StackExchange.com上有两个贴子(贴子一贴子二),贴子名叫“What is the single most effective thing you did to improve your programming skills?” – 对你的编程技术提高最有效的一件事是什么?回复的人中给了很多很不错的建议,我把他们总结了一下,十条,相信一定会对你有用。(注意:顺序是我自己按我的个人经验排的)

  • 和比自己聪明的能力比自己强的人工作。学习他们的代码,他们的做事方法,看一看那些人是怎么处理错误的。
  • 总是倾听别人怎么说,无论那个的资历和职位是什么样的。
  • 实践,实践,实践,总是不满意于一开始出来的事。
  • 多问问自己,现在在写什么代码?为什么要这样写成这样?还有没有更好的方法?
  • 学习多样的技术,多多比较他们,并一定要了解各种技术的优缺点。
  • 总是问别人问好的问题。
  • 多回头看看走过的路,做过的事,写过的程序,感觉一下他们有多烂。
  • 多读读那些大师写的书。
  • 不要总坐在电脑前编程序,多做做运动,多到户外走走,和非技术人多接触,向他们学习。
  • 把你的想法说出去,看看别人怎么回应的。从别人的回应中学习。

除了这些,下面是我个人想给你的建议——

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (19 人打了分,平均分: 4.63 )
Loading...
预发布环境,Tag发布机制和可重复的部署过程

预发布环境,Tag发布机制和可重复的部署过程

下面文章由网友吕毅投递,源文是:http://blog.lvscar.info/?p=427

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

周末聚会,无意间聊起建筑行业。自己是搞软件开发的,我们的行业从建筑设计/施工过程中借鉴了大量的概念,隐喻,名词。可以说软件就是现实中伴随整个人类历史发展的“建筑”在虚拟空间中的投影。有个两年前问过其他朋友的问题,这次友人又再次提起,“为什么建筑设计过程中没有普遍性的采用版本控制呢?” 瞎扯了一干各种原因后,我们几乎同时想到一个名字”Joel”,建筑设计行业或许缺乏像Joel Spolsky一样十数年如一日,把自己丰富的经验和深入的思考转化成一篇篇文章以向新人传授软件开发过程中那些容易被忽略的概念。高傲的黑客们会对CMMI之类的认证抱以鄙夷之情,但对Joel整理出的12条写出更好软件的”最佳实践”,大家甚至把此称为审视其他团队开发过程的“Joel TEST”以推崇

这12条测试如下:

1. 是否启用版本控制?

2. 是否可以一步构建?

3. 是否进行每日构建?

4. 是否有bug跟踪列表?

5. 是否在修改bug后,才开始写新代码?

6. 是否及时更新工作计划?

7. 是否在开发前编写了大家一致认可的功能文档?

8. 是否有安静的工作环境?

9. 是否在使用最好的软件开发工具?

10.是否有专职测试人员?

11.是否在面试时以实际编写代码来检查求职者?

12.是否利用陌生人进行可用性测试?

你所在的团队符合其中的几条呢? 觉得这些条目太一般,软件开发原本就该如此? Joel Test写于十年前,一个Windows XP,Mac OS X,Ubuntu都还没有面世的年代。 如果你觉得这些条目有些过时了,Google中搜索“Joel Test”,你可以看到这十年内很多对此进行更新的尝试, 比如这两个页面“The Joel Test Update for 2010″,“Joel Test for web dev”.

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (6 人打了分,平均分: 4.17 )
Loading...
欢迎攻击酷壳

欢迎攻击酷壳

相信大家都发现昨天下午2011年2月16日,下午从2点到6点,酷壳基本打不开。原因是服务器受到了黑客攻击。从互联网上几乎ping不通服务器(丢包率60%以上,ping时延巨大,是平时的10倍以上),我勉强登上服务器查看了系统负载,相当低,于是停止了Apache,发现网络ping马上恢复正常。于是,我启动Apache,再使用iftop查看了一下TCP链接的带宽消耗,发现有那么一两个链接把服务器带宽全部吃完,于是我记录了下IP地址。攻击在下午6点时准停止,就像我们正常下班一样。

酷壳受到很多攻击,不过,基本上都是一些注入式的攻击,都是想取得一些权限的攻击。这是第一次受到不以取得权限为目的,而只在以影响酷壳正常运转的攻击。

我不竟想到了几个问题:

  1. 为什么要攻击?这只是一个技术blog,这样的攻击目的是什么?
  2. 黑客攻击的背后总是有相关的利益冲突的,不会是没有动机的攻击。

所以,我一直在想,是什么样的利益冲突导到酷壳被攻击的?这个BLOG得罪了谁呢?我这个小小的个人的BLOG触动了谁的利益呢?任何事情总是有因果关系的,我很不自然地想到了最近我发布的几篇文章……

欢迎攻击酷壳!我很乐意看到某些人生气的样子。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (24 人打了分,平均分: 4.71 )
Loading...
Web开发人员速查卡

Web开发人员速查卡

无论你是多牛的程序员,你都无法记住所有的东西。而很多时候,查找某些知识又比较费事。所以,网上有很多Cheat Sheets,翻译成小抄也好 ,速查卡也好,总之就是帮你节省 时间的。之前给大家介绍过Web设计的速查卡25个jQuery的编程小抄,还有程序员小抄大全,今天转一篇开发人员的速查卡,源文在这里。下面的文章我就不翻译了。

HTML Cheat Sheet

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (10 人打了分,平均分: 4.90 )
Loading...
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...