我是结合自身以及团队的因素来说明一下感想的,仅供参考。
当我们部门出现要组织大家结对编程的话题时,大家是非常反对的,问题就是担心效率下降了,学习成本增加了,没有自己的隐私了等等,在IT行业有很大一部分程序猿是不愿意改变的,不愿意学习新的知识和技能的,这样的人本来就应该淘汰或者转岗,要净化程序猿的技术氛围。最后我们经过数次的尝试也获得一些见解,如下:
我说下结对编程的好处是什么呢?
1、可以让新同事一进来就参与结对编程,有利于新同事快速的融入新集体,并且可以考察一个新同事的技术水平,也是一个间接的培训
2、 工位空间大的话,还可以减少工位开支
3、会减少bug的出现率,也较少后期的维护成本,主要编写者讲述思路,边上的人查漏补缺
4、能够对两个人或者多个人的技术水平的提高,有一定的沟通
5、每个人投入更集中了,更不会被其他人员打断了
6、代码设计的扩展性更强了
再说下结对编程有哪些弊端呢?
1、很容易暴露一些员工的真实水平,不利于某些人的发展
2、降低工作效率(只是在某些情况下才是这样的)
3、需要更大的工作空间,容得下两个人的位置
4、两人结对编程,不利于公司对员工的高认可度以及升职加薪
5、有的人员速度比较快,有的人思维反应慢,就会降低效率,也有人会说,和XX一起没有任何所得,破坏同事之间的信任
总结:
1、要正确的对待结对编程,要把这个过程,当做是自己技术水平提高的时机,而不是担心又暴露了自己的实力,这个正式你学习和进步的时间
2、结对编程要有足够的时间来沟通,以此才能达到更高的默契,效率以后才是真正的提高,要给一定的试验时间
3、当出台一些政策或者规定时,往往就是需要考虑大家的心里变化,需要提前把这些工作做到位,并且再出台政策之前做一些调查,让大家了解一下我 们将要普及的内容和概念是对我们多么的有意义
4、当然也有人会说我们出现bug之后,不是还有代码审查嘛,照样可以解决掉问题啊,可是那样会浪费很多时间,有的bug是一个月之前写的,等到集成测试的时候已经把逻辑忘得差不多了;或许在定位问题的时候还会发生推诿的事件,总是把责任归结于别的小组或人员
5、结对编程的人员最好实力相当,这样效率才是最快的
6、其实不管做与不做,总是有利弊的,就是看使用者如何看待,如何使用
7、最重要的就是为大家创造一个能够让开发人员安全的学习、大胆的犯错、快速的尝试、技能能够持续提升的环境。
a、我们要鼓励大家结果编程,并且把初期结对编程所犯的错误给予谅解,也可以请技能高的人员来做带头作用
b、同时组织大家尽快的尝试,最好能够更多的收取大家的匿名反馈,已获得大家的看法
c、给大家一定的创新空间,可以及时调整
以上也是对于大家领导力的一个培养。更重要的是看最终的结果,结果好才是对大家最有利的,即使当初有很多反对的声音!
写在后面:在接下来的日子里我也会和团队不断的使用结对编程来coding。
另外一篇我感觉比较好的文章:http://www.techug.com/post/10-ways-improve-your-pairing-experience.html