每日立会&代码Review

研发过程之代码评审

     在研发过程中，为了保证代码质量，很多团队都会使用代码评审，或者叫做代码Review。一般情况下，代码Review都会采用集体Review的形式。

   集体Review

   形式： 一个团队，大家坐在一间会议室里面。一人进行讲解自己的业务和代码实现，团队的其他成员进行Review，提出问题，发现问题和补充不足。

   这样可以达到以下的目的：

   1.Linus定律 "只要有足够多的眼睛，就可让所有问题浮现"。每个人思考和理解事情的角度不同，这样发现问题也不尽相同，人数越多，发现问题也就越全面。

   2.在进行补充和提出建议的过程中，可以达到组内的开发规范和标准的传播，使大家明白统一标准。

   3.在讲解的过程中，和大家提出问题，发现问题的过程中，可以达到经验和知识的共享。

   缺陷：耗时过长，在开发时间较短的时候，会造成时间压力过大。虽然能减少后期成本，但是对于当时来说，短期的压力。

 

   因为集体Review耗时过长，往往会耽误大家时间，特别是项目时间紧张的时候，项目负责人往往顶不住压力，选择不Review，或者选择自己一个人进行Review，把问题发给大家。

   负责人Review

   形式：项目负责人进行checkout所有代码，进行逐个Review，把发现的问题email或者当面告知相关人员。

   这样可以达到以下的效果：

   1.避免员工设计或者代码出现问题。

   2.可以达到项目负责人的开发规范和标准的传播，使大家了解其标准。

   缺陷：对项目负责人要求较高，并且耗用其精力过多，使其无法处理更多关键的事项。同时因为一个人进行Review，无法对问题进行全面细致的分析，容易遗漏问题。

 

    后来借鉴了结对编程的思想，把结对编程改为了结对Review，取得了一定的效果。

    结对Review

    形式：项目组成员进行结对，两人一组，互相Review对方的代码。每次进行轮换Review的对象。

    这种形式，中和了负责人Review和集体Review的优点，但是同时也中和了上面两个的缺点，达到的是一种均衡。

     效果如下：

           1）两个人互相Review的时候，可以达到这二人业务和经验交流。

           2）Review的过程中可以发现bug，并且在讲的过程中，讲述人也可以发现自身的bug。

           3）加快Review进度，相对于集体Review来说，可以大幅提高Review效率，同时保证一定的效果。

           4）可以达到组织知识的充分共享，组内的人会和每个人进行结对Review，可以全面传播组内人员的经验和知识。

       缺陷：1）如果两人经验都不足的话，技术交流的效果不明显。但可以通过和另外一人的交流时得到补充。所以建议最开始的时候，指定结对Review人员，一名经验丰富者带一名经验较低人员。

                 2）缺少足够多的眼睛，有些bug会被遗漏。

                 3）需要Review的双方都要有责任心，如果任何一方不负责的话，都会产生问题遗漏。

 

      上面三种Review各有其优点和缺点，建议项目上根据自己的情况进行选择，或者组合使用。现在建议的方式是每周1~2次结对Review，每2周一次集体Review，研发负责人根据情况进行抽查Review，或者在项目初期和后期进行加强Review。

敏捷

研发过程之代码评审

摘要: 在研发过程中，为了保证代码质量，很多团队都会使用代码评审，或者叫做代码Review。一般情况下，代码Review都会采用集体Review的形式。 集体Review 形式： 一个团队，大家坐在一间会议室里面。一人进行讲解自己的业务和代码实现，团队的其他成员进行Review，提出问题，发现问题和补充不足。 这样可以达到以下的目的： 1.Linus定律 "只要有足够多的眼睛，就可让所有问题浮现"。每个人思考和理解事情的角度不同，这样发现问题也不尽相同，人数越多，发现问题也就越全面。 2.在进行补充和提出建议的过程中，可以达到组内的开发规范和标准的传播，使大家明白统一标准。 ... 阅读全文

posted @ 2012-04-03 15:29 kaka思言丝语录 阅读(128) | 评论 (0) 编辑

每日立会之漠不关心

摘要: 每日立会本身是进行状态分享交流的会议，现在发现大多数的时候，立会上大家都是各说各话，互不关心，在一个人说自己的事情的时候，每个人都在想着自己的哪一点事。别人说的什么，做的什么，只有项目负责人关心，讲的人眼睛也只是在看着项目负责人再说。并且更没有人在项目上说一些大家共同关心的事情，或者需要大家进行关心的事情。 如果每日立会都只是这样的话，和走形式就很类似了，也没有大家聚在一起的重要性也打折了很多，这样也造成了一个效果就是需要项目负责人非常用心去关注每个人，关注每个细节，如果稍有遗漏，可能问题就会溜走了。Linus定律 "只要有足够多的眼睛，就可让所有问题浮现"，在这里也没办法 阅读全文

posted @ 2012-04-03 14:49 kaka思言丝语录 阅读(733) | 评论 (1) 编辑

每日立会之不含糊

摘要: 每日立会的时候，需要会议的组织者注意一些词汇和和现象，不可走形式，不然的话，立会就不会达到预期的目标。立会的一个主要目的是及时有效的发现问题和解决问题。如果在立会上没有能发现问题，或者忽视掉了问题，那么立会的效果就会大打折扣。 立会上大家所说的话中如果存在含糊的词汇，就需要引起组织者和大家的注意，含糊的地方，其实就是需要注意的地方。比如“比我想象的有些难”、“这个任务有些复杂”、“我理解错了”、“我的实现方式有了问题”、“我的还差一点就好了”，“昨天弄点别的耽误了”等等。乍一听，感觉有些合理，因为一些原因导致了延误，或者有些事情给延误了，但是这些地方其实就是问题的地方。 1.关键词汇... 阅读全文

posted @ 2012-04-03 13:57 kaka思言丝语录 阅读(916) | 评论 (3) 编辑

敏捷立会两三事

摘要: 一直在实验着敏捷的思想，记录在立会的过程中发现的一些小问题 1.各说各话，互不关心 现象：大家都在各自说着各自的事情，做的多少，准备做哪些。眼睛也是盯着开发经理，项目的主持人，而不是大家。一个人讲话的时候，其他人都在想着自己的那点事情。 对策：现在准备改成提问，随机抽取听的人，问问是否听明白上一个人讲的话，明白就好，不明白就问到明白为止。现在发现效果不错，大家的情绪一下子提升起来了，气氛也热闹起来了。 2.分享问题 现象：只是说了自己昨天做了什么，大块的，没有技术分享过程和心得分享。 对策：等待说完了之后，补充问一句，有没有什么想要分享的，和学习到的。或者知道他有... 阅读全文