对codeReview到底要明确什么？

什么不是codeReview

1. Code reviews 不应该承担发现代码错误的职责。
   Code Review主要是审核代码的质量，如可读性，可维护性，以及程序的逻辑和对需求和设计的实现。代码中的bug和错误应该由单元测试，功能测试，性能测试，回归测试来保证的（其中主要是单元测试，因为那是最接近Bug，也是Bug没有扩散的地方）
2. Code reviews 不应该成为保证代码风格和编码标准的手段。
   编码风格和代码规范都属于死的东西，每个程序员在把自己的代码提交团队Review的时候，代码就应该是符合规范的，这是默认值，属于每个人自己的事情，不应该交由团队来完成，否则只会浪费大家本来就不够的时间。个人认为“meeting”是奢侈的，因为那需要大家在同一时刻都挤出时间，所以应该用在最需要的地方。代码规范比起程序的逻辑和对需求设计的实现来说，太不值得让大家都来了。

为什么要codeReview

1. Code reviews 中，可以通过大家的建议增进代码的质量。
2. Code reviews 是一个传递知识的手段，可以让其它并不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码。
3. Code reviews 也鼓励程序员们相互学习对方的长处和优点。
4. Code reviews 也可以被用来确认自己的设计和实现是一个清楚和简单的。

如何进行高效的codeReview

codeReview应该以工程化的思想来做，在正确的方法思想的指导下，通过各种辅助工具来保证整个codeReview过程的质量，并对其过程进行不断优化迭代，更新我们的方法论。以期达到我们review的目标。

工具

• gitlib
• maven插件（阿里规约扫描插件）
• Jenkins自动化构建
• IDE重构、代码检查等

过程控制

1、项目组的codeReview过程控制
2、codeReview组委会的对于codeReview活动开展的过程控制
3、线上codeReview的过程控制

在公司开展codeReview工作看到的问题和想法

1、codeReview的推行，为怎么这么难？（发现的问题,由研发团队和需求团队的矛盾导致，没有时间进行codeReview（换句话说，发版任务需求、工期安排不妥带来的问题，并不是codeReview本身的问题，这里不再具体展开））
        缺少科学体系化的codeReview方法论的指导：导致，无法迅速站在巨人的肩膀上进行快速学习和成长。
            review的方式（强制&非强制、线上交流&线下会议、小片段&大模块、事前&事后、高频率&低频率），如何取舍
             时机如何选取？
             流程/过程，如何控制？如何持续改进？ 以上的一系列问题，并没有形成一个有效的理论支撑指导体系。
        配套的codeReview制度和文化不完善，导致“结果更重要”，也就是说，做出来更重要，做漂亮不重要。因为我的KPI和年终奖based on how many works I’ve done！而不是How perfect they are ! 
            第一：如何更有效地激励？（物质和精神奖励，双管齐下）
            第二：如何用数据和事实，量化codeReview的考核指标？
           
        
        尚未形成统一的代码规范，导致两类问题：
            第一：意见不一，影响review的效率。
            第二：团队根本不重视基本的代码规范，从而导致没有规范、风格不统一，根本无法愉快地进行codeReview。

         缺乏review的check-list。
             导致大部分的团队review过程产生困惑和迷茫，不知道要review一些什么内容，分不清阶段性的重点。毕竟，老司机是少数人，咱们很多负责review的人，其实
    也没有什么review的管理经验。

         缺乏强有力的工具和技术保证。
              一、没有高效的单元测试和接口自动化测试的保证，重构风险和成本巨大！
              二、软件开发、过程管理的工具利用不充分，大量的手工操作，导致review过程效率低下，review结果的产出差强人意。
        人员能力不足，水平层次不一（代码风格、基础知识等欠缺。）

2、想在各个团队高效地进行codeReview，我们还需要做些什么？（参考解决方案）
   从角色分工的角度：
       codeReview组委会
            前提：专人专项负责，加入个人考核和绩效考核、贡献度
             指导手册，提供codeReview方法论。
             深度培训和跟进，让各个团队落地方法论。
             持续总结和优化，不断改进方法论和实践过程。
            工具使用手册和文档的推广：在保证产品按时发版的前提下，逐步提高review的量和质。
                maven插件（阿里规约检查插件）配合Jenkins的巧妙使用，强制、增量、逐步改善代码的规范性问题。（适用于老代码、老项目重构场景）
                IDE：代码重构技巧、规范检查插件的使用，提高效率。
      产品或者项目的直接负责人
            进一步配合codeReview组委会，完善codeReview制度和文化。解决两个问题：
            第一：如何更有效地激励？
               首先，考虑直接和KPI、绩效、工资挂钩
               其次，从个人价值、公司价值等精神角度，充分调动团队中各类人群的积极性？
                    根据不同的人群，需求不一样，区别对待。
                    利用好玩事儿的精神，将金豆、荣耀、奖章等和codeReview充分结合起来
                        接入jira、gitlib和codeReview主题相关的数据。并玩事儿结合起来，直接分配或者发放荣耀、金豆。
                    评选codeReview最佳团队、个人（质量之星），当然如何评选以及如何奖励，也是需要精心设计一番的。否则，容易适得其反！
                    
            第二：如何用数据和事实，量化codeReview的考核指标？
                    通过jira，进行数据的分类统计。    
                   通过gitlib进行数据的统计、分析和抽查。（线上review的频度、质量）

      项目经理
            完善补充新人上手指导文档，新人上岗前培训和考核（侧重代码规范、工具使用、环境操作规范等，纳入经理考核项）
            促进团队传帮带氛围、定期技术主题分享。（纳入经理考核项）
             主动发现和帮助需要进步的团队成员。（纳入经理考核项）
            组织团队codeReview，并整理codeReview的相关数据、成果。（以备考核、晋升）
            督促技术专家和骨干，完成各项工作。（纳入经理考核项）
            检查新人各项工作的执行情况。（纳入每月、或者每周工作汇报中）

      技术专家和骨干
            第一步：要解决单元测试缺乏，和接口自动化测试管理平台缺乏的问题。
            其次是：提供和完善check-list
            最后：根据各自团队情况，定期进行主题技术分享
            
      新人和普通员工
            按文档或者规范、示例进行学习
            执行规范
            反讲（自己讲述给师傅们听，并通过带徒弟、新人进一步巩固）
          通过学一下、组织考试等。多积累。

总结

codeReview需要根据公司实际情况，在不同情况下不同阶段可以不断优化，不断适应公司当下的需求才是最好的方案，任重道远~