谈谈极限编程XP（pt1 结对编程）

谈谈极限编程XP（pt1 结对编程）

软件业发展了几十年，软件人们一直在摸索着软件设计的完美方案。从早期的无序开发到瀑布式流程，再到现在的rup和xp，软件人们一直奋斗着。前段时间的老新闻了，vista的发布日再次推迟，本来计划会赶在今年暑期之前，现在至少要到明年了 。记得初识vista是02还是03年，那时候还叫longhorn，有次看朋友的电脑装了个内部测试版，感觉界面很眩，挺开心的，想想等不了多久久就能爽爽新系统了，然而这一等却是五年。据报道vista已经花了M$50－60亿美元了，这次的推迟发布造成了5亿损失，也只有Gates玩的起。对比下IBM的office软件，浪费了9亿美元，vista估计肯定能坐软件失败的头把交椅了。

极限编程是最近一些年来软件人们经常讨论的话题，它以其另类性而独领风骚。传统的软件设计比如RUP迭代开发是先计划，然后细化，接着编码测试，到最后的安装交货；极限编程更注重于程序员本身。它提倡在计划初期就构建代码，结对编程，测试先行，简单设计，现场用户等等。XP注重的核心是沟通，简明，反馈和勇气。因为知道计划永远赶不上变化，XP并不需要软件开发人员在软件开始初期做出很多的document，写出很多的report；提倡只制定一个大致的plan，此时编码测试等工作已经开始了，然后随着各种需求的出现逐步完善plan。XP提倡结对编程即1个小组2个人员共同书写代码，甚至这两人坐在一台桌子旁共用一台电脑。XP提倡测试先行，为了将以后出现bug的几率降到最低···

先说说结对编程（pair-programming）。去年有机会尝试了一下结对编程，体验了XP在实际project中的作用。当时临时准备用JSF做web层的开发，所用到的开发工具为IBM的RAD（rational application developer）。之前对JSF的了解纯粹只是概念上知道这么一个MVC框架，而公司里面并没有任何人很精通JSF，之前我们做的一些project都是基于JWS的胖客户端。选择JSF是因为研究了JSF和STRUTS的架构，感觉JSF更加合理，且其将会是J2EE 5.0的标准。

确定需求之后制定了个大致的流程，画了一张简单的流程视图便开始了编码。当时公司实际写此软件的人分处香港和深圳，其中深圳的4人，香港的10人。分配工作之后深圳这边2个用JSF写UI，1个做需求测试，一个负责文档；香港那边2个做JSF层，1个美工，4个逻辑层编码及数据库，1个整合各层，2个测试。理所当然，我和深圳这边还有个同事组成了一个subgroup，受极限编程影响，我们选择了结对编程。开始的5天为学习熟悉JSF时期，我们采取的方法是分头学习，遇到想不明白的地方即提出讨论。为了使讨论尽可能便宜，我们选择了2张紧靠的办公桌。实际证明这种方法不错，大概用了3，4天我们就熟悉了JSF的实际使用方法。有时候人是存在思维障碍的，有些简单的东西可能想错方向而导致时间资源的浪费。一个礼拜后接到了新的UI之后我们便开始了实际的编码操作。初期我们决定先分开各自写页面，因为此时的工作比较简单，任何涉及到提交请求的先做成空链接，遇到比较困难的组件，则先写在纸片上，在每天固定的时间讨论具体的实现方法并在不同的web浏览器进行了一些实际的测试。在我们两人均无法解决的时候则通过jabber跟在香港的同事进行交流，共同寻求处理方法，包括寻找网络资源等等。页面的jsf化处理进行的很顺利，比预定日期提前了2天。随后我们开始了BackingBean的具体编写，包括虚拟一些数据进行单元测试。这时候我们更多的是在一起进行开发，轮流编码。结对编程客观上减少了我们实际编码期间的片面性，从而减少了以后进行debug工作时候所花费的时间。还有个注意的就是注释的使用，因为我们并不打算专门写开发的文档，为了以后查阅，我们为每个方法都写了比较详细的注释。结对编程还有个很显然的好处就是可以使程序员更全面的掌握应用软件，学习同伴的技巧，我就通过这次的结对编程知道了更多RAD工具的一些小技巧。最后，在UI完成的时候我们比在香港的同事快了3天，他们是采用传统的各自编码进行的。提个注意点，如果两个程序员都比较喜欢聊天还是不要结对编程比较好。

惯例，帮自己的网站宣传下 www.jsfchina.org