Every object is linked to a prototype object from which it can inherit properties.

于是，如果我们试图从一个对象中获取属性，而该对象上缺少这个属性，它就会查找自己的prototype对象，如果这个prototype对象上还没有，然后就会继 续往prototype对象的prototype对象上找，一直找到根上--- Object.prototype。 这种prototype的关系是动态的，一旦给某个prototype上加了一个属性，在所有基于此prototype的对象上就都能看到这个属性。

利用这个特性可以完成很多事情，比如添加公共方法和动态的提供对象上的方法增强。

《JavaScript, The Good Parts》这本书中对于第一点给出了很多例子，例如实现Function的curring

Function.prototype.method = function(method, func){
	this.prototype[method] = func; 
	return this;
};

Function.method('curry', function(){
	var slice = Array.prototype.slice,
		args = slice.apply(arguments),
		that = this;
	return function(){
		return that.apply(null, args.concat(slice.apply(arguments)));
	};
});

用Jspec给它写个测试看看:

describe 'method should be able to be curried'
  it 'should curry add method'
	var add = function(number1, number2) {
		return number1 + number2;
	}
	
    var curried_add = add.curry(7)
	curried_add(8).should_be(15)
  end
end

同理，我们也可以自己给Array上增加一些便利的方法，比如select:

describe 'functional test'	
	before_each
		function People(name){
			this.name = name;
		}
		
		friends = [new People("jacky"), new People("xiaodao"), new People("jane")]
	end
	
	it 'should do select'
		var jane = friends.select(function(people) { if (people.name == "jane") return people; })
		jane.name.should_be("jane");
	end
end

实现代码如下:

Array.method('select', function(f){
	var i;
	for(i = 0; i < this.length ; i+=1){
		var result = f(this[i]);
		if( result != null){
			return result; 
		}
	}
});

也可以把《Scala程序设计》中第七章讲隐式类型转换的例子重写一下:

Number.method('days', function(when){
	var date = new Date();
	switch(when){
		case "ago":
			date.setTime(date.getTime() - this * 3600 * 1000 * 24);
			break;
		case "after":
			date.setTime(date.getTime() + this * 3600 * 1000 * 24);
			break;	
		default:
	};
	return date;
});

然后就可以这样用了: var date2DaysAgo = (2).days("ago");

项目里面曾经有这样一段遗留代码，嵌在了jspx页面里面：

function getDropDownOptions(data) {
	$.ajax({
		url: "/dropdownoptions.json",
		dataType: "json",
		cache: false,
		data: data,
		success: function(data) {
			$("#journals").html("");
			for (idx in data.journals) {
			    $("#journals").append("" + data.journals[idx].name + "");
			}
			$("#journals").removeAttr("disabled");
		}
	});
}

$(document).ready(function() {
	$("#series").change(function() {
		$("#journals").attr("disabled", "disabled");
		$("#journals").html("Loading journals...");
		getDropDownOptions({
			"journalType": $("#series").val()
		});
	});
});

实现的功能很简单，就是个级联下拉框，第一个下拉框#series被选中以后，第二个下拉框#journals先被禁用掉，等异步请求返回数据之后，再把数据填充到下拉框里面，并将之使能。

看上去代码还是很好读懂的，但测试却是个大问题。后来就发现了jspec 这个好东西，于是我想，那就把这段代码重构一下，然后加上测试吧。

开工

要给一段遗留代码补测试，首先要弄明白要测试的功能是什么。上面这陀代码实际上干了三件事情: 1. 禁用#journals下拉框；2. 发起ajax请求；3. 拿到返回的json对象，用它填充#journals下拉框。也可以归为两类，一类是发送ajax请求，一类是操作dom。我想先把操作dom的这部分功能加上测试，比如禁用下拉框(dropdownmodel_spec.js):

describe 'dropdownModel'
  	before_each
	    html = $(fixture('dropdownlist.html'))
	    dropdownModel = new DropdownModel(html)
  	end

  	it 'should prepare for series change'
    	   dropdownModel.prepare()

	   journals = html.find("#journals")
	   journals.should.be_disabled
	   journals.find("option").should.have_text('Loading journals...')
  	end
end

