敏捷开发初体验

声明：本文目的仅限于传达关于敏捷开发的一些体验，这对于刚刚接触敏捷开发的同学也许有一些借鉴意义。我只是把它归于“在ThoughtWorks的日子”这个系列。至于是否有资格放到首页，不必根据系列的名字判断（这个系列其他文章也没有放到首页）。关于这方面的讨论就停止吧。
至于我是不是炫耀自己去了ThoughtWorks，如果不是过分心理有问题我想不会这样去揣度别人的。
技术讨论欢迎，其他问题请移步。楞出来“欲盖弥彰”这样的评论，我实在是觉得匪夷所思了——难道我去ThoughtWorks之后感觉很好需要掩饰吗？
我删掉了几个评论，这不是第一次也不是最后一次，我无法忍受自己挤出时间来写一些文章分享还看到这种冷嘲热讽——有这个时间大可以去做点更有意义的事情。

昨天(Dec. 09)是入职第2天.上午分配到跟另一个同事一起去做将某开源软件从Java移植到.NET平台上,即转换成C#代码.下午真正体验了一把pair programming.给我印象最深的一句话就是:那就现这样吧,不行再改.而且重要的是在说这句话的时候没有压力,不像是妥协而是一种从容的选择.还有一件事,就是有时候事情可能真的不像是想象的那样困难.

我们要做得是一个代码转换器:将JUnit代码转换成NUnit代码.乍一听仿佛特别复杂.但是,我们需要的并不是一个完美的解决方案,我们可以用工具转换大部分代码,然后剩下的手动完成.我们将问题做了分解:将package语句替换为namespace;将import语句删除(而不是自动添加using);添加using nunit framework语句,等等.架构也非常简单,输入为List<string>通过一个转换器,最终转换为输出List<string>.我一开始考虑使用Visitor模式+Interpretor模式实现,因为我之前做过一个流程图转XML文件的系统,就是使用了这个方案.但是后来的开发并没有证实这两个模式的必要性.我并没有提出来,主要是考虑到不想在一开始将事情搞得过于复杂.但是我提出过是不是需要一个全局的Context用来保存中间转换结果,但是这种设计还是会比传递参数复杂一些,所以我们选择了后者.

我们使用的是TDD的开发方式,开发过程倒是还算顺利.只说一下几个有争议的地方吧.

1. 跨行语句的处理
   我们的设计是基于行作转换.但是我们知道Java语句是可以跨行的.跨行的处理我们的设计框架并非不可以解决,只是比处理单行要复杂得多.我们最终决定先不处理跨行的情况,因为这个软件毕竟只是我们内部使用的一个工具.
2. 是否应该使用Composite模式来组织转换规则
   我们将应用于其上的规则称为IConverterRule,所有具体规则都实现这个接口.因为我们最终是要将所有的(至少大部分)转换都要施加到所有的文件上的.如果将其实现为Composite模式是比较自然的选择.但是这样会使得设计稍微复杂一些,因为要在里面添加一些维护叶子的接口.如果只是让总的规则集合实现IConverterRule则不会带来任何别的益处.最后放弃了这个方案.

今天开始移植源代码部分.我们采取的方案是测试与代码交替移植的方式:即先移植一个测试,再移植相关的源代码,再移植一个测试,再移植源代码.不过光源代码就有500多个文件,工作量还是蛮大的,而且重复工作比较多.我本以为这一部分没有必要PP了,事实证明即使这样的工作PP起来对效率也是有好处的.

中间休息跟韩锴聊天,他提出非单元测试部分我们可以看看能不能也先用工具转换一下再做手动修改,并告诉我们一个Unix下的文本处理工具awk.我到主页浏览了一下,今天没有尝试.

PP可能会比较累,我是有心理准备的,但是到真的实践中还是发现比我想象的还要累.我们不得不每一个小时左右休息一会儿.而且今天下午最后一节几乎坚持不住了:(