Code Review

How to improve quality of the product using “code review”
Mikalai
alimenkou
Aleksey
solntsev

Alimenkou Mikalai
Java Technical Lead/Scrum Master at Zoral Labs
6+ years in software development
4+ years of working by Agile methodologies
Expert in Agile engineering practices
Agile coach at XP Injection
Solntsev Aleksey
Process Architect at Infopulse Ukraine
Agile volunteer
Certified Scrum Practitioner
Initiator and coordinator of translation of the cult book "Scrum and XP from the Trenches" into Russian
Agile coach at XP Injection

Agenda
Introduction and common principles
WhyCode Review works?
WhyCode Reviewcouldn’t work?
How to find reviewer?
Practices, metrics, tips and tricks

Where is quality better?

Goals of code review
Improve quality of code
Share knowledge
Improve collective code ownership
Check conformance
Verify completeness
Educate
Reach a consensus
Try other approaches

Classification
Less formal
Most formal

Common principles: roles
Third persons
A reviewer
An author

3
main reasons why code review works

Two pair of eyes are better then one

«Teddy bear» effect

Common denominator

reasons why code review couldn’t work
3

Interpersonal conflict

“Ego” effect

Too bored procedure

7
strategies how to choose a reviewer

1. «Daddy at home»

2. «Help yourself»

3. «Review contract»

4. «Control center»

5. «SWAT»

6. «Everybody dance»

7. «Adulterous relationship»

2
ways to drivecode review

1. ATR (Author driver review)
Yep, yep
I’ve added a couple of new interfaces. There are the implementation.
A reviewer
An author

2. RTR (Reviewer driven review)
Hmm… I don’t understand what you try to verify using
this test.
Actually, I’m also a little bit confused …
A reviewer
An author

7
answers you shouldknow

What should we start with?
A reviewer

What to review?
Look at code changes/differences
Review whole solution
Identify methods/functions and classes

How to organize code review?
Use changes package (email, patch, etc.)
Use separate branch in VCS
Use distributed VCS
Code exchange tools built in IDE
Specialized instruments

How to organize code review?

Should we use metrics?

How long?
60

Fast or slow?
500

Big or small commits?
400

How to start?
1. Make common decision
2. Start slowly
3. Select only the most
problematic modules
4. Inspect and adapt

8
tipsand tricks

Before or after check-in?

Track reviewers
Not for blame
Easy to find person who also knows the code
More responsibility for reviewer

Checklist – make your live easier
Has error handling code been tested?
Are objects accessed by multiple
threads thread-safe?
Are variables initialized before
they are used?

Comfortable conditions for reviewers

All rules should be on WIKI

Use pen and paper

Use static code analysis

Easy, tiger, easy

And what …

Q&A
Email us:
mikalai.alimenkou@xpinjection.com
aleksey.solntsev@xpinjection.com

http://lib.custis.ru	659
http://xpinjection.com	298
http://kuaa.ru	236
http://agilebasecamp.org	55
http://www.slideshare.net	29
http://wiki.office.custis.ru	9
http://static.slidesharecdn.com	2
http://www.lmodules.com	2
http://hghltd.yandex.net	1
https://kuaa.ru	1

Code Review

by Mikalai Alimenkou on May 29, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

10 Embeds 1,292

Statistics

Code Review — Presentation Transcript