在上面的代码里，首先是用fixture()这个方法构建了一个fixture，把dom传给DropdownModel的构造参数，让js和html解耦。fixture的加载路径是在测试页面中配置的，可参考jspec文档。然后是DropdownModel：

function DropdownModel(dom){
	this._dom = dom;
}

DropdownModel.prototype = {	
	prepare : function(){
		 var journals = this._dom.find("#journals");
		 journals.attr("disabled", "disabled");
		 journals.html("Loading journals...");
	}
}

但测试页面显示有failure，这是因为fixture页面还没有写好，这里写个最简单的页面就好了，只要带有id为journals的select元素就行。测试通过以后，我们可以继续把用json数据填充下拉框的测试也写完。先构造一个json字符串:

{
"journals" : [
	{
	"id" : "0",
	"name" : "All journals in series"
	},	{
	"id" : "3009",
	"name" : "Alzheimer's Research"
	}]
}

然后是测试:

it 'should populate journals'
	journal_json = fixture('journal.json')
	journal_data = eval('('+ journal_json +')')

  	dropdownModel.populate(journal_data)
	
	journals = html.find("#journals")		
	journals.should.have_many 'option'
	journals.find("option")[0].should.have_text("All journals in internal series");
	journals.find("option")[1].should.have_text("Alzheimer's Research");
end

实现就略过不提了。接下来就是测试发送ajax请求的部分，这个类对外只有一个接口，比如叫做changeSeries吧，它要先调用model的prepare方法，然后发请求，然后把json对象做参数，调用model的populate方法。JSpec提供了mock ajax request的方法，于是测试也变得很简单了。比如:

describe 'heading'
  	before_each
	    html = $(fixture('dropdownlist.html'))
	    model = new DropdownModel(html);
	    controller = new DropdownController(model);
  	end
	
	describe 'change series'		
	   it 'should call model populate journals after a success ajax call'
	       journal_json = fixture('journal.json')
	       mock_request().and_return(journal_json, 'application/json');
		
		controller.changeSeries();

		journals = html.find("#journals")		
		journals.should.have_many 'option'
		journals.find("option")[0].should.have_text("All journals in internal series");
		journals.find("option")[1].should.have_text("Alzheimer's Research");
	    end
	end
end

实现代码如下:

function DropdownController(model){
	var _model = model;
	
	this.changeSeries = function(){
		 _model.prepare();

		 getDropDownOptions({
		 	"journalType": $("#series").val()
		 });
	}
	
	function getDropDownOptions(data) {
		var model = _model;
		$.ajax({
			url: "dropdownlist.json",
			dataType: "json",
			cache: false,
			data: data,
			success: function(data) {
				model.populate(data)
			}
		});
	}
}

结束语

到此为止，原先嵌在页面中的一段js代码已经分离了出来，并根据职责的不同，拆分出了两个类，一个操作dom，一个处理ajax请求，并且有了针对操作dom行为的两个单元测试，以及针对ajax请求的一个集成测试(如果愿意的话，还可以mock一下model的prepare方法，测试它会被controller的changeSeries方法调用到)。

在这个过程中，我的感触是:

1. JSpec是很牛逼的。提供了如rspec一样清爽的语法；有很大一陀功能强大，也更易读的Matchers，一如hamcrest；有before_each和after_each用；支持JQuery；原生支持mock ajax call；可以用selenium把js测试集成到CI里面去

2. Javascript的可测试性是很重要的，这样才能用低成本的单元测试、集成测试来覆盖javascript的功能，而不是成本高昂的功能测试，或者是傻傻的一味加断点Debug。

(完)

图中的S表示同向变化，O代表反向变化。

针对这种问题，我们常常采用的实践就是分布式、分阶段、分层。

分布式无庸多言。

分层可以理解为按特性划分支，在特性分支中的构建（包括本地和CI），都只跑跟这个特性有关的测试，与之同时，分支和主干之间，必须要频繁（每日）同步，在分支向主干push的时候，要跑主干上的所有测试，在从主干向分支pull的时候，要跑跟分支有关的测试。

这是用来解决团队规模过大，特性之间相互影响的问题。这个实践在团队中曾经用过一段时间，为了不影响某个特性的critical release，专门拉了一条分支出去。每天做同步。但release完了以后分支就干掉了。

