Behind the Code

今天很肆意的睡了下去，因为我已经正式的成为失业下岗大军的一员。

昨天办理了全部的手续，轻轻的离开了139。心里的确是很不好受。

新的旅程开始了，我也该开始总结我在139近两年的点滴了。

给点力吧老湿，都加了个油~~

今天很偶然的发现有域名要过期了，才发现丢了很多域名。

看来我的智商不足以支撑瞎搞，还是老老实实的吧。

今天整个移动集团要推动 http://10086.cn 的改造，http://139.com 正式尘封，改为 http://shequ.10086.cn 和 http://t.10086.cn 。

在139刚刚成立的时候我加入了进来，已经快两年了，在这有很多的美好的回忆，我看着139一路的成长，经历各种成功和失败。我也一路从一个死Coder成长到现在的技术和项目经理。真是怀念啊。

现在我很可能离开139，去寻找我自己的一片天空。现在，晚上1:20分，大家还在为了上线而奋战。随着我们上线流程和系统的逐步完善，我们产品形态的逐步确定，通宵上线貌似已经是很久远的事情了。所以，这个时刻，也许还真是我的幸运啊。

一小时之后，荷兰就要和乌拉圭进行第一场半决赛了。比赛在继续，我的工作和生活也要继续，是时候开始我自己的冒险了。这一年半多的时间，我很开心，我很怀念。等我正式离开的时候，我会把这快两年的点滴回忆写下来作为纪念，以及思考。

PS：10086.cn 这个域名真山寨，本着我朝山寨既创新的风骚，让我们山寨到底。

Update：2010/07/07 附上通宵上线的人们

我让朋友从米国带来的iPad到了。准备按照计划开始移动开发之旅了。

感受先。

用过一段时间的git，感觉非常之爽歪歪，但是也发现了一些问题，比如团队的成员并不是很容易的接受git，觉得麻烦。而且对于在含有*nix和windows上面同时开发的团队，经常要在不同的环境中处理回车换行的问题。这时候git不是不能解决，而是一遍一遍的给团队的成员灌输这些东西，成本是非常高的。

这两天抽空研究了一下Hg，发现国内外的“实用主义者”更倾向于使用这个。她和svn的一些使用习惯差不多，比如diff时候的版本号都是使用冒号(:)分割等等。这些小细节往往则是团队开发中选择一个工具的比较重要的因素。

我决定继续研究一段hg，然后考虑一下是否更加合适在团队中使用。

春节快乐～～

2010-03-18 晴

今天应该是封闭的最后一天，我们要在最后一天把这次封闭的成果上线展示出来。这次封闭其实更多的是一个练兵，是让兄弟姐妹们能够学习和提高。

今天是我们的收官之战，同志们还在前沿阵地奋战。一拨人公司配合上线的，另外一拨人测试这次开发的功能，还有继续改代码的，还有我这样记录的。

今天大家都很辛苦，几拨人都是到了中午下午才把代码全部搞定提测。需要上线的有两部分，一部分人是这次封闭做的新的小的任务，我们姑且叫做团队A。一部分是和公司一起搞的一个大版本升级，我们不妨叫做团队B。两个任务同时上线，刚刚好可以做一个不是那么精准的比较。

1. 人员组成
   • A组是一个中级程序员和三个初级程序员组成的团队，每人认领几个指令任务进行开发。
   • B组是一个半高级程序员，而那一个全人的水平是很不错的。
2. 任务类型
   • A组是一个组合指令的任务，可以明确的拆分任务，而且B组的负责人前期已经制作好了一个框架。
   • B组是一个现有系统的升级，牵扯到新老平台的切换，而且要修改的代码很难界定范围。
3. 开发模式
   • A组采用的是这次封闭尝到的单元测试先行的开发模式。
   • B组由于是修改现有系统，而且以前没有任何的测试类代码，所以还是传统的开发模式。
4. 任务难度
   • A组的每一个细分的任务都不是很难，但是比较庞杂，想要做好了必须完全吃透需求和无数的场景。
   • B组的难度比较大，是公司的一个重点项目，牵扯的系统都很多。
5. 任务强度
   • A组是这次封闭的主要项目。
   • B组时间非常紧张，本周才开始。
6. 测试人员数量
   • A组一个半人，最后这半个测试人员也并入到B组的测试中。
   • B组的专职测试人员4+人，还有很多不明真相的志愿者。
7. 测试时间
   • A组采用单元测试，从第一天可以说就在测试，从全部提测到测试结束大约3天。
   • B组由于任务重，所以测试时间并不多，但是从开发开始没多长时间就开始测试了。
8. Bug
   • A组的Bug不能算少，但是严重的bug并不多，只是几个。大多数的bug集中在类似文案调整的类型。
   • B组的Bug并不是很多，但是每一个bug都很纠结。
9. Bug的修复
   • A组的Bug由于存在测试用例，所以很容易定位，基本上每一个Bug修复的时间都不长。
   • B组由于没有测试用例，加之系统复杂，所以每一个bug都无法快速定位，必须依靠经验和对代码的熟悉程度。而且中间还出现了相关人员集中在白板前思索可能的坑在哪的问题。

上面是一个比较不靠谱的比较，也许并不公平。但是我们从中还是能看到一些问题的。比如有了测试用例可以快速的定位bug，比如如果没有我们会很纠结。比如我们每次修改的系统如果牵扯的非常多我们就很抓狂（应该把系统隔离的更好）。

现在已经早上6点了，我们还在准备上线。两个组都还纠结，但是看到曙光了。凡是我们用例定义的好的，测试覆盖的好的，很快就过了，否则都很缓慢。我们还有很长的路要走。

记得第一天我说，行百里者半九十，我们现在还远没有走到九十里。前面的路还很长。
前方的路不知是洒满阳光还是布满荆棘，我都会掸掸身上的土，继续走下去。

2010-03-17 晴

今天全天都处在疯狂的状态。几个小组齐头并进，我也亲自下水了。

还是发现兄弟们的基础还有待提高，而且往往是不对需求仔细了解就开始动手。这也是我发现的很多工程师的一个问题，就是总觉得动手早就是快。

工欲善其事，必先利其器。还是我昨天说的，必须吃透了需求，我们才能更好的进行下去。

这两天比较忙，昨天的东西现在才写，就到这吧。

2010-03-16 晴

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

今天的感悟非常多。

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

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

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

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

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

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

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

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

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

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

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

2010-03-15 晴

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

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

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

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

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

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