我看“结对编程”

在公司的一个项目的第二次迭带中,团队决定尝试使用结对编程的方式。我从未尝试过这种编程方式,但仅从想像中去衡量,其实我并不喜欢这种方式,也不认为这种方式会提高我个人的工作效率,又或者对我个人成长真的有那么大的利好,以至于我们要迫不及待的去进行。但团队中几乎全部同事同时认为这是一件大好事,因此我决定还是用一天的时间去试试,去体验一把,再做定论。

当我结束一天的结对编程后,回到家里小总结了一下,虽然跟上面提到的想像中的场景不太一样,但结论仍然是:我个人对这事不太感冒。但出于这样的考虑,可能是由于初试这种工作方式,不得要领,又是戴着些许情绪的,所以结果会比较负面,我决定再去尝试一天,而且努力去适应它,但如果一天工作结束后,结果仍然很不乐观,那么我认为这是一中不好的工作方式,至少对我来说是不好的。

------------以上是周一晚上记录在google docs上的------------

今天白天我再次让自己尝试结对,一个上午的时间...我下午决定放弃结对,中午跟Team吃饭的时候,讨论到这个话题,谈到了“因人而异”,确实这个工作法真的是因人而异。

------------以上是周二晚上的记录------------

题记:今天周五,team周会,我们谈到了“结对编程”的问题,还有之前我查了一些关于“结对编程”的资料,这里我就说说我对“结对编程”这种工作方式的看法。

首先,我们要明确,“结对编程”这仍然是一个处在试验阶段的工作方法,我去查了一些学术资料,无一例外,所有的文章对“结对编程”的介绍都是持试验态度,分别介绍其优劣。另外一些文章中,虽有对“结对编程”大肆追捧的,却也在一部分,没有一边倒的迹象。但在国内的一些文章中,这个比例的确较高。

本文,我也不讲“结对编程”的优劣势,网上到处都有,稍后文章后面附上一些资料,只聊聊这一周我的感受。

在我看来,“结对编程”作为一种工作方式的诞生,是对“编程”这个工作本质的一种转移。或者说在某些变成活动中“结对”并不合适,而在另外一些则可以。“结对编程”的优势无非在于:提高代码可读性,减少项目个人依赖,降低错误率,促进个人成长。但我们看这些特性,事实上并不属于一个绝对意义,或者说纯粹意义上的编程(hack理念的编程),而是一种代码工业化的最需要具有的性质。

但这种工业化需要的性质,通过“结对”方式也不能保证达到,因为不同的程序员有着不同的工作习惯,有些人就是喜欢单独工作,不希望别人的干扰,当“结对”时,会大大降低他的工作效率和工作质量,这就适得其反了。

说道具体的工作中,往往我们容易使用一些极端做法去做事,这明显是存在问题的。例如在项目中大规模使用“结对编程”的工作方式,而没有考虑到这种仍然处在试验中的工作方式到底是否适合我们这个团队,到底是否适合团队中的每个人。

在工作方法的选择上需要因事而异,更需要因人而异,谨慎选择。

下边附上我认为比较不错的一些资料:

维基百科对 pair-programming的解释(http://en.wikipedia.org/wiki/Pair_programming)

Benefits

Design quality: Shorter programs, better designs, fewer bugs. Program code must be readable to both partners, not just the driver, in order to be checked in. Pairs typically consider more design alternatives than programmers working solo, and arrive at simpler, more-maintainable designs, as well as catch design defects very early.

Reduced cost of development: With bugs being a particularly expensive part of software development, especially if they're caught late in the development process, the large reduction in defect rate due to pair programming can significantly reduce software development costs.

Learning and training: Knowledge passes easily between pair programmers: they share knowledge of the specifics of the system, and they pick up programming techniques from each other as they work. New hires quickly pick up the practices of the team through pairing.

Overcoming difficult problems: Pairs often find that seemingly "impossible" problems become easy or even quick, or at least possible, to solve when they work together.Improved morale: Programmers report greater joy in their work and greater confidence that their work is correct.

Decreased management risk: Since knowledge of the system is shared among programmers, there is less risk to management if one programmer leaves the team.Increased discipline and better time management: Programmers are less likely to skip writing unit tests, spend time web-surfing or on personal email, or other violations of discipline, when they are working with a pair partner. The pair partner "keeps them honest".

Resilient flow. Pairing leads to a different kind of flow than programming alone, but it does lead to flow. Pairing flow happens more quickly: one programmer asks the other, "What were we working on?" Pairing flow is also more resilient to interruptions: one programmer deals with the interruption while the other keeps working.

Fewer interruptions: People are more reluctant to interrupt a pair than they are to interrupt someone working alone.

Decreased risk of RSI: The risk of repetitive stress injury is significantly reduced, since each programmer is using a keyboard and mouse approximately half the time they were before.

Drawbacks

Work preference: Some developers prefer to work alone.

Intimidation: A less experienced or less confident developer may feel intimidated when pairing with a more experienced developer and participate less as a result.

Tutoring cost: Experienced developers may find it tedious to tutor a less experienced developer. Experienced developers working alone may be capable of producing code that is clean and accurate at the outset, and the benefits of pairing might not be worth the cost of an additional developer in some situations. This may apply more especially when producing more trivial parts of the system.

Egos and potential conflict: Personality conflicts can result in one or both developers feeling awkward or uncomfortable. Differences in coding style may result in conflict.

Cost: There are varying opinions as to whether two developers can be as productive when working together as when working separately.

 

以及一篇Dell集团某人和犹他大学某人合著的论文:The Costs and Benefits of Pair Programming

 

标签:结对编程 pair programming 工作方法

添加新评论