BDD（behavior driven development）行为驱动开发。敏捷开发的一种方式。

维基的解释http://en.wikipedia.org/wiki/Behavior_Driven_Development

 大概BDD 就是个基于行为的设计方法。其实TDD应该也可以算是设计方法吧。不过他们各自的关注点不一样。

例如TDD可能比较贴近功能点，而BDD以我拙劣的理解能力看来，就是换了个yy方式吧，可能是为了让开发能够从测试的怪圈里跳出来，从而只关注这段程序应该做什么，要做什么。而不是关注在这个数组边界是多少，数组类型是什么，从而写对应的单元测试以保证这些功能点，业务规则，甚至是程序规范这些细致的点。

从下面这篇文章看来

http://www.ibm.com/developerworks/cn/java/j-cq09187/

其实BDD的代码也是非常有特色的 不再是Test开头都变成Should开头了。呵呵。个人感觉，这样一种行为驱动，似乎就是将需求细分成很多功能和系统行为，边设计边开发。写的稍微粗点的话，这又和敏捷的userstory有什么区别呢？

然而userstory 其实又可以说是用户的简单的需求卡。那么这样追溯下去其实就是拿着一个有条理的需求边设计边开发而已。

可能框架提供了很好的环境和接口。由于我没有实践和经历过BDD，单从此时有的材料纸上谈兵一下，感觉上似乎BDD的结果就是测试保证了功能点的功能结果。无形加重后期测试成本。但是TDD，如果测试设计的好可以在单元测试过程中覆盖到很多程序员一些不良习惯，粗心大意造成的问题。。

就这样原始追求发展，发展后有复古回归原始。有点像7，80年代流行喇叭裤，8，90年代流行窄脚裤，直筒，90年代末到21世纪初又开始流行喇叭裤，现在2008，2009年了又介于喇叭裤和窄脚裤的过渡期间。

感觉上这BDD有点像行为艺术，哈哈。

其他的一些参考：

http://www.javaeye.com/problems/2221

http://tech.it168.com/d/2008-03-10/200803101401922.shtml

http://www.infoq.com/cn/news/2008/02/unit_tests_forests_n_trees

1. Framework knowledge (架构知识)

架构是大型网站开发的重要部分。开发者已经从Rails, Django等公司提供的网站架构工具中收益，因为架构工具可以帮助完成那些需要一定编程知识的重复性的任务。如果你拥有领先的架构技术(像Rails, Django, CakePHP, Symfony等)，你的择业面将非常广阔。

2. Widget Development (窗体小部件开发)

　窗体小部件(Widgets)是一个嵌入网页的迷你应用程序，通常也可以下载到Windows或者Mac桌面下运行。它让数据变得便与携带而且更具交互性。比较出名的像Yahoo Widgets和AOL Music Widgets。窗体小部件开发除了需要掌握网络应用程序开发所需的语言知识，还需要精通Javascript和Flash知识。

3. Custom CMS themes (内容管理系统主题定制)

　如今越来越多人开始使用CMS(内容管理系统，例如Wordpress和Drupal)来构建他们的网站。可以想象不可能大家都用CMS提供的默认主题，为了让自己的CMS网站在外观设计上独树一帜，就需要一些专门给CMS开发主题的技术人员。

4. CMS Customizations and plugin development (内容管理系统的定制以及插件开发)

　同样随着CMS的流行，对CMS的功能定制以及插件开发的需求也越来越大。

