Behind the Code

2010-03-14 大雪

难道真的2012？现在还下雪，还是鹅毛大雪。娘列~~

今天重温了一下进度，感觉还是有点紧张的，实在不行就只能砍掉一些需求了。现在给兄弟们的压力太大了，工作很辛苦。不过按照我的说法第三周效率会有一定的提高，因为测试用例大家已经熟悉一些了。不过这个还有观后效。

中午围观了一下上线流程，真是帅呆，累呆。

上线应该是包含哪些呢？

1. 各小组把代码提交到自己的分支
2. 把不同分支的代码（不同小组的代码）合并到上线分支（有些是从分支上线，在此并不讨论，这两种方式没有好坏之分）
3. 把上线分支的代码同步到线上环境
4. 把上线分支的代码合并到其他的分支

这里面说起来挺简单的，而且第三步我们已经有了上线工具可以做到，按道理应该是不难的。但是我们却花了至少一个小时才完成。真是杯具啊。

说起来我们在哪里费时间了呢？

1. 各小组代码提交到自己分支，很快。
2. 把不同分支的代码合并到上线分支，这个费时间很长。
   原因是上次的第四步没做好。而且我们每次都做这两步都是基于文件的（而不是基于提交或者 ChangeSet），每次挑选到底哪个文件（甚至哪个部分）要上到上线代码是一项人类体力与智力的考验。如果没有拜过春哥或者你不是从娜美克星来的你可得小心。
3. 使用上线工具，很快。问题也是基于文件的，但是现在还没有遇到问题。
4. 貌似这次又忘了？

这里面最耽误时间的是第二步。今天的花销其中95%以上都是消耗在这里。
个人觉得这里面的问题并不容易解决。比如我们总有一些文件不得不提交，但是这些文件却不需要上线。 这里如何解决呢？
最简单的办法当然是一次性用新的代码合并上去最好，但是如何保证合并后的代码没有问题呢？尤其是一些比如负责分发判断等代码，贸然的合并一定出现问题。而其一些常量定义的文件在多团队开发下，也一定会出现冲突的情况。

根本上我觉得现在上线和多团队开发还不是那么的爽，还需要大量的人力参与，可能还是开发模式的一些有待提高的地方。试想，如果linux也有我们这样的问题，那就真的没法混了。
这个我会好好的考虑一下如何推进。既要让效率提升，又要每次改动都让现行的开发人员平滑的升级，这并不简单。

程序开发是一个团队作战，我们需要明星战士，但是我们更需要一个能捏合整体的有效的方法。而且还要考虑到产品和运营的需求，在市场、产品、研发、积累等等方面做到平衡。管理，则应该是这个粘合剂，我也应该是这个粘合剂。

2010-03-13 晴，转暖

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

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

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

2010-03-12 晴，大风大风

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

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

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

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

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

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

2010-03-11 晴，开始暖和

今天大家已经开始进入到一种稍微憋闷的状态了。有些兄弟开始出现了身体不适的反应，我很担忧。早上没有叫大家，让大家自然地醒来。工作中也第一次允许开放音乐了，必须开始调整气氛了，已经近乎癫狂了。
某个哥们也开始说像他这样不爱说话的人也开始有想见人就拉住聊天的冲动了。
现在我已经开始轰人回去睡觉了。

状态的调整是一个很重要的事情，如何让团队保证一个持续的战斗力是一个很高深的话题。
今天也第一次透彻的感觉到团队的力量。以往看到很多的人说，在一切的资源中，团队是最重要的，但是从来没有过这么直接和透彻的感受。 一个合理的团队搭配是保证高质量战斗力的前提条件。这个团队必须有教练的角色，也必须有核心队员和明星队员。但是最重要的则是梯队的合理。试想，当年风头最劲的黄色潜水艇就是因为其他球员太弱，就算里克尔梅赔上老命也无法杀入欧冠决赛。
现在我的团队就是梯队有些不合理，导致几个兄弟十分疲劳但是任务其他人也无法分担，看得我心焦又心疼。
兄弟们，快快成长起来吧。

晚上和组里的一个童鞋一起看他的测试用例和代码，写的还算不错。和他一起又探讨了一些关于TDD、重构的思维方式以及最佳实践。一次可能灌得有点多了，慢慢来，成长也是一个过程的。
我准备在这几天单独给他开小灶了，必须拔苗助长了，会很辛苦，但是也会很有收获。

有这样的一个机会，我能够近距离的，透彻的观察我的团队，思考团队应该如何进行人员配比、如何建设、团队的弱点、团队的潜力等。这是一个最佳的实践机会，也让我自身提高去更好地履行教练的职责。

知难行易，任重道远。加油。

2010-03-10 晴，升温

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

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

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

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

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

2010-03-09  昨天雪，今天冷

昨天已经有童鞋提测了，今天测试MM开始了基于单元测试的测试流程，明天我们就可以拿到一个对比的报告了，很期待。第一个完整流程指日可待。

今天遇到的一个情况是测试驱动开发的反复。

