Behind the Code

2010-03-08 鹅毛中雪 今天早上中午还都是平平淡淡的过去的，没有波澜，只有不惊。唯一的不同时窗外白茫茫的世界。从夜里开始下雪，周围已经都白了，天气也冷了，这是什么天啊。2012？ 下午吃饭前1小时的时候，我们决定提前进行CodeReview，按照某些人的说法就是“爽一下，然后去吃饭”。 今天上战场的小哥是一个测试开发人员，我已经单独的给他Review过至少三次代码，代码的质量已经好了很多了，让他上去游街我还是比较放心的。 不明真相的群众纷纷前来围观，我们又开始激烈的讨论，今天的讨论让人为之一振。 今天我们没有过多的纠缠在编码风格等地方，究其原因应该是： 经过一周的训练，小哥的编码已经没有太大的问题了 经过一周的围观，群众的见识已经大大的不一样了 取而代之的是，我们花了很大的篇幅来讨论 TestCase 应该怎么写；测试断言应该到什么粒度；测试时候是否相信（一个）函数的功能；重构时候函数抽取到底应该包含那些；等等，不一而足。讨论非常激烈，而且也第一次出现了双方的论述都有道理，都无法彻底的说服对方的情况。这是一个好的现象，说明我们已经上升到了一个思辨的层面，也说明我们已经开始有能力站在稍微高一点的层次来看待开发这点事儿了。 今天分歧最大的一点在于几个开发人员认为用例覆盖的太过于细致，被抽象出来的一个创建对象的方法里面进行了大量的检查，这是没必要的。而负责写用例的童鞋是测试人员，他认为是非常有必要的。从而展开了一场声势浩大的拉歌比赛。 我个人从如下三点来理解这个问题和分歧的： 要考虑代码是经过多次重构长起来的 今天大家看到的代码其实是重构了多次，一点点的生长起来的。在重构的过程中，一定会出现为了几个地方差不多，略有不同但是本质上可以放在一起的情况，这时候把他们重构到一个方法中不能说不合适。而这时候造成的结果可能就是这个方法只能上稍微有一些臃肿。这时候我们可以选择职能继续拆分，或者是忍。可是忍了，这些（逻辑上可能）多余的代码怎么办？ TestCase 中无副作用的多余的代码如何处理 我个人写 TestCase 的习惯是这样的。写好的断言，如果不是非要删除不可，一般我都会留下。因为这不是功能性代码，这地方稍微罗嗦一点没关系，而且说不准哪天会用上。而最重要的理由则是，这些代码没有副作用。当然了，如果某些断言耗时很长，那就属于有副作用了，如果没用，坚决干掉。 每个人的职责不同，看问题的角度不同 还有一个问题就是大家看到的问题的角度是不同的，开发看的是用例应该体现设计思路、单一职能，要简洁。而测试人员看到的是我不相信一切，我要覆盖到一切可以覆盖的地方。而引申出来则是开发童鞋看到的用例应该测试单元，而测试童鞋的用例则是为了覆盖场景。 这个思辨的过程是我第一次想到的，也是我觉得收获最大的一点。如果我们认为测试和开发是站两边，现在团队已经开始在朝着中间靠拢了。我记得我说过一句话，就是开发的单元测试用熟练以后是应该朝着覆盖场景前进的。这也算是我们为了以后更大规模的自动测试前进了一小步吧。 随着测试驱动开发的锻炼，我相信开发人员都会有一颗测试的心。 还有，期间有童鞋说，写断言没错，但是如果是多个断言，可能会打断正常的思路。 这里面我给出的答案是“采用占位方法”。说起来很简单，就是在需要写大量代码的地方，给出一个占位的方法，这个方法的职责就是去完成那需要多行代码组合起来的功能。这时候就不怕思绪被打乱了，而且这个方法还没有，编译/运行肯定不过，也不怕回来忘了。 今日Milestone，测试人员已经开始测试了。给出了一个任务，要求测试的MM和功能开发的兄弟明天一起给出一个报告。这个报告是要对比使用 TestCase 前后的不同的。其中应该包括Bug的数量、回归的时间、问题的定位等。 完成了这一步，我们的测试驱动开发才能算是完成了一个完整的循环。

