Code Review（CR）

Code Review（CR）

Code Review CheckList

检查项	检查点
满足功能需求	满足业务需求、无遗漏
对现有代码的副作用	是否影响上、下游
并发	线程安全、同步、死锁、活锁
可读性和可维护性	易理解、可配置、无硬编码
一致性	编码风格、编码规范
性能	关注启动时、循环、频繁执行的情况
错误和异常处理	预定义、标准
简单性	简单优雅
可重用性	组件、代码是否可重用
安全性	身份验证，授权，输入数据验证、加密敏感数据等
单元测试	覆盖率

Code Review 环节

过程
: 作者大致讲解需求和整体设计，然后是核心代码
: Reviewer提出问题，作者确认是否是问题
: 对发现的问题进行记录，分类处理

内容
:  是否满足功能需求，有没有多做，有没有少做，有没有潜在的Bug
:  是否满足非功能需求。性能（高频调用的函数、核心算法）？可用性（异常处理是否完善）？可读性？
:  代码质量、规范

结束
:  Review一轮并不意味这个Review活动结束，因为还有待解决的问题，因此应该借助工具跟踪Review发现问题，指明问题的修复者、问题的验收人、问题的验收时间。当一次Review所关联的所有问题都得到修复之后，Review活动才算结束。

Code Review 原则

对所Review的代码逻辑应可以“完全看懂”
:  Good Case：对所Review的代码，掌握情况就像自己写的一样
:  Bad Case：在Review代码后，对代码的逻辑和背后的原因依然很模糊

好代码的标准，不仅仅是“可以运行通过”
:  正确性，可读性，可重用性，可运维性
:  Google：差一个空格也不行

Code Review和写代码一样重要
:  Code Review和写代码一样，也有产出：更高质量的代码
:  Review代码有时比写代码还辛苦：理解&找出问题

以提升代码质量为最终目标
:  Review双方共同努力的目标

**关于Bad Code的简单判断 **

【5分钟内不能看懂的代码】---------5分钟内无法让我看懂（认真前提下），这个代码一定写的有问题
【需要思考才能看懂的代码】--------好的代码：Don’t make me think！
【需要来回翻屏才能看懂的代码】–好的代码，经常在一屏内就是一个完整的逻辑
【没有空行/注释的代码】-------------不会用段落，不会写注释，肯定不是好的程序员写的代码

Code Review的注意事项

在必要时，Review的双方做面对面的沟通
:  背景、关键点的说明，便于Review理解
:  在必要时，应提供设计文档

对关键模块，应建立Owner制度
:  所有提交代码，必须由Owner做最终确认
:  便于由Owner掌握全局，并建立明确的责任关系

对Review中发现的问题，一追到底
:  在问题没有完全改正前，不能通过！

一行代码都不放过
:  对每一行提交的代码，都要Review

小步快跑
:  每次提交Review的代码量不要太多（减低复杂度）
:  几百行已经是很多了
:  特殊情况：一个新模块的构建，最好逐步完成（通过多次提交）

为Code Review预留出足够的时间
:  常见问题：只预留了写代码的时间
:  Code Review VS Coding，有时可能达到1：1（考虑到有时大的修改）
:  关键是要改变“CodeReview 不重要”的错误认识

每天Review代码的数量不宜过多
:  每次最多1-1.5小时
:  要放在自己精力比较好的时间段