• 2008-03-28

    半路出家

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/17787897.html

    不知道算是幸运,还是不幸,我参与的多数项目,如果不是从头开始,我也是最开始加入的几个人之一,所以,我通常对项目的来龙去脉都比较清楚。这次,我有机会尝试一下在一头雾水的情况下开始一个项目。

    这个项目已经进行了超过一个月,因为客户需要在赶在最近的一次发布之前,增加一些功能。老板按照目前的进度估算了一下,如果不加人,这个任务很难完成,于是客户很合作的同意增加两个人。就这样,我成了临时工。事实上,在这个阶段进入,项目早就过了最初的阶段,远远望去,没有几百也有几十的程序文件屹立在那里。虽然有最熟悉项目的人为我们介绍了项目的背景和架构,但这些宏观层面上的东西,对于编写代码这样“微观”的操作而言,几乎是没有任何直接的帮助。作为一个新人加入到项目,除了发呆,我还能做什么呢?

    回想在以前公司的情形,大多数新进项目的人多半是得到一大堆文档,然后,有人语重心长的说,先把文档看了吧!且不说这些文档这种东西几乎写出来就过时,单单读完这些文档就需要花费很多时间。运气好的话,还有代码可以对应,但千万不要指望你能够一下子读懂这些代码。也许,你会想找别人来问,如果不出意外,大多数人都会不明就里的非常忙,忙到有时间上网聊天却没有时间给你讲这些东西。事实上,很多人即便自己做了很多东西,也不一定能够清晰的描述出来,所以,即便找到一个“闲”人,成功从他那弄明白这些东西的概率也很低。其结果是,我们经常会看到一些人在那对着电脑上的文档发呆。

    在ThoughtWorks,我也恨不得找到一堆这样的无聊文档来打发时间,以此来享受偷懒的时光。遗憾的是,完全没有这种机会。因为那些“文档”会被视为浪费,这在以消除浪费为己任的敏捷来看,是无论如何不能接受的。于是,我在找不到任何借口的情况下,进入项目的第一天,就开始写程序了。不了解项目,怎么写程序?这是个问题。

    敏捷实践中,有一个叫做Pair Programming的,从字面上来看,就是两个人一起开发。对于ThoughtWorker们来说,Pair是一种常态。所以,我在开发时也会有一个Pair,虽然我对项目一头雾水,但我的Pair已经在这个项目上工作了很长一段时间,所以,他很清楚这个项目的一切,差不多一切,因为代码是集体所有,所以,他在开发过程中会接触到各个部分。

    拿到我们要做的Story,我的Pair会结合这个Story给我介绍上下文,并结合代码大致描述一下我们要做的事情。虽然在这个项目上我是新手,但我并不是对编程一无所知。有了这些基本的信息,我至少对我们要做什么,以及如何来做,在心里已经形成了一个大致的印象。刚开始时,基本上是我的Pair在主导开发,一边做一边告诉我,我们已经走到了哪里。渐渐的,我已经对我们在做的代码有了一些认识,开发也开始由一个人主导转向两个人讨论。随着开发的深入,我也发现了现有做法的一些不足,于是,我提出对代码进行重构,并给出了自己的分析和建议。我的Pair在听了之后,认为这是一个可行的建议,于是,我们毫不留情的将那段大家看着不舒服的代码改掉,这段代码从此清净了。

    这就是在加入项目前几天所做的事情,虽然我目前还不能对整个项目有个很好的把握,但是,我相信,我已经开始在这个项目中起作用了。我想,Pair Programming是主要原因。正如前面所说,虽然我对项目很无知,但我的Pair很好的弥补了我的不足。正是两个人的协调工作,让我可以在对项目没有完整认识的情况下,可以很快入门,以最快的速度融入到开发之中。

    曾几何时,我对Pair Programming的认识还停留在大家一起写程序和知识分享上,原来它对半路出家的人帮助也很大。虽然《人月神话》教导我们说,加人起不了很大的作用,但Pair的方式至少可以在相当大的程度上发挥新人的价值,削弱加人带来的负面影响。

    分享到:
    引用地址:

    评论

  • 哈哈, 梦想的文章好象风趣了不少. 听你这么说PAIR, 不禁想到了一个比喻. 这好象就是细胞分裂嘛, 老细胞把他对项目的了解(DNA)快速地教给新细胞, 过一段时间, 这两个细胞又可以分裂了. 当然不分裂是最稳定的.
  • 其实,xp对于程序员的要求是更高了,而不是相反,想象一下两位初级程序员,即使pair,也不会出什么成绩,但这种初级程序员,在waterfall的形式下,也是需要的
  • 我也很喜欢代码重构,看到不清晰的代码,或者过时的注释,真的很不舒服。有机会多交流。。:)
  • 我有几个关于pair的问题请教:
    两个水平相当的人(包括技术和项目经验)在一起做pair,会带来什么样的好处?是不是有点浪费资源?是不是所有的事情都需要pair?
    :-) Thanks.
    回复zuma说:
    从你的问题来看,你需要的是一些相关的书,来比较完整的了解一下Pair Programming。

    简单来说,Pair不是提高开发速度,而是提高开发质量,因为一个人做事,总会有一些盲点,由此看来,大多数事情是可以Pair来做的。
    2008-03-28 19:10:38
  • 考虑一下传统软件开发方式针对这种情况的处理,
    实际上还是对人有要求的,对于Programmer,除了
    编程技能之外,还有一项很重要的就是沟通能力,
    就是三言两语能把别人很繁复的事情讲清楚,但是
    这个又回到了对人要求比较高的老路上,(就像以前
    别人批评敏捷xp对人要求比较高一样).
    但是,敏捷也不是对于所有情况的项目就一帆风顺,
    比如团队是分布式,那么你们这种情况下,即使想用
    pair,也用不了,那么这种情况下,你们是怎么做的呢?
    回复femto说:
    在Pair过程中的沟通,所需要表达的内容远远少于一个讲解所需要表达的内容,所以,更容易把问题讲清楚。

    团队是分布式的,这会造成很多的问题,只能不断的加强沟通,比如电话或IM等等方式。个人来说,我不喜欢分布式开发。

    我不知道,你为什么这么喜欢强调人的素质,至少每个人都是希望自己进步的。如果在工作中,水平不能得到提高,那工作还有什么乐趣?
    2008-03-28 19:06:16