• 有童鞋对测试用例有了一些疑问
• 有童鞋恢复到了以前的模式，先写功能性代码，然后用用例才测试

疑问是这样的，他在开发中，遇到了大量的遗留代码的问题，这时候在对已有代码的信任度上已经产生了质疑，他总是觉得要覆盖更多的内容才放心，但是这样却觉得UnitTest写起来没完没了了。
我对这个的回答是从两个方面进行的

1. 因为这次是第一次采用UnitTest，所以一定会出现大量的以前藏着的雷被踩到。
2. 已有的代码，我们这次假定是信任的，如果真的有问题，我们暂时绕过去，并告知测试和原有代码维护人员。因为如果不这样我们是无法定义用例覆盖的边界的。而遗留代码的问题，是应该相关的维护者补充对应的测试用例来覆盖的。

测试驱动开发是一个循环的事情，坚持住了，往前走就是良性循环，被遗漏的代码越来越少，雷区越来越少，代码质量提升。但是如果往后走，总觉得没时间写，总是有大量的不可覆盖不可测试的代码，每写一点就趟雷，会严重的打击士气，然后就不写了，然后就恶性循环了。

让我觉得非常受打击的一个事情是有些童鞋回到以往的开发模式了。先写功能代码，然后用用例开覆盖功能代码，起到测试的作用。
我记得我多次提过这样的危害，但是还有童鞋跑了回去，晚上只好那他开刀进行CodeReview。结果发现了一些设计和场景层面没有照顾到的地方。在此，我再说一次用 UnitTest 会带来的好处，当然这里只是说了一些对于开发者最明显的好处

• 用用例覆盖场景，因为我们考虑的是场景并且有测试人员配合，所以我们不容易遗漏场景
• 写TestCase是在进行设计，从使用者的角度，从API设计者的角度去看代码，会让设计更加自然
• 用功能性代码覆盖用例，功能性代码有保障
• 测试时期发生Bug容易定位
• 为测试节省时间，比如边界测试等都可以通过TestCase来进行，而无需每次都人肉
• 等

我决定他下一个任务我和他结对编程。

行百里者半九十，古人诚不欺我。

一直以来我都是用 yinwm.cn 这个域名，但是不知道为什么总是不能被google检索到。

今天趁着还有点时间，整个把blog都切换到 yinwm.com 这个域名，也算是逃离了老大哥的注视，希望谷哥哥能看上我。

另：feed 也重新烧录一下，大家不用更新，还能接着用

• http://feeds.feedburner.com/yinwm
• http://feed.feedsky.com/yinwm

2010-03-08 鹅毛中雪

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

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

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

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

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

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

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

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

2010-03-07 疑似小雪

今天总体上是比较顺畅的，早上大家强制休息，也睡了这一周以来的第一个懒觉。只不过还是有些人禁不住工作的诱惑一早就下来了。

今天下午整理了一下说客层面的 网元 信息，从整体结构上搞明白了各个系统之间的链接关系。随后的工作就是开始整理各个场景。
这个过程本身挺简单，过程中我也逐渐体会到作为一个管理者所应该具有的职责。我不应该抛下所有的事情冲到一线、钻到某个细节。如果总是赢得了战役输掉了战争，那就不是一个好的将军。

• 我得成为一个管家，四处出敲打追债。
• 我得成为一个教练，为我的团队制定更好的成长、战斗计划
• 我得成为一个指导，协助团队成员的进步。
• 我得成为一个千斤顶，为团队顶住压力。
• 最重要的，我要成为一个望远镜和放大镜，清楚团队要做什么不做什么，先做什么后做什么。
• 等等

看到自己的成长感到高兴，看到团队的成长感到欣慰。

晚上又进行了CodeReview，感觉有些不同。
整体上大家都期待着CodeReview，很多不明真相的群众主动围观。 大家愿意学习其他人的长处，愿意分享自己的经验。看到别人踩雷的时候，也会想想自己是不是也有类似的风险。CodeReview，是交流，是成长，更重要的是创造一种氛围。看来大家开始上瘾了。
说道CodeReview就不得不说我们的一个小童鞋，到现在经历了大约三、四次CodeReview，每次Review之后都基本上重写一次自己的代码，真是可怜。更可怜的是，几乎每次都似乎Review别人的代码，-_-!!

2010-03-06 晴 小风 貌似某些地方有雪

今天总体上就是某些人的幸福和郁闷。

早上领导来探班，带来了很多吃的喝的，鼓励一番大家后，考察了进度等情况，还算不错。中午一起去吃饭，可算换了一个饭店，这才好点。

下午大家就是休息，毕竟太累了。等晚上吃饭的时候，发现各个食堂都没地方了，只好回来CodeReview。这下某些人郁闷了。我们这群不明真相的群众不断的挑出了很多的问题，搞的当事人很是xxxx。
问题很多，等我稍后一起总结。

然后CodeReview被强行终止，因为太饿了，鉴于食堂还是没有地方，我们出去吃了一顿野食。比较丰盛。回来打了一下牌，强行要求所有人休息。

明天早上睡个懒觉，然后继续拼杀。