2010-03-07 疑似小雪 今天总体上是比较顺畅的，早上大家强制休息，也睡了这一周以来的第一个懒觉。只不过还是有些人禁不住工作的诱惑一早就下来了。 今天下午整理了一下说客层面的 网元 信息，从整体结构上搞明白了各个系统之间的链接关系。随后的工作就是开始整理各个场景。 这个过程本身挺简单，过程中我也逐渐体会到作为一个管理者所应该具有的职责。我不应该抛下所有的事情冲到一线、钻到某个细节。如果总是赢得了战役输掉了战争，那就不是一个好的将军。 我得成为一个管家，四处出敲打追债。 我得成为一个教练，为我的团队制定更好的成长、战斗计划 我得成为一个指导，协助团队成员的进步。 我得成为一个千斤顶，为团队顶住压力。 最重要的，我要成为一个望远镜和放大镜，清楚团队要做什么不做什么，先做什么后做什么。 等等 看到自己的成长感到高兴，看到团队的成长感到欣慰。 晚上又进行了CodeReview，感觉有些不同。 整体上大家都期待着CodeReview，很多不明真相的群众主动围观。 大家愿意学习其他人的长处，愿意分享自己的经验。看到别人踩雷的时候，也会想想自己是不是也有类似的风险。CodeReview，是交流，是成长，更重要的是创造一种氛围。看来大家开始上瘾了。 说道CodeReview就不得不说我们的一个小童鞋，到现在经历了大约三、四次CodeReview，每次Review之后都基本上重写一次自己的代码，真是可怜。更可怜的是，几乎每次都似乎Review别人的代码，-_-!!

2010-03-06 晴 小风 貌似某些地方有雪 今天总体上就是某些人的幸福和郁闷。 早上领导来探班，带来了很多吃的喝的，鼓励一番大家后，考察了进度等情况，还算不错。中午一起去吃饭，可算换了一个饭店，这才好点。 下午大家就是休息，毕竟太累了。等晚上吃饭的时候，发现各个食堂都没地方了，只好回来CodeReview。这下某些人郁闷了。我们这群不明真相的群众不断的挑出了很多的问题，搞的当事人很是xxxx。 问题很多，等我稍后一起总结。 然后CodeReview被强行终止，因为太饿了，鉴于食堂还是没有地方，我们出去吃了一顿野食。比较丰盛。回来打了一下牌，强行要求所有人休息。 明天早上睡个懒觉，然后继续拼杀。

2010-03-05 大风 今天感觉大家已经开始进入状态了，进入测试先行的状态了。 任务最艰巨的一个组已经画完了燃尽图，看上去排列的非常紧密。而且大家也都把 TestCase 相关的东西用起来了。 给几个童鞋 Review 了一下 TestCase，感觉到了成长和差距。很多童鞋总是太纠结于实现和细节，总是想这个东西是怎么做出来的，但是对他们应该怎么提供给别人使用和担负着什么职责明显关注不够。 如下的几个问题可能大家都会遇到： 能写程序但是不会写程序 写出来能运行的程序不难，但是写出来能正确运行并且优雅的程序很难。很多的程序从功能实现的角度没问题，但是从使用者的角度去看，就觉得用起来总有一些地方不爽和别扭。 解决的办法就是我说的用 TestCase 来规范你的编码设计，把 TestCase 当做你使用的场景。让每一个调用，每一个判断都自然而然的，思绪就好像小溪一样流到你的指尖，自然的形成一种被调用的代码。简简单单，自然而然。重剑无锋，大巧不工。 程序不够简洁、美观 很多人认为程序是完成功能的。但是我记得看过这样一句话，“程序首先是给人看的，然后才是给机器运行的”。我非常赞同这句话。现在的团队协作越发紧密，一个人是无力支撑一个系统的。这时候代码的沟通需要的是简单、清晰，目的是传达你的思想，而不是炫耀你的奇技淫巧。还是那句话，重剑无锋，大巧不工。 多几个空格，多几个空行，好一点的排版，这样同样的代码就清爽很多。我总说好的代码就好像身材曼妙的女人——凹凸有致。后退一大步，看看屏幕，如果一坨一坨的，你都看着恶心，那哥们，还是修饰一下吧。 代码的美，也在于留白。 对面向对象程序设计理解使用不当 什么是面向对象？为什么使用面向对象？应该怎么使用面向对象？ 这些问题很多人并不能回答，很多的对面向对象的使用，更多的就是把类当做一个方法的容器，所有的调用都是静态的方法，使用起来很丑陋。 今天给他们讲了一下对象的概念，看上去他们有了一些理解，也做出了一些看上去像点样子的代码了。还要持续观察。 但是让我最欣慰的是大家已经上道了。主动的让我去 Review 代码和 TestCase，让我帮忙一起分析用例和实现代码级别的 TestCase，愿意听我絮叨程序设计和开发中的一些经验，并且努力的尝试着去理解和实践。这些非常让我开心，我愿意这样做大家的召唤兽。 今天晚上没有计划没有安排什么工作。每天工作到凌晨零点，并且有些童鞋连续两天工作到凌晨一点，今天算是强制性的休息。但是晚上还是有些不自觉的人去写代码，我们都想把他按到床上绑起来睡觉。 程序员，请注意和照顾你自己的身体，这真的很重要。 另：今天晚上 QQ 同时在线突破 1亿 人，真NB。

