Code reviews are a powerful tool in ensuring and maintaining quality in your application, but they can be very difficult to get right. When they're misunderstood or poorly executed, they can even make a bad situation worse.
In this session I'll use my professional experience to give you some tactics for getting great benefit from code reviews. We'll talk about tools, about process and most importantly about attitude! Whether you're a developer or a technical lead, come along and find out how to perform a genuinely useful code review and provide constructive feedback in the quickest time possible.
1. EFFECTIVE
CODE
REVIEWS
Sebas1an
Marek,
So8ware
Architect
Sebastian Marek
2. • a
Pole
living
in
Sheffield
• over
12
years
in
development
• Pascal,
C++,
PHP,
perl,
python,
Java
• co-‐author
of
2
PHP
books
• big
fan
of
process
automaBon
• TDD
and
CI
• occasionally
contributes
to
open
source
projects
• wants
to
be
a
knight
h?ps://joind.in/7056
@proofek
4. All characters
appearing in this
presentation are
fictitious.
Any resemblance to
real persons, living or
dead, is purely
coincidental.
Disclaimer
5. Tom “I Need It Now” –
The Owner
Harry “Just Get It Done” –
The Manager
The Team
6. Adam “The Night Coder” –
developer
Kris “Hackety Hack” –
master code reviewer
Bruno “It Will Work” –
apprentice reviewer
The Team
7. How much time do we need to
get this project done?
Well, design, coding, code
reviews, testing…
Do we really need to code review the
code? You surely know how to code, and
you have tested it and it works… Right?
Scenario 1
8. We're nearly done, just need to
get this code reviewed.
Hmmm… all the developers are busy, we
have no one spare. Let's skip it and get it
straight into QA…
Scenario 2
9. Hello Harry,
I need John to review my code.
John is busy, you can have Rob.
But Rob is a junior developer, and he
doesn't know this system.
You want it code reviewed or
not? Rob is all we've got!
Scenario 3
10. We do all these code review, spend a
lot of time on this, but the code that
hits production is still buggy. It's a
waste of time!
Scenario 4
11. Code review
Adam The Developer 9:31 PM (0 minutes ago)
to
Kris
The
Reviewer
Kris,
I got this code I need you to review.
Can you do it for me please? The code is in my repository on problem-fix branch.
Thanks
---
Adam
Click here to Reply or Forward
14. Code review
Adam The Developer 9:31 PM (13 minutes ago)
to
Kris
The
Reviewer
Kris,
I got this code I need you to review.
Can you do it for me please? The code is in my repository on problem-fix branch.
Thanks
---
Adam
Kris The Reviewer 9:44 PM (0 minutes ago)
to
Adam
The
Developer
Adam,
No problem at all, but where did you branch the code from?
I can’t identify the change set without it.
---
Kris
Click here to Reply or Forward
15. Version
control
• Specific
change
sets
• avoid
specific
commits
• Reviewing
patches
risky,
unless
automated
What to review
16. Code review
Adam The Developer 9:31 PM (25 minutes ago)
Kris, I got this code I need you to review. Can you do it for me please? …
Kris The Reviewer 9:44 PM (12 minutes ago)
to
Adam
The
Developer
Adam,
No problem at all, but where did you branch the code from?
I can’t identify the change set without it.
---
Kris
Adam The Developer 9:56 PM (0 minutes ago)
to
Kris
The
Reviewer
Kris,
Ah yes. Sorry. It’s branched from my master branch.
---
Adam
25. Kris
“The
Master
Reviewer”
Things
checked:
• clarity
• duplicaBons
• performance
• code
quality
• excessive
complexity
• potenBal
deployment
issues
• impact
on
other
systems
• design
flaws
• does
the
soluBon
solves
the
problem
…by looking at things all important
26. • Knowledge
sharing
• Mentoring
new
starters
• Find
bugs/design
flaws
early
• Improve
overall
code
quality
• Fostering
collecBve
code
ownership
The benefits of a code review – they are for you!
27. DEVELOPERS
• Understand
and
accept
that
you
will
make
mistakes.
• You
are
not
your
code.
• No
maZer
how
much
"karate"
you
know,
someone
else
will
always
know
more.
• Don't
rewrite
code
without
consultaBon.
The soft side - developers
28. CODE REVIEWERS
• The
only
true
authority
stems
from
knowledge,
not
from
posiBon.
• CriBque
code
instead
of
people
The soft side – code reviewers
29. • LocaBon
of
your
changes
WHAT?
– Repository
name,
branch
name,
branch
base
• Subject
of
your
changes
– What
have
you
changed
• Reason
for
the
change
– Why
have
you
change
it
Summary - what include in the code review
30. WHO?
• Seek
the
experts
– If
you're
not
sure
ask
around
• QuesBon
the
soluBon
– Make
sure
it
fits
the
purpose
Summary - who assign the code review to?
31. WHERE?
• Make
it
traceable
– Bug
trucking
system,
ie.
Jira,
Trac,
ManBs,
etc
– Code
review
tool,
ie.
Fisheye/Crucible,
gerrit
• ConversaBon/Pair
programming
– Just
make
sure
outcome
is
captured
Summary – where to raise a code review?
32. • Use
tools,
don’t
be
a
tool
HOW?
• Check
for
duplicaBons/complexity
• Asses
impact
on
other
systems
• Make
sure
code
is
clear
and
self-‐
descripBve
Summary - how to perform a good code review?