It’s not easy to perform a good code review. Often done in a hurry just to get it done, it only makes things worse. People treat it as an obstacle, not a helpful thing. I am gonna tell you why code reviews are important and how they can help you maintain good quality code. I will not only tell who are the code reviews for, how to raise a useful code review, but also how to perform a good code review in the quickest time possible.
Human Factors of XR: Using Human Factors to Design XR Systems
Effective code reviews
1. code reviews
Effective
ct
h ite
rc
eA
ar
ftw
So
-
k
re
Ma
n
s ti a
ba
Se
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
automation
• TDD and CI
• occasionally contributes
to open source projects
• wants to be a knight
https://joind.in/6947
@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
30. Kris “The Master
Reviewer”
Things checked:
• clarity • duplications
• performance • code quality
• excessive complexity • potential deployment
• impact on other issues
systems • design flaws
• does the solution
solves the problem
…by looking at things all important
31. • Knowledge sharing
• Mentoring new starters
• Find bugs/design flaws
early
• Improve overall code quality
• Fostering collective code
ownership
The benefits of a code review – they are for you!
32. DEVELOPERS
• Understand and accept that you will make
mistakes.
• You are not your code.
• No matter how much "karate" you know,
someone else will always know more.
• Don't rewrite code without consultation.
The soft side - developers
33. CODE REVIEWERS
• The only true authority stems from
knowledge, not from position.
• Critique code instead of people
The soft side – code reviewers
34. • Location 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
35. WHO?
• Seek the experts
– If you're not sure ask around
• Question the solution
– Make sure it fits the purpose
Summary - who assign the code review to?
36. WHERE?
• Make it traceable
– Bug trucking system, ie. Jira, Trac, Mantis, etc
– Code review tool, ie. Fisheye/Crucible, gerrit
• Conversation/Pair programming
– Just make sure outcome is captured
Summary – where to raise a code review?
37. • Use tools, don’t be a tool
• Check for duplications/
HOW?
complexity
• Asses impact on other systems
• Make sure code is clear and
self-descriptive
Summary - how to perform a good code review?