成就高效DevOps团队的“降龙十八掌”第一式——codeReview？

什么不是codeReview

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

为什么要codeReview

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

如何进行高效的codeReview

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

方法论指导

待完善……

工具

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

过程控制

1、项目组的codeReview过程控制
……待完善
2、codeReview组委会的对于codeReview活动开展的过程控制
……待完善

3、线上codeReview的过程控制
……待完善： 基于gitlib和gitflow实现

在公司开展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这件事儿，并不容易，但我们在路上……

参考文章：

关于在线代码评审的几点考量
作为开发-codeReview的几种形式
大公司怎么做codeReview
如何选择codeReview的形式？
如何高效地进行codeReview
从codeReview谈如何做技术
codeReview的几个提示