2010-03-04 晴 又是微凉 今天的工作比较平淡，只是一切按部就班的前行。各个项目组也开始拆分场景和任务并且入Trac了。 这里面突然发现团队梯队建设的重要性。其实我一直自认为梯队做的还是不错的，高中低错落有致，但是在此次封闭中，还是发现了一些问题。 能够全面把控和影响队友的人还是少。如果说是因为我们第一次采用全新的开发方式导致了很多初级工程师不习惯，很纠结，那么我们在流程制度的推行上是否要更加的慎重和考虑更多的东西呢？ 这些恼人的问题值得总结和深思。 晚上还是照例的 Code Review，之后和几个同事针对 TestCase 进行了一些思辨。发现了几个问题，总结一下 从开发的角度，是从下往上看，还是从上往下看？ TestCase 是否真的节省时间？ 第一次用 TestCase 怎么估计开发时间？ 为什么功能性代码写起来很快，而 TestCase 耗时巨长？ 其实这些都是我们成长中必经的一些道路。我们每个人都无法停留在 舒适区，我们必然要痛苦和茫然的跨过恐慌区，走进学习区。逆水行舟不进则退，要相信，我们一直在成长、前行。

2010-03-03 晴 微凉 今天是忙碌和劳累的一天。搞的我现在才能写今天的封闭笔记。 今天的流水账有： 场景继续拆分 确认开发流程，如何和现有工具结合 Git使用 CodeReview 今天说话的成分非常的多。其中最关键的一点就是确认了开发的流程，和现有工具结合。 我一直是推行燃尽图的，因为这样可以有效的观察到项目的进度。而且对团队的心理情况也有良好的促进作用。但是这两天一个问题一直困扰着我。当我们采用场景、用例迭代开发的时候，我们还能否采用燃尽图来观察进度，我们如何有效的观察和控制进度？ 今天算是有一个可以接受的答案。 由产品人员给出场景（多个），代替以前的一大坨的需求。并建立Trac Ticket，类型为“场景”。 场景会被拆分成为两部分 测试人员根据场景拆分测试用例 开发人员根据场景拆分任务 这两部分是相辅相成的，需要测试、开发人员有一个大纲性质的沟通。 开发人员把拆分好的任务写入Trac，建立Ticket，完成任务卡。 开发人员根据任务（卡）完成燃尽图。燃尽的点为任务。 多个任务合并成为一个场景，完成之后可以单独上线。 这样可以结合现行的工具和流程的情况下，对流程进行初步的改进。希望会有一些好的结果。 晚上闲来无事时候，主动的去骚扰了一下开发的工程师，一起做了一个小范围的Code Review。内容大致如下： 区分行为和数据 用职责的眼光看待类 从使用者的角度看待API设计 内容虽然很少，感觉到他收益还是颇多。我们写代码的时候多思考一些，站的角度变一下，写代码会顺畅很多。