5. PSD to XHTML services (PSD转换XHTML的服务）

　在建站中，许多公司是先用Photoshop设计好网站的外观原图，然后再转换成XHTML。这需要很强的CSS/HTML知识。

6. Javascript Plugin creation(Javascript的插件开发)

　Javascript的Framework非常流行，因为它使Javascript的代码开发变得简单。就比如说现在流行的Javascript Framework – jQuery，如果你在它的基础上开发优秀的插件，那么你的插件也会跟着流行起来。

7. Facebook/MySpace applications (Facebook/MySpace 应用程序开发)

　Facebook/MySpace两大社交网站在美国红遍半边天。给他们开发应用程序，不用说一定是相当热门的。

8. iPhoneapplications (iPhone 应用程序开发)

　同样给iPhone开发应用程序，也一直都可以被大量下载，因此也是很赚钱的活。

9. E-commerce integration (电子商务一体化)

　如今电子商务网站(像Ebay，Amazon)与在线银行服务系统(像Paypal和Google Checkout的)之间的配合越来越紧密，因此电子商务交易平台的开发也是相当有前途的。

10. Flash and Actionscript Knowledge (Flash和Actionscript知识)

　越来越多的公司采用Flash来制作自己的网站、展现自己的产品，因为精美的动画总是容易吸引人们的眼球。因此Flash动画技术也必然迅速发展。

1， 尽快结束 if语句

例如下面这个JavaScript语句，看起来就很恐怖：

1 function findShape(flags, point, attribute, list) {
2    if(!findShapePoints(flags, point, attribute)) {
3        if(!doFindShapePoints(flags, point, attribute)) {
4            if(!findInShape(flags, point, attribute)) {
5                if(!findFromGuide(flags,point) {
6                    if(list.count() > 0 && flags == 1) {
7                          doSomething();
8                    }
9                }
10            }
11       }
12    } 
13  }

阅读全文…

但如果这么写就好看得多：
1 function findShape(flags, point, attribute, list) {
2    if(findShapePoints(flags, point, attribute)) {
3        return;
4    }
5
6    if(doFindShapePoints(flags, point, attribute)) {
7        return;
8    }
9
10    if(findInShape(flags, point, attribute)) {
11        return;
12    }
13
14    if(findFromGuide(flags,point) {
15        return;
16    }
17
18    if (!(list.count() > 0 && flags == 1)) {
19        return;
20    }
21
22    doSomething();
23
24 }

你可能会很不喜欢第二种的表述方式，但反映出了迅速返回if值的思想，也可以理解为：避免不必要的else陈述。

2， 如果只是简单的布尔运算（逻辑运算），不要使用if语句

例如：
1 function isStringEmpty(str){
2    if(str === “”) {
3        return true;
4    }
5    else {
6        return false;
7    }
8 }

可以写为：
1 function isStringEmpty(str){
2    return (str === “”);
3 }

3， 使用空白，这是免费的
例如：
1 function getSomeAngle() {
2    // Some code here then
3    radAngle1 = Math.atan(slope(center, point1));
4    radAngle2 = Math.atan(slope(center, point2));
5    firstAngle = getStartAngle(radAngle1, point1, center);
6    secondAngle = getStartAngle(radAngle2, point2, center);
7    radAngle1 = degreesToRadians(firstAngle);
8    radAngle2 = degreesToRadians(secondAngle);
9    baseRadius = distance(point, center);
10    radius = baseRadius + (lines * y);
11    p1["x"] = roundValue(radius * Math.cos(radAngle1) + center["x"]);
12    p1["y"] = roundValue(radius * Math.sin(radAngle1) + center["y"]);
13    pt2["x"] = roundValue(radius * Math.cos(radAngle2) + center["y"]);
14    pt2["y"] = roundValue(radius * Math.sin(radAngle2) + center["y");
15    // Now some more code
16 }

很多开发者不愿意使用空白，就好像这要收费一样。我在此并非刻意地添加空白，粗鲁地打断代码的连贯性。在实际编写代码的过程中，会很容易地发现在什么地方加入空白，这不但美观而且让读者易懂，如下：
1 function getSomeAngle() {
2    // Some code here then
3    radAngle1 = Math.atan(slope(center, point1));
4    radAngle2 = Math.atan(slope(center, point2));
5
6    firstAngle = getStartAngle(radAngle1, point1, center);
7    secondAngle = getStartAngle(radAngle2, point2, center);
8
9    radAngle1 = degreesToRadians(firstAngle);
10    radAngle2 = degreesToRadians(secondAngle);
11
12    baseRadius = distance(point, center);
13    radius = baseRadius + (lines * y);
14
15    p1["x"] = roundValue(radius * Math.cos(radAngle1) + center["x"]);
16    p1["y"] = roundValue(radius * Math.sin(radAngle1) + center["y"]);
17
18    pt2["x"] = roundValue(radius * Math.cos(radAngle2) + center["y"]);
19    pt2["y"] = roundValue(radius * Math.sin(radAngle2) + center["y");
20    // Now some more code
21 }

4， 不要使用无谓的注释
无谓的注释让人费神，这实在很讨厌。不要标出很明显的注释。在以下的例子中，每个人都知道代码表达的是“students id”，因而没必要标出。
1 function existsStudent(id, list) {
2    for(i = 0; i < list.length; i++) {
3       student = list[i];
4
5       // Get the student’s id
6       thisId = student.getId();
7
8       if(thisId === id) {
9           return true;
10       }
11    }
12    return false; 
13 }

5， 不要在源文件中留下已经删除的代码，哪怕你标注了
如果你使用了版本控制，那么你就可以轻松地找回前一个版本的代码。如果别人大费周折地读了你的代码,却发现是要删除的代码，这实在太恨人了。

//function thisReallyHandyFunction() {
//      someMagic();
//      someMoreMagic();
//      magicNumber = evenMoreMagic();
//      return magicNumber;
//}

6，不要有太长的代码

看太长的代码实在太费劲，尤其是代码本身的功能又很小。如下：

1 public static EnumMap<Category, IntPair> getGroupCategoryDistribution(EnumMap<Category, Integer> sizes, int groups) {
2        EnumMap<Category, IntPair> categoryGroupCounts = new EnumMap<Category,IntPair>(Category.class);
3
4        for(Category cat : Category.values()) {
5            categoryGroupCounts.put(cat, getCategoryDistribution(sizes.get(cat), groups));
6        }

#

我并不是说非要坚持70个字符以内，但是一个比较理想的长度是控制在120个字符内。如果你把代码发布在互联网上，用户读起来就很困难。
7，不要在一个功能（或者函数内）有太多代码行
我的一个老同事曾经说Visual C++很臭，因为它不允许你在一个函数内拥有超过10，000行代码。我记不清代码行数的上限，不知道他说的是否正确，但我很不赞成他的观点。如果一个函数超过了50行，看起来有多费劲你知道么，还有没完没了的if循环，而且你还的滚动鼠标前后对照这段代码。对我而言，超过35行的代码理解起来就很困难了。我的建议是超过这个数字就把一个函数代码分割成两个。

    在传统的软件过程中，面对逐渐散发出“腐败”味道的设计文档，通常有两种对策，一种是安排专职的文档开发人员，每次在代码中修改设计都及时更新到设计文档中，以保持文档的“新鲜”。其实这种方法也只是一种看上去很美的东西，且不说多数项目组都不会有多余的人手专职做文档开发（有哪个项目组敢在项目还在进行中就说自己的人手足够了？），就算有这样一个文档开发人员，那么是否每次设计上的小修改都会通知到他（她）呢？显然不会，他（她）必须Review每一个开发人员的代码，并与大家随时沟通，发现与原始设计不一致的修改，这样会累死人的。那么是否可以由开发人员自己负责维护与自己工作相关的那部分文档呢？试想一下，当轰轰烈烈地代码编写开始后，或者头顶着产品交付倒计时牌，开发人员是否还有“闲情逸致”时不时停下正在Coding的手去重新修改一下设计文档呢？另一种对策是任由设计文档慢慢“腐败”，把主要力量集中在代码上，毕竟最终交付产品依靠代码而不是设计文档。这种情况下原来花费大量时间完成设计文档纯粹是浪费时间，哪怕是对自己人也没有丝毫用处，如果我是这个项目组中补充进来的新人，看到这样的文档和那样的代码，可能会得精神分裂症。

    所以在敏捷（Agile）的词汇表里已经没有详细设计这个词汇了，取而代之的是“够用设计”，就是所谓的Not less not more， just enough。那么在敏捷这种短迭代周期，快速反馈体系中，是否还有必要编写一份用自然语言或图表展示的详细设计文档呢？Jack W.Reecves在他的论文《什么是软件设计？》中提出了“源代码就是设计文档”的观点，Jack说得设计文档和我本文提到的设计文档还不是同一个概念，我把他的观点引用在这里主要是为了和另一个观点做对比。Jack认为，“任何工程活动的最终目标都是某些类型的文档。当设计工作完成时，设计文档就被转交给制造团队。该团队是一个和设计团队完全不同的群体，并且其技能也和设计团队完全不同”【1】，由此看来，如果源代码不是文档，那么软件开发人员就不能被称为是工程师了，他们就和建筑工地上的工人一样，只是一群Builder。是否可以用源代码代替任何用自然语言描述的文档呢？我看还不太可行，源代码相对于自然语言来说过于晦涩，只有开发人员能够读懂（即便是开发人员，也不是所有人都能理解所有代码），显然制约了源代码作为文档的用途。不是有人在研究用自然语言编程序吗，如果这样的类似自然语言的源代码作为文档，倒是很合适。

    上文提到，有一个与之对比的观点，那就是用测试代码代替源代码作为设计文档，但是前提条件是：使用TDD作为开发模式。很显然，源代码产生以后做单元测试用的测试代码已经失去了作为设计文档的前提，那就是每次迭代的设计文档必须早于或不晚于本次迭代的源代码产生出来。因为作为单元测试的测试代码是为已经存在的源代码量身定做的，并且已经受到这些代码的思维定势影响，失去了“设计”的意义。做为测试先行的TDD本身就是一个分析、设计、实现的过程，而测试代码又是这个过程的产物，测试代码理所当然的就是设计文档了。加之TDD要求在编写任何代码之前要先完成测试用例，这就是说任何新代码（新加的模块）都有配套的测试代码，自然而然的，测试代码就成为了新代码的描述文档，其中包含了如何建立使用新模块以及期望达到什么样的效果，而这正式设计文档的主要功能。源代码不适合取代自然语言的文档，因为源代码过于功能细化，逻辑纷繁复杂，分支和跳转加剧了理解代码的困难，缺乏对整个模块的宏观表达能力。与源代码相比，测试代码显然“单纯”很多，测试代码侧重于使用源代码，通常可以用作源代码的一份sample，所以它对整个模块的宏观表达能力要强于源代码。另外，测试代码通常是线性结构，比较容易看懂，从可理解性上看，测试代码比源代码更接近自然语言，因此测试代码比源代码更适合作为软件的设计文档。
    

    那么测试代码是否可以完全取代自然语言形式的设计文档呢？我看还不行，原因有三：
其一，测试代码虽然比源代码容易理解，但它仍然是代码，不是所有人都能理解的；
其二，测试代码的宏观表达能力还是不如自然语言或图表；
其三，很多人习惯看文字而不是看代码，彻底改变人的习惯很难。
所以在TDD开发过程中，比较好的形式是自然语言的文档和测试代码相结合，用自然语言的文档做一个够用的设计就行了，这个设计只要详细到模块关系这一级别就足够了，各个模块的详细设计就由测试代码充当。

    不管是“源代码就是文档”的观点还是“测试代码就是文档”的观点，目的都只有一个，那就是消除那些浪费人力物力做出来的、没用的、总是散发着“腐败”味道的东西。

[1] Jack W.Reecves. 什么是软件设计. 2002.