1.
How To Have Code Reviews
Your Developers Actually
Want
CAMERON PRESLEY
@PCAMERONPRESLEY
HTTP://BLOG.THESOFTWAREMENTOR.COM

2.
About Me
◦Software Engineer at Pilot Flying J
◦Musician, Boardgamer, Process Geek
◦Organizer of @FunctionalKnox and @Knox_Hacks
◦Work one-on-one with developers to help improve their
career

3.
Outline
◦Why We Should Have Code Reviews
◦Common Mistakes Teams Make
◦Good Code Reviews Look Like…
◦What I Look For In a Review
◦How I Do a Code Review

4.
What Do We Mean By
Code Review?

5.
Code review is systematic examination (sometimes
referred to as peer review) of computer source code. It
is intended to find mistakes overlooked in the initial
development phase, improving the overall quality of
software.
- Wikipedia

6.
Concept is not unique
to software development

7.
Code review is systematic examination (sometimes
referred to as peer review) of computer source code. It
is intended to find mistakes overlooked in the initial
development phase, improving the overall quality of
software.
- Wikipedia

8.
Why the focus
on finding bugs
sooner?

9.
Bugs cost more
the later they’re found

10.
How Much Does It Cost To Fix A Bug?
Time Introduced Requirements Architecture Construction System
Test
Post
Release
Requirements 1 3 5-10 10 10-100
Architecture - 1 10 15 25-100
Construction - - 1 10 10-25
from Code Complete 2nd Edition

11.
IBM found that each hour of inspection prevented about 100
hours of related work
Assuming $25 an hour, that means for every $25 invested,
$2500 was saved.

12.
Raytheon reduced its cost of rework from 40% of project
cost to 20% of project cost
The amount spent on bug fixes dropped 50%

13.
As professionals, we are responsible for doing what’s best
for our employer
Plenty of incentives for companies to have code reviews
But it’s not all about the company, what do we get out of it?

14.
How Many Of You
Are New To The Industry
(less than 2 years)?

15.
Developers start out knowing how to write code, but not
much finesse
Takes time to learn the nuances of development
However, it’s not just time in the job, it’s constantly learning
new techniques and perspectives

16.
Which developer would you prefer?
5 years of experience
or
the same 1 year of experience 5 times?

17.
How can you gain the experience?
By learning from those who came before you
There’s always someone who knows more than you and
code reviews provide a way to gain that knowledge

18.
The more experience you gain
The more employable you are
The more valuable you are

19.
Why We Should Have Code Reviews
It’s the right thing to do for the company
◦ Cheaper to fix bugs the sooner they’re found
◦ Relatively cheap way to mitigate risk for the company
It’s the right thing to do for us
◦ Allows us to perfect our craft
◦ Shows us how others think about problems

20.
Common Mistakes

21.
Reviewing too much

22.
We can’t review a ton of changes and expect to find any issues
◦ We can only focus on so much code at a time
But how much can we optimally review?
IBM partnered with SmartBear and Cisco to determine some best
practices for code reviews

23.
Source

24.
Instead, break the down the work
We should strive for smaller pieces of work
Big changes will happen
◦ Need to have more frequent code reviews

25.
Opinion Based Improvements

26.
Stick to facts and ideas with reasoning
It’s normal for us to think “we wouldn’t of done it that way”
when reviewing code
But the goal is to not have everyone code like me
If you have a suggestion, make sure to back it up with facts,
not with gut reactions

27.
Attacking the Developer

28.
Instead, Attack the Code
Ownership (using “we” instead of “you”)
◦ “What should you do when the array is empty?”
◦ “What should we do when the array is empty?”
Code is the problem (not the developer)
◦ “This for loop is garbage, what in the world were you thinking?”
◦ “I’m having issues understanding this for loop, can you step me through what
it’s doing?”

29.
What Does A Good Code Review Look Like?

30.
A Good Code Review Will Have
Tight Collaboration
◦ Are both people working together?
Fact Based Improvements
◦ Are suggestions based on merit?
Knowledge Sharing
◦ Are both people learning something new?
Bugs Being Caught

31.
Tight Collaboration
Both you and the reviewer are asking questions
Discussion, not interrogation
No one person is doing all the talking
This leads to joint ownership

32.
Improvements Based on Facts
Can be hard to classify “good” code or to give feedback that isn’t solely opinion
based
Frame the suggestion with your reasoning why.
For example: “It looks like we have that same logic in a few different places, we
should extract that logic out to a shared function/method so if we need to
change it, it’s in one place.”

33.
Knowledge Sharing
One developer should not be solely responsible for a part of the
application.
Leads to problems like we can’t make changes without Cameron
here
By sharing business knowledge and the design of the code, other
developers can pick up the context quickly

34.
Knowledge Sharing

35.
Catching Bugs
Main business goal of code reviews are catching bugs
If a bug is found, add it to your review notes
After the review is over, go fix the bugs and get another review

36.
Good Code Reviews Look Like
Tight Collaboration
◦ Are both people working together?
Fact Based Improvements
◦ Are suggestions based on merit?
Knowledge Sharing
◦ Are both people learning something new?
Bugs Being Caught

37.
What I Look At
Quality
◦ Are there any bugs?
Readability
◦ How easy is it for me to understand?
Maintainability
◦ How easy is it to make changes?
Style
◦ Does the code follow language guidelines?