2010-03-02 晴 微凉 今天我们进入了正式的开发阶段，各个项目组也都开始按照自己的步骤进行下去了。 今天非常显著的几点进步如下： 产品、测试拆分场景 研发拆分用例为 TestCase Git 初步使用 今天我一直在整理新的开发流程，相对于以往，新的流程非常强调场景的概念。从产品的需求到最终上线，都是围绕场景的。（具体我会稍后详细解说） 对于场景，第一步也是关系着流程能否跑起来的关键的一部就是产品的用户“场景”。今天我们伟大的产品人员抽象了每一个用户场景，让我们测试和研发的童鞋非常容易入手。 对应着“场景” ，我们的产品、测试、研发都进入了角色，都开始了围绕着场景的战斗。 花开两朵各表一枝，我们先说产品和测试的用户场景。早上，产品和测试的童鞋采取了半结对的方式拆分用户场景，把每一个场景都拆分成为逻辑上可以测试的用例，并记录为Wiki。这样以后对产品的需求覆盖有据可循，也对研发的开发边界有了一个良好的指导。 我们再看另一路的研发。携昨晚测试童鞋拆分用例之威，今天研发的童鞋就已经开始撰写 TestCase，并且已经跑起来了。来，为他们呱唧呱唧。 TestCase 就没什么可说的，今天说说在使用过程中，尤其是初次使用的时候可能遇到的一些问题和疑问。最常见的是： TestCase 和功能性代码貌似只能迭代进行，无法先写完整的TestCase TestCase 中的那些只有名称没有实现的代码，看上去怪怪的。 先说第一个问题，如果是个人开发，当然是迭代进行最为爽快，用例完成，代码也完成。但是对于团队开发，而且是从业人员有梯度的情况，情况可能不同。因为有时候要以一个设计者的身份，有时候要以一个管理者的身份。这时候，我们可能需要更多的统管的一些责任，那么完成大多的TestCase是一种比较可行的办法。 对于第二个问题，其实使我们在开发中身份转换的一个情况。大多的场合，我们是开发的身份是开发人员，我们是细节，这时候我们的视角是从下向上看的。而在我们撰写TestCase时候，是一个使用者和设计者，这时候我们是需要从上往下看的。我们是API的第一批使用者，如果这些API我们自己用着都不爽，那么别人一定会来砍我们的。 另外，我们这次还有很重要的一个环节，就是每天晚上的Review。这里既包含对代码的Review，也包含对TestCase的Review。这里不再废过多的笔墨，我会找时间专项讲解的。 第二天的工作是充实的，我们感受到了团队在成长，感受到每个人在成长。真不错。

今天继续很早睡了，凌晨4点，够早吧。 完成了第一版的几乎所有功能，当然仅仅是完成了功能。在使用ScrumWorks进行自我管理的时候还是可以的，但是自己一个人就有一个大问题，就是基本上想到了什么任务就做什么任务，而没有从最初就设定一系列的任务然后自我分配，这就是项目管理的最大的问题。我想也许是因为一个人的缘故吧。但是这里面存在的一个问题就是，这样干到哪想到哪的方式，是很混乱的，几乎就是没有管理嘛。要非说有，也是存在于一个自己脑子里面的一时干不完的TODO list。 为了改变这个龌龊的做法，我对自己进行了如下的要求。 设定最终完成要达到的状态，也就是做的这个东西要满足什么需求 根据这些需求拆分功能和组件 设定Milestone，每一个Milestone要完成什么东西 根据情况设定工作时长，每一个Milestone的完成时间（这个可以酌情） 使用一个工具记录下来这些 Just Do It 这里面的几个难点 针对上面的要求1，很多时候我们是做不到的，也就是我们在做一个东西的时候，大多的时候只有一个笼统的想法，和最后我要把这个东西做成一个什么样子。但是具体的是什么，也许我们并说不清楚。这个东西越大，越说不清楚。所以，我要求自己停下来，好好的想，我到底要一个什么东西，我要干什么，要实现什么功能，要满足我什么需求，这个一定要想清楚。 针对上面的要求2，我们大多时候，是不能非常好的进行拆分的，我们缺乏的是经验，没办法，多做吧。 针对上面的5，一定要用一个工具记录下来，因为你不记录下来，没有监督，那不就是自我安慰了么。现在的工具很多，Trac，Redmine，很多很多的。最不济的，记事本你总有吧，纸笔你总有吧。 在这个为期两天的一个土鳖小项目里面，我发现工具的重要性，我现在是Bug，REF，什么的都放在Trac上面，但是我的Task，时间管理都是使用ScrumWorks（而且这个还是一个试用版）。我没有找到一个能够把他们都管理起来并且很容易结合的东西。对了，Trac 还不支持bzr。 看来没办法，只能自己写了。现在正在缓慢的进行一个项目，就是做一个完整的 Ticket，代码，时间管理的工具，最好天然的支持Scrum。