分阶段是用来解决构建时间过长的问题。其解决方案是，让一部分价值最高，成功率最高，运行时间短的测试作为提交构建，每次提交的时候，都必须要跑这些测试。在这个基础上，把全部的测试作为全量构建，放到不会有人频繁提交代码的时候运行，防止对工作造成影响。执行的策略是专人轮流负责，红了必须修。

全量构建的通过用来评价提交构建的好坏，如果全量构建经常失败，就把全量构建中的一些测试放到提交构建里面去做；提交构建里面一些价值不高的测试，也可以挪到全量构建里面去。

但在执行分阶段集成或者分层集成策略的时候，每个人也必须意识到，这些策略都是有成本的，是在一定条件下达成的妥协。它所带来的好处是可以快速反馈，但问题是这种反馈是不是真实的？在反馈中发现的问题是否容易修复？实践证明，当全量构建、Trunk上的构建失败的时候，已经远离了问题出现的时机，定位问题、修复问题的代价都增加了。这就是成本，也是风险。如果对全量构建的关注度不够、分支主干的同步频率很低……最终的结果可能就是无法在主干上得到一个稳定构建，最终放弃并回到苦苦等待令牌的老路上来。

还好有了WinApps，于是我就可以体面的在Mac上用Raysource了。但它又带来了新的困扰。一如绝大多数下载工具一样，它即便在退出以后也在后台放一个常驻进程，这一点在Windows还没有太大问题，但在Mac上退出一次以后就再也启动不起来了。。。WTF！

作为一名体面的程序员，我无法接受每次都去ps aux | grep Raysource 再kill进程这样的操作，于是写了这样的脚本[raysource.rb]：

raysource_status = `ps aux|grep peer.exe`.split("\n")
raysource_process = raysource_status.select{|line|
  line.split(" ").select{|piece| piece.eql? 'Files\RaySource\peer.exe'}.length != 0
}
if raysource_process.length != 0 then
  raysource_process_id =  raysource_process[0].split(" ")[1]
  `kill #{raysource_process_id}`
end

然后我只需要再写一个shell脚本，quitraysource.sh，给QuickSilver添加一个Trigger指向 "quitraysource"+"Run in Terminal..."，以后每次想退出Raysource的时候，用快捷键调用那个Trigger就可以了。

从发现Raysource的问题到写完程序花了大概半个来小时，但以我平均两天使用一次Raysource的频率而言，它可以为将来节省大量手工重复操作的时间。

我不知道迅雷、纳米人，乃至IE是不是也存在同样的问题，但如果你曾遇到过的话，希望这个程序对你有用。不知道如何配置QuickSilver Trigger的朋友，可以参看我从前的博客：QuickSilver进阶应用指南

他们项目中每个刚毕业的大学生都跟国外客户谈过需求。

在项目结束的时候，他们培养出了一个能写程序的测试，两个能做测试的dev，一个能管项目的dev，一个能做UI的dev。

想知道这样一支团队是如何炼成的，请期待胡凯 的文章完稿。

于是有了这些脚本。

Firefox.au3

$firefoxClass = "[CLASS:MozillaUIWindowClass]"
$firefoxOpened = WinExists($firefoxClass)
$firefoxExecutable = "C:\Program Files\Mozilla Firefox\firefox.exe"

Func run_firefox()
    If $firefoxOpened Then
        active_firefox()
    Else
        open_firefox()
    EndIf
EndFunc

Func active_firefox()
    WinActivate($firefoxClass)
EndFunc

Func open_firefox()
    Run($firefoxExecutable)
EndFunc

Func wait_util_firefox_opened()
    WinWaitActive($firefoxClass)
EndFunc

Func open_new_tab()
    Send("^t")
    Sleep(500)
EndFunc

MingleCard.au3

#include <firefox.au3>
$cardnumber = $CmdLine[1]

run_firefox()
wait_util_firefox_opened()
open_new_tab()
enter_card_url()

Func enter_card_url()
    Send("http://localhost:8080/projects/projectname/cards/")
    Send($cardnumber)
    Send("{ENTER}")
EndFunc

show.bat

minglecard.au3 %1

把show.bat加入PATH以后，只需要输入show 20这样的命令，就可以直接打开序号为20的这张卡了。

