Code Review 百科内容来自于: 百度百科

Why we do Code Review(为什么进行)

1提高质量
2及早发现潜在缺陷与BUG降低事故成本
3促进团队内部知识共享提高团队整体水平
4评审过程对于评审人员来说也是一种思路重构的过程帮助更多的人理解系统

Types of Code Review(代码评审的几种类型)

一般来说代码评审分为正式代码评审与轻量级代码评审俩种

Formal Code Review(正式代码评审)

Fagan inspection范根检查法:
RolesAuthor/Designer/Coder: 作者
Reader: paraphrases the document阅读者
Tester: reviews the document from a testing standpoint评审员
Moderator: responsible for the inspection session, functions as a coach协调人
Recorderrecord detects.(记录员)
Flow

Lightweight Code Review(轻量级代码评审)

几种常见的轻量级代码评审方式
Over-the-shoulder – One developer looks over the authors shoulder as the latter walks through the code.它由作者启动和主持评审作者向评审者展示文档优点是启动快成本低缺点是容易被作者误导过程
Email pass-around – Source code management system emails code to reviewers automatically after checkin is made.优点自动化可以及时提供最新代码进行评审缺点是无法达到人工筛选的功效
Pair Programming – Two authors develop code together at the same workstation, such is common in Extreme Programming.源于XP作者与评审者平级可以帮助同伴间的学习和共享
Review Meeting – (定期组织review会议轮流有团队成员选出自己的评审作品需要系统化得预备总结和追踪优点可以提高团队整体技能和对产品的理解缺点是评审范围有限成本较高 )
Tool-assisted code review – Authors and reviewers use specialized tools designed for peer code review. 大量的代码评审工具比较流行的checkstyle/findbugs/pmd
本文以下内容都是指针对轻量级代码评审进行进一步讨论

Options of Code Review(代码评审的选择)

1最近一次迭代开发的代码
2系统关键模块
3业务较复杂的模块
4缺陷率较高的模块

Practice of Code Review(代码评审实践)

代码评审不是批斗会不能以缺陷和错误来打击开发人员的积极性评审的目标的提高质量和提高整体水平作者应该带着学习和提高的态度来参加评审
代码集体所有制对发现的问题要本着整体承担责任 的原则因此建议把代码质量与团队绩效而不是个人绩效挂钩
评审程度进行一次整体的地毯式的评审成本很高
代码评审的可操作性首先需要评审团队具备经验丰富的系统架构师和精通业务的行业专家其次团队需建立其开发规范或指南在项目初期建立少量的Sample代码与checklist为评审提供依据
评审人员的职责是发现工作成果中的缺陷并帮助开发人员给出消除缺陷的办法而不是替开发人员消除缺陷
记录评审中出现的问题跟踪改进
评审前充分准备评审后详细总结
不要因为时间和成本问题取消评审
$firstVoiceSent
- 来自原声例句
小调查
请问您想要如何调整此模块?

感谢您的反馈,我们会尽快进行适当修改!
进来说说原因吧 确定
小调查
请问您想要如何调整此模块?

感谢您的反馈,我们会尽快进行适当修改!
进来说说原因吧 确定