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小时
: 要放在自己精力比较好的时间段