在敏捷中国论坛里我曾说过：

流程专家首先必须是生产专家，这是被丰田重复过无数次的话了。

不懂生产就不知道哪里是现场，
即便知道哪里是现场可能也看不懂，
即便能看懂现场也未必看得到问题，
即便看得到问题也未必能知道问题的根源，
即便知道问题的根源也提不出解决方案。

这样的人跑到团队里边来指手画脚不就是一件令人愤怒的事情么。

这次看到Bob大叔给了个很中肯的评价：

Scrum does not define any technical disciplines so, strictly speaking, Scrum Masters do not need to be technical. However, if technical disciplines (like TDD, Continuous Integration, Refactoring, etc.) are not used, then the code produced by the scrum team will very quickly rot into a festering pile, leaving the team entombed in an ever deepening and thickening tar pit. Therefore _effective_ scrum teams must be good at technical practices; and someone must play coach for those practices. That technical coach might be the scrum master, or it might be the lead developer.

但总是会看到有人出来扯看上去很美的淡：

根本问题并非“Scrum Master 是否需要技术背景？”，而是进行敏捷实施的团队是否需要相关的技术指导， 如果团队没有技术指导方面的需求，Scrum Master 自然无需太多的技术背景！ 敏捷开发是为了随需应变，而不流于形式； 敏捷实施也应如此，Scrum Master 应各有所长、各司其职！

在用系统反馈图的方式来剖析问题成因、改善点、观测点的时候，有一点相当重要，那就是要头脑风暴。每个人都有自己的知识局限性、认知差异，所以有的人会摸到象腿，有的人会摸到身子，或者尾巴。只有每个人都可以无阻碍的把自己的理解呈现出来，这个团队才能建立一个趋向于分析系统全貌的思考方式。

但是该怎么做呢？mvn release这个插件已经把所有步骤封装在一起了，除非先能拆开。但改源码重新发布的成本又太大。然后又想到用管道捕获命令行输出，当程序读到某些字符的时候就调用批处理文件启动AutoIt来操作VPN，貌似可以达成需求。

于是我就稀里哗啦写了些代码。然后贾杨就告诉我他想到更简单的办法了。这个办法的关键是两点：1. 理解maven的生命周期。2. 理解Profile。

我们在pom.xml写了一个Profile，指定用maven-groovy-plugin（当然也可以用别的，比如mavn-ant-plugin），让它在某个phrase执行断开VPN的脚本，在另一个phrase执行连接VPN的脚本。这个profile默认不启动，在本地的settings.xml里面加这么一条，即告完结：

<activeProfiles>
     <activeProfile>Beijing</activeProfile>
</activeProfiles>

修改后的pom文件如下：

<profiles>
        <profile>
            <id>Beijing</id>
            <activation>
                <activeByDefault>false</activeByDefault>
            </activation>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>groovy-maven-plugin</artifactId>
                        <version>1.2</version>
                        <executions>
                            <execution>
                                <id>process-test</id>
                                <phase>test-compile</phase>
                                <goals>
                                    <goal>execute</goal>
                                </goals>
                                <configuration>
                                    <source>
                                        println("======================start disconnect");
                                        "dis.bat".execute().text ;
                                        println("======================end disconnect");
                                    </source>
                                </configuration>
                            </execution>
                            <execution>
                                <id>prepare-package</id>
                                <phase>prepare-package</phase>
                                <goals>
                                    <goal>execute</goal>
                                </goals>
                                <configuration>
                                    <source>
                                        println("======================start connect ");
                                        "connect.bat".execute().text ;
                                        println("======================end connect  ");
                                        sleep 10000
                                        println("======================wait for vpn");
                                    </source>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>

这个事情做完以后，就大功告成了。每每想到日后每一次做release，都可以敲个命令让它自动执行，心情就畅快的很。

回头来看，这个过程的突破点都跟我无关，默默在buzz上推荐了AutoIt，贾杨想到的用profile。有什么难解的地方么？没有。可是项目团队却一直在用这个方式工作。也许是我的忍耐度比较低；也许在我加入项目之前大家都在忙着做其他更急迫的事情，慢慢就习惯了。

我认为忍耐度低是件好事，这表示我在坚持我认为正确的事情，并努力把它做好。