2010-03-16 晴

今天大家的工作非常紧张，都进入了冲刺阶段。

今天的感悟非常多。

程序开发，吃透需求非常重要

前天晚上，我在写基础代码的时候，有一个相关的兄弟一直围观。我边写边讲，说根据需求为什么要有这个方法，为什么要这样使用。他一边听一边跟我熬夜，很是辛苦。而且，在昨天拆分需求的时候，他的问题是最多，稍有不明白的就马上询问，对需求的理解也是最清晰的。

结果今天的进度，他是最快的，而且很多看起来可能比较绕的流程也顺利听过。加之TestCase辅助，晚上就已经写得七七八八了。赞一个。

反观另外两个童鞋，这里不得不批评一下。他们的进度主要被耽误在对场景的不理解，不能整体理解需求、把握场景，导致途中频频趟雷。速度起不来，情绪也起不来。

程序开发，从更高的层次思考很重要

我们为了需求，写了一个很小的算是框架的东西，其实就是一个分发器。分发器接收请求，然后轮询问注册进来的指令类是否需要处理，如果需要则分发下去，否则询问下一个。这是一个非常简单和标准的做法，但是我发现很多工程师并不能理解这个模式。甚至到现在，已经基于这个结构作了一些东西之后还是不能完全理解。所以导致很多东西写起来很慢。

程序员要提高自己，其中很重要的一点就是越发的从高一层的角度来看待自己的工作。如果能够高屋建瓴，那么再脚踏实地会事半功倍，而且出错少很多。哪怕我们不能站上去，我们也要吃透自己涉及的相关的代码。

团队遇到的问题是隐藏在平稳下的

最大的感受，其实还是在团队。分配了任务之后，每个人都按照认领的任务开始了工作，一切平静。但是往往是危机四伏，如果此时跟进不及时，往往会出问题。因为我们总是有一些问题是无法预计的，碰到了是想凭自己死磕过去的，或者是根本没意识到这时一个问题的。如果这时候作为一个协调者和后勤人员，及时的在每个人遇到困难时候就跟进，能够在过程中解决大量的问题，节省很多时间。

我觉得，管理对我的要求就是对每个人，每个环节的了解，预判哪里可能出现什么困难，然后第一时间赶过去把问题消灭，让团队顺利的前进。

我的职责是预判可能的问题，并主动的去想办法帮助解决（潜在的）问题，让团队更好的去继续进行任务。

2010-03-15 晴

其实现在都16号了，昨天忙忙碌碌一天，一直到现在还有空写下笔记。

昨天一直在忙准备上线的东西。不是我们封闭的这些人的上线，而是另外的一个大的系统要上线，需要我这里进行配合，而且集中在一个兄弟身上。一下午都是在考虑如何在人员、进度、任务当中纠结。

当任务一多，就发现想平衡多个项目，各自达到一个比较理想的结果，整体获得一个比较理想的结果是一个非常考验智力的事情。这也是管理的难度和挑战。

在拆分和调整的过程中，再一次发现团队合理性的重要。现在由于一些关键路径、关键节点上都卡在同一个人身上，导致很多的任务安排起来很纠结。团队的组建，不同的层次的人的成长是一个很挑战也很容易感到有成就感的事情。我觉得我开始入门了。

晚上重新拆分了一个重要的需求，把任务分了下去，还是让大家理解需求，理解用例，通过用例覆盖场景的顺序。我自己则亲自动手，为大家做一个基础的数据类。算是第一次在写PHP，被大家围观了，还好没丢脸。

开始冲刺了，最后一周，一定要从全局把握好，争取一个好结果。

2010-03-13 晴，转暖

今天的事情并不多，昨天两个哥们一直到今天早上7点才去睡觉，一直在重构和单元测试。厉害。不过还得说一句保重身体。

下午得到公司的消息，新的系统测试的非常牛掰，每秒可以推送10万消息，很是振奋。我们这边也是配合修改前端的调用方式。代码修改量并不大，但是我承认开始并没有对此有一个足够的估计，本以为修改量很大。
这也就给了我另一个提醒，如何平衡多个项目之间的进度关系，如何让某些任务提前某些滞后。从一个大的项目来看，这些任务是不分先后的，但是从一些需要配合的场景来看，则必须。这就是关键路径的问题。

今天晚上强制休息，没干活，还好，大家玩的挺痛快。虽然有人惦记着工作。

2010-03-12 晴，大风大风

今天是值得纪念的日子，我组里的小童鞋第一次把做的东西投入生产环境，加油加油！！

今天的上线又被延误了，原因是整个这片地区整个断网，从早上不到11点到下午4点多，最好的时间什么都干不了。也好，强制休息了，很多童鞋选择了睡觉，晚上大家精神明显好很多。

印象很深的一刻是网络连通的哪一个时刻，所有人几乎是同时的奔回自己的作为开始干活，而且楼上的童鞋也是收到消息第一时间就回来了，进入工作状态时间之短令人振奋。可见这是一个有战斗力的团队。

晚上吃饭的时候，盘算了一下进度，到现在大约延期了一天半。其中大约一天是环境的问题。今天是无法上网半天，上次是新开发的上线系统不熟悉，连带git-svn合并代码半天。这些都是最开始没有料到的，这是我的问题，以后要记下来。
这其实也是一个工欲善其事必先利其emacs的事情。我们总是在打造自己顺手的工具，提升每个人的生产效率。但是我们往往不是那么的关注团队的顺手的工具。余以为，这个工具是流程，是配合的环境，是统一的方法。

简言之是两个方面，流程工作方法是一个方面。我们发现很多的程序员都在抵制流程，但是在这几天没发现这里的人抵制单元测试，而且也看到大家从中获益良多。那么是不是以前我们的流程有问题呢？是定位的问题？还是推广的方式有问题？
我们不能为了流程而流程，如果一个流程是为了让领导看，让领导觉得我们没闲着，那么这就是扯淡的事情。

