先说说我们团队的背景：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来记录团队学习日记”，就当做我们团队的第一篇“团队学习日记”吧（传说中的递归？！）。