今天下午又有同事请水了，她要下项目了。其实这个礼拜会很热闹的，因为有两个孕妈妈同事都要下项目了。

我来到项目组九个月了，现在，竟也成了组里的老人儿了。组里的人，来来往往，上上下下。九个来月的功夫，便也轮了一遍了。经常也是刚跟一拨同事熟悉起来，适应了节奏，就要看着他们接受新鲜知识，迎接更新的挑战了。

不过在祝愿他们发展更好的同时，我还是会感伤的。毕竟，与每个人的相处，都是一段难得的缘分。

刚开始看到有人下项目的时候，就有人告诉我，Techops是个锻炼人的地方，人员的更迭是常事儿。如今，我是真的感受到了。

我们正在维护的code base，在code base里也算是有点点年岁的。我在里面，还看到了众多曾经贡献过的同事的名字。

其实，对于这些经常换人维护的项目，知识的传递还是蛮重要的。要不然，丢失的上下文太多，后面人再想着接手还是有些困难的。

敏捷里有关Code Review的实践，对于这种情况，我个人认为是蛮有用的。Code Review是啥，网上已经有太多的讲解了。只说说我们是怎么用的。

从我一开始实习的公司，到后来第一份工作的公司，code review的过程是不同的，我们的代码会提交pull request。其他同事看过了，可以直接在上面进行批注。待提出了修改或者通过意见，做过调整了，便会由TL合到master上。

现在在我们的项目组，是选定了每天下午的特定时间。每对pair讲自己做的卡，简述上下文，重点叙述解决方案及实现方式。若大家对上下文模糊，有疑问都会寻求解答，或者一起扒代码。若是遇到解决方案繁杂了，大家也会提出来。比如上周五我刚做的卡，用了一个非常繁杂的实现方式，可是在code review的时候，有熟悉另一种方案的人马上说出来，大大减少了我即将继续浪费的时间，还为我提供了新的解决思路。我下来自己一研究，时间能省出来一天啊。不过大家的重点从来都是代码本身，而不是写代码的人。

一个月前大家发现对业务也不熟悉，还集体分了任务，每个人去熟悉不同的业务知识，然后每天code review的时候腾出来半个小时做分享。大家现在遇到的不懂的业务上下文也少些了。

还有就是Pair(Extremely Code Review)。这也是我们组一直坚持的代码方式。今天还有同事跟我说羡慕我们组的敏捷实现（开心脸）。其实我个人并不是极力推崇一定要Pair的。但是我认为知识传递的时候，或者一段时间内代码质量下降的时候，Pair都是很好的方式。可是Pair的速率不一定等于1个人的2倍的，这是个客观存在的事实。像我们现在一直人来人往，会比较需要这样的方式，可若是一个组人人都是非常熟悉代码之人，再碰上工期紧张，也没必要一定执着于此。

今天思绪比较凌乱，没有条理地写了一篇。可能我是真的不舍得她们吧。

最后，还是希望两位孕妈顺利生下健康宝宝～还等着拿来办公室玩儿呢～