另一个方面是标准化，前几天我说过部署环境的标准化，现在看来在每个人的开发工具上提倡标准化也是有必要的，尤其是在梯队建设中的时候。很多时候我们要做CodeReview，还有结对编程，这时候如果大家的工作习惯不同，对效率的影响还是很大的。
现在的团队基本上在主推vim等开发工具，我这个emacs党只能不明真相的围观了。

2010-03-10 晴，升温

雪停了，终于也开始升温了，寒冷的冬天会过去了吧。

今天的一切都很平稳，除了网络。本来安排今天要上线一些东西的，一点一点的迭代的更新，但是都准备好了的时候，网络却罢工了，连到服务器打字都要等半天的。结果到现在都没有搞定。

下午和昨天那个哥们一起写了新的功能的测试用例。算是我盯着他手把手做的。发现了现在的很多的工程师对这个还是知其然不知其所以然。他写的代码都是测试功能性的，而不是测试场景的。这样的代码对于场景是没有意义的。手把手的和他一起写了几个用例，感觉他明白了一些。还需要加强。

今天大家休息了一下，但是还是有很多人痴迷工作。看来有必要继续强制休息了。这种癫狂的工作状态，是既想引入回公司，又感觉有点害怕的。

晚上review了一些新的代码部署的结构，准备采用rpm，并且架设自己的yum源。我们终于逐渐的走上标准化的路线了，这个值得欣慰。

2010-03-08 鹅毛中雪

今天早上中午还都是平平淡淡的过去的，没有波澜，只有不惊。唯一的不同时窗外白茫茫的世界。从夜里开始下雪，周围已经都白了，天气也冷了，这是什么天啊。2012？

下午吃饭前1小时的时候，我们决定提前进行CodeReview，按照某些人的说法就是“爽一下，然后去吃饭”。
今天上战场的小哥是一个测试开发人员，我已经单独的给他Review过至少三次代码，代码的质量已经好了很多了，让他上去游街我还是比较放心的。
不明真相的群众纷纷前来围观，我们又开始激烈的讨论，今天的讨论让人为之一振。

今天我们没有过多的纠缠在编码风格等地方，究其原因应该是：

1. 经过一周的训练，小哥的编码已经没有太大的问题了
2. 经过一周的围观，群众的见识已经大大的不一样了

取而代之的是，我们花了很大的篇幅来讨论 TestCase 应该怎么写；测试断言应该到什么粒度；测试时候是否相信（一个）函数的功能；重构时候函数抽取到底应该包含那些；等等，不一而足。讨论非常激烈，而且也第一次出现了双方的论述都有道理，都无法彻底的说服对方的情况。这是一个好的现象，说明我们已经上升到了一个思辨的层面，也说明我们已经开始有能力站在稍微高一点的层次来看待开发这点事儿了。
今天分歧最大的一点在于几个开发人员认为用例覆盖的太过于细致，被抽象出来的一个创建对象的方法里面进行了大量的检查，这是没必要的。而负责写用例的童鞋是测试人员，他认为是非常有必要的。从而展开了一场声势浩大的拉歌比赛。
我个人从如下三点来理解这个问题和分歧的：

1. 要考虑代码是经过多次重构长起来的
   今天大家看到的代码其实是重构了多次，一点点的生长起来的。在重构的过程中，一定会出现为了几个地方差不多，略有不同但是本质上可以放在一起的情况，这时候把他们重构到一个方法中不能说不合适。而这时候造成的结果可能就是这个方法只能上稍微有一些臃肿。这时候我们可以选择职能继续拆分，或者是忍。可是忍了，这些（逻辑上可能）多余的代码怎么办？
2. TestCase 中无副作用的多余的代码如何处理
   我个人写 TestCase 的习惯是这样的。写好的断言，如果不是非要删除不可，一般我都会留下。因为这不是功能性代码，这地方稍微罗嗦一点没关系，而且说不准哪天会用上。而最重要的理由则是，这些代码没有副作用。当然了，如果某些断言耗时很长，那就属于有副作用了，如果没用，坚决干掉。
3. 每个人的职责不同，看问题的角度不同
   还有一个问题就是大家看到的问题的角度是不同的，开发看的是用例应该体现设计思路、单一职能，要简洁。而测试人员看到的是我不相信一切，我要覆盖到一切可以覆盖的地方。而引申出来则是开发童鞋看到的用例应该测试单元，而测试童鞋的用例则是为了覆盖场景。
   这个思辨的过程是我第一次想到的，也是我觉得收获最大的一点。如果我们认为测试和开发是站两边，现在团队已经开始在朝着中间靠拢了。我记得我说过一句话，就是开发的单元测试用熟练以后是应该朝着覆盖场景前进的。这也算是我们为了以后更大规模的自动测试前进了一小步吧。
   随着测试驱动开发的锻炼，我相信开发人员都会有一颗测试的心。

还有，期间有童鞋说，写断言没错，但是如果是多个断言，可能会打断正常的思路。
这里面我给出的答案是“采用占位方法”。说起来很简单，就是在需要写大量代码的地方，给出一个占位的方法，这个方法的职责就是去完成那需要多行代码组合起来的功能。这时候就不怕思绪被打乱了，而且这个方法还没有，编译/运行肯定不过，也不怕回来忘了。

今日Milestone，测试人员已经开始测试了。给出了一个任务，要求测试的MM和功能开发的兄弟明天一起给出一个报告。这个报告是要对比使用 TestCase 前后的不同的。其中应该包括Bug的数量、回归的时间、问题的定位等。
完成了这一步，我们的测试驱动开发才能算是完成了一个完整的循环。