现在在给一个自己的网站 http://www.yes7080.com 写一个类似于百度贴吧的功能。当前合作者出去和老婆Happy了，暂时项目只有我自己一个人。想想，也不能瞎写，就使用一些东西把自己管理起来吧。 刚刚看完Scrum，发现和我平常期望的，理想的，使用的方法很像很像（看来我有慧根）。所以打算自己一个人试试看。并结合TDD等方法，把自己管起来。 毕竟，刚刚入门，而且一个人，难免有东施效颦，丢三落四的情况出现。 第一天，也就是今天凌晨1，项目初创开始新项目，使用bzr开启一个新的repository，开工。采用TDD，构建一个最简单的，最土鳖的测试用例，不要求很完整，只是一个对大多数常用功能的简单使用，目的是为了尽快的搭建出项目原型和框架。遵照Uncle Bob的谆谆教诲，在完成一个土鳖测试用例之后，成功的让Eclipse画出来一坨坨的小红线（编译不过嘛）。然后撰写真正的Interface，还有Abstract Class，真不错，终于编译成功。 收获：这个过程并不是一个浪费时间的过程，而是结合了思考，设计，具体请参见我的《初涉敏捷编程》。这过程中出现了很多的对API的推敲，对类的职能的思考。而且，在写真正的接口的时候，可以不用过多的考虑用不到的方法，也就是我总说的，关注一个类的职能。Duty Oriented. 2，开始功能实现有了用例和接口，就可以写实现了。因为项目的特性，一个只读的数据存储结构是最合适的。但是无奈项目时间紧迫，所以我没有这么充裕的时间去选型，甚至设计实现一个适合这个场景的存储结构。所以我把实现分成了多个部分，第一部分，也就是使用传统的数据库作为存储，这样可以最快的实现功能，并且满足现在访问量并不大的情况。以后随着访问量的增加以及时间的充裕，可以继续完善甚至更改存储体系。 醒目的目录结构是这样的./src./src/com/yes7080/saybar （存放所有的接口，并且这是使用时候的统一入口）./src/com/yes7080/saybar/impl （存放实现）./src/com/yes7080/saybar/impl/datamodel （存放使用datamodel，亦即使用数据库的实现）./test./test/src./test/src/com/yes7080/test/saybar （测试代码）实现使用了二级目录结构，也就是使用impl/datamodel，这样的目的就是因为以后可能出现其他的存储方式。而且，正因为这样从目录解耦，就可以更好的进行设计了（具体的设计思想，我以后会撰文解说的）。 很爽的写了很多，很土鳖的没有采用任何的项目管理。工具使用Trac，但是更多的是一个用于文档和Ticket跟踪。所以我决定对自己采用Scrum进行管理。也对自己有一个监控。 最开始，实话实说，我真的忘记了Scrum具体应该怎么开始了，但是非常简单，用户故事（是这样么说么）只有一个，就是实现一个用数据库的存储。我给自己两天的时间，也就是后天天亮之前完成，大约是还有10-16小时的工作时间。然后在看情况进行修改吧。嘿嘿~暂时给自己定一个时间，然后，继续工作鸟~~