/**
 * first post on 20051124
 */ 

你到底结不结对

话题:结对编程技术  

定义:  

结对编程就是两个人共用一台电脑编程。  

这么简单?简单就用不着俺在下面哆嗦这么一大段了!  

角色:  

结对编程角色有Two:你是Driver,俺是Navigator缠缠绵绵…(俺狂吐@_@)  

活动:  

他们之间要共同:探讨设计方案,设计算法,编写程序代码,完成各项测试。  

当然还可以共同吃饭,打球。(晕,少扯了)  

效果:  

先声明这些效果都是实践证明了的!你不承认?不承认就接着往下看,等着瞧!  

       System.out.println(“  

1.           质量++,  

2.           时间/2,  

3.           忠诚度++,  

4.           信任与团队精神++,  

5.           知识交流=100%,  

6.           促进学习=true 

);  

重定义:  

结对编程技术是一种不需要增加多少投资就能大幅提高软件产品质量的手段。  

有这么便宜的事么?当然有!说不定哪个PLMM哪天就主动要求跟俺“结对”了呢!(怎么了,做梦是人的本能)  

七、八种激励效应:  

刚才是谁不承认来着,是你吧,小样,过来。什么,你承认,,承认也得听俺gong():  

1.          互相督促
使之更勤奋。如果俺表现得不出色的话,肯定要被对方给BS
使之更专心。知道你小子就想着去看什么NBA新闻或去收什么Email来着,嘿嘿,俺盯着你呢。
 

2.         互相协商
必须承认人的智慧服从“分布式认识”规律,不然哪来的“三人行,必有俺徒”?
协商中得以发现一些极其复杂、看似无从着手的问题的解决方案。
任务越复杂,就越需要两个人的智慧。(别问俺为什么不是三个,俺会答不上来的。)
 

3.          互相鼓励
“其实老板对结对编程有些误解。唉,俺只跟你说啊,刚才开会不敢讲。”
“就是嘛,下次大会讲,俺支持你。”
“我们也支持你。”大约有一个班的声音。
FT,又带着耳机去说话了…”

很多人都有想法,但又怕当众出丑或冒犯,结果许多赋有创意和忠实的想法都被扼杀了。现在不同了,因为我们每天都用“结对编程”。  

4.         互相复查
很少有人主动做代码检查工作,最多由“好不知情”的检查员进行。
现在不同了,因为我们每天都用“结对编程”。(少打广告了…)
if(you.check(code)==false){
   
.check(you);
    System.out.println(
“哈哈…”);
}
 

5.          互相纠错
下面几个突然不想写了,其实都很容易理解。不服?不服你写啊!!  

6.          互相学习  

7.          互相信任  

8.          互相娱乐
这个是后来加上的第八条,据说这条还是得票率最高的。  

目标:  

System.out.println(“  

1.           以高质量代码完成任务,  

2.           不会因关键人才流失而造成重大损失,(几个人对系统各部分都了如指掌)  

3.           让员工都开心,  

4.           缩短对新人的培训时间,  

5.           团队更团结,成员间沟通更有效率。  

”);  

这家伙真懒,什么注解都没留下。(不是写了一个么…)  

实践与技巧:  

1.           Driver留点时间去发现和纠正他自己的错误。
“来,把球传给小陈,小王站出来,你去挡差,

FT,真哆嗦,比直播NBA的那个老头还烦!”  

2.           搭档闲着犯困,就把键盘交给他。
都累了怎么办?那就去下几部好片,哈哈
 

3.           讲清自己的习惯。
“我不打中锋。”
“俺远投比较准。”
……遭到一群怀疑的眼光。
“其实俺投篮还可以啦,只是大一篮球考试的时候才连续
13罚不中而已嘛。”  

4.           多说,多交谈。
“你小子传球啥!”“防守积极一点!”
当你们之间缺乏这种交流时,你们在场下郁闷的时间就多了。
 

5.           TDD
不知道
TDD???你完了,你真的完了 

6.           用指挥棒(就是铅笔什么的)来代替手指。
作为职业杀手,怎能在显示器上流下自己的指纹。
 

7.           注意个人卫生,勤洗澡,多吃口香糖。
好耶,还可以吃口香糖,俺也要结对。
 

结合方式:  

下面选了那本书中的一小部分,先抄上来再说。  

外向型-外向型
P骑士(憋着噪子装女高音):要是在这儿用上Decorator模式,这段代码就太棒了。
J骑士(装男低音)我可不这么想,这模式不能用在这儿。
观众们大笑。
P骑士:哦,骑士,你的理由不能接受,我就要用这个模式。  
观众们切切私语。  
J骑士:啊,my friend!我必须承认,你是一个心术不正胡说八道的恶棍。  
两“骑士”拔出“剑”来开始决斗。  

结合方式有好几种,上面只是其中一种。  

俺再打个比方,毕竟不能全部都抄袭撒。比如活跃一点的元素就喜欢“结对”,如OCl等,它们之间的结合而且总是能冒出不少火花(放出能量高)。而HeHr等比较“死板”一点的元素就喜欢“独干”。活跃一点的程序员总是很容易结对,优秀的程序员之间的交流总是非常活跃的,不是么?(大约一次/per30-60s。没话说?嗯啊也可以,别笑,就是这样!)  

七个好习惯:  

System.out.println(“  

注意休息,适当放松,谦虚谨慎,戒骄戒躁,既要自信,又要虚心,交流,倾听,积极思考,积极参与,不卑不亢,以理服人。  

”);  

这些东东俺也不哆嗦了,就都列出来算了。  

 

就写这么多,说多了没意思,待会P俺的人更多  

参考书目:<<结对编程技术>>(大部分都是抄的,不信你可去翻原书。)   

看完了支持的话就回答俺:你到底结不结对?

评论
praguesky 2007-07-08
谢谢`~
shaucle 2007-01-02
俺以前是理想主义者,(现在可能也是)

(以下摘自 读书小感,小议XP )
其实XP中有很多东东也不总是好用,如:
集体所有权:可能导致平庸的改动,而且责任不明显。
教练:有几个这样勤奋和优秀的教练呢?
客户:不仅很累,做的都是程序员不愿做的事,而且很大程度就是项目失败的替罪羊。
结对编程:有时安静还是比较好一点,而且有些人不喜欢。
等等。


个人认为XP应该重构的几个方面:
1 做计划时按项目复杂性作一定量的设计(分成子项目),最好不要一开始就编码。
2 迭代周期不一定要每次都短,解决问题才是最重要的。
3 当你持续重构时,应该怀疑一下你的设计了。
4 避免过早的将项目推入维护模式,起码要等项目基本成型,这可能是XP一大软肋。
5 不要强求结对编程和大家同处一室。
6 教练、客户不是一定需要的,要的话,责任也不一定要分得太明确。
7 集体所有权也不是一定的,可以通过团队的设计、评论来补充。
8 程序员有各自的测试是好事,但当项目较大时,仍然应有独立的QA团队。
9 TDD和预先设计是相互补充的。(再强调一次)
lautsie 2006-12-31
写得很不错啊,呵呵

不过事实上结对的还是很少的
发表评论

您还没有登录,请登录后发表评论

shaucle
搜索本博客
博客分类
最近加入圈子
最新评论
评论排行榜