38.
Quality
Are inputs handled correctly?
◦ Does the code give the correct answer for the input?
◦ How about nulls? Empty arrays? Negative numbers, etc.?
Are errors handled gracefully?
◦ Does the app crash? Is the user presented with a message?
Edge Cases
◦ Does it handle input at the edges of validity?

39.
Readability
Source

40.
Readability
This is determined by your team
◦ Concise for one team is unintelligible for another
Clear beats clever, but what makes code “clear”?
◦ No surprises, the team can understand it
Write code simple enough for a junior to understand, but complex enough to
remove clutter

41.
Maintainability
Code is always in flux
The longer it takes for me to make a change, the costlier the work is
The longer it takes, the more likely I’ll make a mistake
Ensuring that relevant software design principles are being followed

42.
Style
Does the C# code looks like it was written by a C# developer?
Or more like a C++ developer?
Focus on
◦ Naming conventions
◦ Proper use of code constructs
◦ Project structure
Known as being “idiomatic”

43.
What To Expect From A Code Review

44.
High Level
You and the other developer (reviewer) will sit down to look at the changes
You’ll lead the review by showing what changes were made and why
Reviewer will make some suggestions and find some bugs
You’ll address the bugs and decide on which suggestions to implement

45.
Leading the Reviewer
What problem were you trying to solve?
◦ “There’s a bug when processing a transaction on Feb 29th“
What changes did you make and why?
◦ “Had to change our leap year logic”
Is there an area in particular you want the reviewer to focus on?
◦ “This section works, but I think it could be written cleaner, what do you
think?”

46.
During the Review
Questions will be asked
◦ “Could you step me through how you found this bug?”
◦ “What happens when the year isn’t a leap year?”
Suggestions will be made
◦ “This leap year logic is being used elsewhere in the application, we should
probably extract it out”
Bugs will be found

47.
How I Do Code Reviews

48.
Features

49.
Framing – Understand the Need
Describe the pain point in business terms
Not only frames the problem in terms that your user
understands, but it teaches the business
If using Domain-Driven-Design, helps with ubiquitous
language

50.
Inspection – Examining the Solution
Does the architecture make sense?
◦ If the application is service-oriented, then it doesn’t make sense for the feature to be
layered
Is it maintainable?
◦ It’s ok to have technical debt, but we’re looking for mortgage on a home, not Ferrari
on a credit card
Are the tests well written?
◦ You are writing tests, right…?

51.
Verification – Trying Out the Feature
Use the new feature like a user and see how well it solves the pain
point
Keep an eye out for steps that don’t make sense or where technical
details bleed through
◦ The “View Report” option is under the “About” file menu
◦ Dumping an exception message to the main window
◦ Telling the user the application lost connection to its database

52.
Reviewing Features
Have we identified the pain point?
Does the solution follow current architecture?
Does the code follow our standards and guidelines?
Are there tests over the new functionality?
Does the feature work seamlessly, or are there rough patches?

53.
Bugs

54.
Framing
In basic terms, what is the problem?
◦ Focus on what the user would be doing and stick with your domain language
Can you consistently reproduce the error?
◦ If we can’t consistently reproduce the problem, how can we verify that the
bug is ever fixed?
Have we found the root cause?
◦ Have we found the source of the issue? Or are we just patching a symptom?
◦ Common mistake when working with new developers

55.
Walkthrough – Developer Fix
Two different approaches
◦ Start with the big picture (i.e. how everything hangs) and then drill down to
the affected pieces
◦ Start with the pieces to build a foundation and then walk it up to form the big
picture
Avoid bouncing back and forth, the code should be telling a story, therefore the
review should have a flow

56.
Walkthrough – Special Focus
Is there any part that the developer wants some extra attention on?
◦ “This works, but I think there’s a better solution, do you have a suggestion?”
◦ “The business rules for approving this request is tricky, can you help me
double check it?”
Remember, the goal is to find bugs sooner than later
◦ So if there’s a particular rough spot, call it out and make sure you get it right
Asking for help is not a weakness, it shows maturity

57.
Walkthrough - Reviewing
Majority of code review should be spent here
Provides feedback on the work done, ideas for improvement
Check that the code is readable, maintainable, follows correct style,
and is of adequate quality
Developer and Reviewer agree on changes needed (if any)

58.
Verification
Demonstrate the fix
◦ Verify that the bug no longer happens with the fix
◦ Bonus points if you have a unit test that fails because the bug
exists
Are there any other workflows impacted by the changes?
◦ If there are, can we verify we didn’t break something?

59.
Reviewing Bug Fixes
Can we reproduce it?
Have we found the root cause?
Does the fix follow our standards and quality?
Are any workflows impacted by the changes?
Have we functionally verified that the bug is fixed?

60.
Wrapping Up
◦Why We Should Have Code Reviews
◦Common Mistakes Teams Make
◦Good Code Reviews Look Like…
◦What I Look For In a Review
◦How I Do a Code Review

61.
Resources
The Clean Coder: A Code of Conduct for Professional Programmers by
Robert C. Martin
11 Proven Practices For More Effective, Efficient Peer Code Review
Code Complete 2nd Edition by Steve McConnell
Peer Reviews in Software – A Practical Guide by Karl E. Wiegers

62.
Contact Information
Email: Cameron@TheSoftwareMentor.com
Twitter: @PCameronPresley
Blog: http://blog.thesoftwarementor.com