Daniel's blog

.Net - Just cool!

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
前几月有幸跟从项目经理来了一段eXtreme Programming(极限编程),感觉倍爽,而且发自内心地认为这是能为软件开发人员带来福音的好东西,真希望能有更多人投身进来展开XP的实践。

作为Agile Development(敏捷开发)的一种,XP通过结队编程(也是争议相当大的方式)使每行程序都至少经过两双眼睛的检查,比传统的Desktop Review更有意义。原始的那种让程序员互相检查程序的方式是一种相当形式化的手段,其实效果不好,因为检查者无法像开发时那样完全融入程序的逻辑之中,很难从中发现业务逻辑错误,多数情况下根本都不会仔细去看。事实上在两个人同时编写程序的过程中,每个人的注意力都会比自己一个人编程时更加集中,考虑问题更加全面,互相提醒需要注意的事项。当背后有一双眼睛看着自己编程时,程序员会不由自主的顾虑起自己的编程风格是否规范、注释是否充分,以免被当场被同事指出问题,这也能提升自己的开发信心。

当两个人共同开发时,充分的交流(语言交流)所带来的效率是传统纸张文档所不可比拟的,也更容易深入业务逻辑,发掘问题并拓展解决方案的思路,增进团队间的友谊。而且通过大量的交流和沟通,两个人在技术水平和业务能力上的提升都会远比一个人闷着头干活儿快得多。不要吝啬于和自己的partner交流,因为就算是经验老道的程序员也能从新手身上学到有价值的东西,开阔思路,对公司整体员工质素的提升也是很好的促进。

结队编程保证了任何一行程序都有两个以上的人了解,这对公司抵抗人员流动风险的能力有极大的助益,由于参与结队的成员是经常在变化的(通常半天可以重新组队一次),所以对于同一块程序,所有相关人员全部离职的可能性相当低。对于一本需要修改的程序,只要有程序员是熟悉它的,无论过了多久,也比一个“新手”做起来快,毕竟思路都是当年自己走过一遍的,一个对这本程序完全陌生的程序员必然需要更长的时间去挖清楚其中的逻辑和实现风格,无形中加大了公司维护程序、升级程序的成本。
当然,结队编程并不是什么灵丹妙药,其中有一个相当关键的要素就是程序员们都是抱着期望提升代码质量和自身素质的目的参与到项目中的,如果所有的程序员都是以混日子、磨洋工的风格工作,以完成任务了事为最高使命的话,那无论是么开发方式都不会有任何的帮助,整个开发团队只会步步走向崩溃。

也有人诟病结队开发的效率问题,认为传统的两个人一起打键盘的速度随便怎样都要比统一时刻只有一个人打字的速度要快得多,我的看法是这样,开发过程中也许表面上会慢,其实由两个人同时开发所能避免的错误和返工将是非常客观的,对于经验并不老道的程序员来说尤其如此,再算上维护的时间和成本,应当说结队开发的效率是只高不低的。
posted on 2005-09-23 17:24  Daniel  阅读(1055)  评论(10编辑  收藏  举报