Pair Programming & Simple Design

阅读更多
摘自:http://www.blogjava.net/raimundox/archive/2007/03/27/106669.html
pair programing是所有XP实践中争议最大的一个,但窃以为确实XP实施的关键关键实践之一,甚至于,我认为很多XP实施的失败都是由于没有采用pair programming而造成的。
要了解pair为什么重要,就要了解pair的目的在何。当然了,大多数人都知道pair的重点在于知识传递,知识共享,持续走查,降低代码缺陷等等等等。这些都是pair的优点,不过最重要的一点却常常被忽略——pair programing的最直接而又最根本的目的之一在于simple design。

上图是著名的Ron Jefferies Model,可以看到XP最佳实践被划分成了一个一个的圆圈,而pair, TDD, refactor和simple design位于中心。这并不是说这四个实践就是xp的核心。jefferies model每一圈代表了xp实践过程中的不同关注点,最中心的是dev视角,其次是team视角,最外层是交付/管理视角。每圈上的最佳时间多少都有些紧耦合,放开其他的不讲,我们专门说说dev圈,pair programing, tdd, refactor和simple design。

这四个实践里只有simple design最虚也最重要。有一个问题已经被问过无数次了,“到底多simple的design才叫simple”。我对此也有一个近乎刻板的回答:team里所有人员都能够理解的design就是simple的。一旦立了标准,这四个实践的主从关系就一下子清晰起来——simple design是这四个实践的核心,其他三个实践都是它服务的。

首先做出一个设计,最简单的判断标准就是是否可测,一个不可测的设计基本上可以认为无法实现,于是TDD即是simple design的质量保证又是simple design的直觉验证。

refactor是为了得到好的代码,那么什么是好的代码?simple design!!!这里有人不同意了,有人说只是要易于修改和扩展,可是扩展和修改也要别人看得懂才行啊...simple design是起码的要求嘛。实际上,XP中的refactor就是朝着simple design的方向重构过去的,也就是朝着所有人都能理解的代码refactor过去的。插一句题外话,为啥说好的架构的不是设计出来的呢?因为好的架构至少应该是simple design的,而simple的概念有和人员相关...所以当你极尽能事show off你的pattern知识之后,得到复杂设计根本就不可能是好的架构。时刻紧记,架构是妥协啊...

最后,pair programming是simple design的实际检验!!!因为即便是最复杂的设计,只要是你自己想出来的,你都觉得它简单无比,里面充满了直白且显而易见的理由。可惜不幸的是,我们要的简单,是对team里所有人的简单。如果你的pair不能理解你的设计,那么说明你的设计复杂了;如果你们两个人懂,但是swith pair的时候,换过来的人不懂,说明你的设计复杂了。pair programming(以及他那容易让人忽略的子实践switching pair)就是检验simple design的过程。pair programing + refactor就是时刻保证simple design防止过渡设计反攻倒算的过程。pair programming + refactor + tdd就是团结在以Deming同学built quality in的质量大旗下,坚定地与过渡设计做斗争的过程。据我观察,至没有使用pair programming的团队中,少一半simple design成了口号,而这一半中,至少又有一半最终放弃了xp放弃了敏捷(俺以前带过的团队就有这样的...默哀一下)。深刻的教训啊,我们来高呼一下:"pair programming是检验simple design的唯一标准!"。

最后说一下pair programming经济学,过多的假设我就不讲了。单说一点,有哪一位上班的8小时从来不上msn/yahoo/qq等im?有哪一位上班从来不上论坛/不回贴/不发邮件?以我pair的经验来看,pair programming的过程中,两个人几乎不会用im,几乎不会逛论坛。你不好意思呀,毕竟不是你一个人的机器,毕竟是两个人的时间,毕竟你也不愿意给同事一种懒散的印象吧?收回的这么浪费的时间,至少顶得过另外一个人的工作时间了吧?

你可能感兴趣的:(pairprogramming,xp,simple,design)