代码改变世界

团队学习日记(0)——用wiki来记录团队的学习日记

2010-10-26 22:42  菜阿彬  阅读(2212)  评论(10编辑  收藏  举报

  先说说我们团队的背景:6个程序员,除了少数(比如我)虚长几岁经验丰富点外,大部分都是年轻人,而我们开发的软件是个遗留系统,里面的代码是非常“过程式”的,而开发任务又一直比较紧,这些因素导致这些年轻人OO的经验相对薄弱。其它像设计能力、写clean code、重构、TDD等等,也是我们团队非常感兴趣要去提高的地方。

  公司虽然开发任务紧,但还是经常有团队学习的时间,比如release一个版本的时候,会有1个月的时间code freeze,QA进行系统测试,这段时间我们dev就比较闲了,可以研究一些技术上的东西。(当然对于一个敏捷团队来说,一个月的code freeze,本身是个issue,但这不是本文重点。)

 

  这个月就是这样,我们dev闲下来了,就对一个模块进行重构,一方面为下一阶段做的需求增强做准备,另一方面也是锻炼大家重构、设计、写干净代码的能力。

  这个模块的背景:代码大多散布在code-behind文件里,也就是aspx.cs文件,当然还包括一些domain object类;代码最大的特点是可读性非常差,函数长、圈复杂度高、命名不规范,总之不调试进去的话,很多代码都不知道是干嘛用的。我们作为有追求有活力的团队,当然是要改变这个现状。

 

  重构大致分了两个阶段,第一阶段用pair的方式,把原来比较混乱的代码清理了一遍,清理的动作包括:把长函数抽成小函数;规范化命名;移除不可及代码等等。第二阶段是从昨天开始的,目标是把aspx.cs里属于domain logic的代码,移到domain model类里,让domain model类“充血”,重要的是,这样就可以对这些代码进行unit test了。一个没有unit test的世界是黑暗的,而我们看到了一丝曙光。

  这第二阶段没有用pair了,而是采取的是所有人坐在一起写代码的方式。这是考虑到大家处在学习的过程中,对“好的设计”的理解还不是很一致,如果pair的话,分为3组,这3组仍旧可能写出很不一致的代码出来,于是干脆大家坐在一起写,有那么点coding dojo的意思。

 

  话说今天,大家又坐在一起写了一天的代码,而每次在这个过程中,我作为设计、重构和TDD经验相对比较丰富的一个人,都感觉还是有很多东西可以分享给团队的,此其一;其二,他们对代码的思考和疑问,反过来也会促进我的思考。我相信他们也是有和我一样的感觉,那么,这些思想碰撞的过程,对整个团队能力的提升是非常有利的。

  可是晚上回来,我还是有点困惑:有些东西,团队学习的很快,但有些东西,也许是经验未到一定的程度的关系,团队比较难记住,需要多次的提醒。

  洗澡的时候我就想:如果我是他们中的一个年轻人,我会怎么办?自然而然就想起若干年前,我还年轻的时候(俺也年轻过啊!),我是会写“工作日记”的,把学到的知识点,简单记下来(不一定每天,但有了就记),当时看好像没什么,但日积月累,一段时间后,把那个日记本重新翻一下,收获是很多的,可以温故知新,又可以提高自信(过去一个月居然学到那么多东西,我真是小强)。想到这里,决定,明天上班向他们推荐这个做法。

  这时准备收工,可是灵光一闪,又想:为什么不让团队作为一个整体,来写这个“工作日记”呢?团队刚好建立了wiki,是写这个日记的绝佳地方。随着这些日记的增多,对团队知识的巩固应该是个帮助,而且还可以分享给公司的其他团队,以及以后新来的员工,甚至我可以把有价值的部分,放到我的blog上来。我觉得是个不错的主意,于是心满意足地收工了。

  为啥我的灵感,大多都是在洗澡或睡觉的时候得到呢?白天为公司工作,晚上回家还继续为公司爆发人品值,我的公司真是赚大了。(boss看这句就行了,haha)

 

  洗完澡整理了下思路,我们的“团队学习日记”应该会记录一切跟工作相关的、让我们团队成长的知识点,包括写代码、做事的方式方法、敏捷实践、团队建设、团队学习……嗯,我们是敏捷团队,团队作为一个整体来做事、来交付软件、来做决定……也应该作为一个整体来学习。

  而这篇文章——“用wiki来记录团队学习日记”,就当做我们团队的第一篇“团队学习日记”吧(传说中的递归?!)。