Effective code reviews

Effective Code Reviews

William Deurwaarder

30th of May, 2015

NextBuild

Think profit-based, not cost-based.

TomTom devices

2


TomTom products

Maps

Navigation

Traffic

Fleet-management

Fitness

3


Introduction

• Theory

• Creates awareness, explains philosophy

• Defines “defect” and explains its impact

• Practice

• How to improve the efficiency of reviews?

• What is role and mindset of author and reviewer?

• How to execute reviews?


Perfect code

What is perfect code?

• Working

• Readable

• Maintainable

• Extendable

• Elegant

• Simple and clear

• Well documented

• …

Easy to recognize, hard to describe


Not so perfect code

Why is real code not so perfect?

• Time-boxed

• Lack of experience

• Change on change

• Edge cases

• Built on legacy

• Mindset author (problem solving, result oriented, pragmatic, …)

• Multiple authors (own mind, no machines)

Easy to describe, hard to fight


Definition of defect

What is a defect?

• Highly unlikely defects

• Race conditions

• Timing issues

• Extreme load

• Trivial defects

• Subjective term

• Hard to predict impact of a defect

Defect: anything that may cause any additional cost later on


Cost of defects

Cost to fix defect grows exponentially

Consider 4 stages: design develop test production

Every stage adds additional cost factor of 10

• code review instead of test: 10x cost savings

• code review in stead of production: 100x cost savings

Finding/fixing defects early is always faster and cheaper than not finding or not fixing them


Cost of defects

1 single defect will pay for 100

99 defects never ever causes a problem 1 single defect causes a problem in production Question is: which one?

No significant additional cost fixing 5 or 50 defects

Building, Reviewing, Testing, Deploying

Fix ALL defects that you can find (no priorities)


Fix ALL defects

What happens next?

• No trivial defects any more

• No discussion on minor and major, just defect

• No subjective reasoning

Cleaner and more useful statistics as well

• Code gets higher quality and is easier to review

Increased developer pride, reduced ‘broken window’ effect


Change your thinking!

The cost of fixing everything is small, and the profit is much higher than the cost

Fix all defects that are found

• Ensure defects that cause issues are fixed

• Ensure defect that pays for all other defects is fixed

Think profit-based, not cost-based


Statistics

This is about applied statistics

Good engineers respect statistics

You are an engineer… respect and obey statistics!

Know: Many defects will never cause an issue if left unfixed

So: Fixing an individual defect does not necessarily reduce cost

And: Some (unlikely) defects will lead to great cost if left unfixed

But: You cannot tell which defect will cause an issue

Not about individual defects or reviews, about applying this practice continuously -> benefits


Theory summary

Defects enter our code for a lot of reasons

Defect is anything that cause additional costs

Cost to fix defect grows exponentially

Fix ALL defects

Think profit-based

It is all about statistics

Effective Code Reviews

(Practice)

William Deurwaarder

30th of May, 2015


Introduction

• Theory (previous session)

• Creates awareness, explains philosophy

• Defines “defect” and explains its impact

• Practice

• How to improve the efficiency of reviews?

• What is role and mindset of author and reviewer?

• How to execute reviews?


Improve quality

How can reviews address mentioned issues?

• Reviewer has different goal so different mindset

• Author solves the problem

• Reviewer checks code quality (guardian)

• Solution fits context

• Solution adheres to good practices

• Reviewer is not bothered by time (dead-line)

• Reviewer looks at code from different angle

Code review is an easy tool to increase quality


Increase efficiency of reviews

What can be changed to become effective?

• A: Ensure changes are ready (static code analysis, annotate)

• A: Limit number of reviewers (default is 2)

• R: Find as many defects as possible (time-boxed)

• R: Be thorough (address everything that catches the eye)

• Sharing knowledge

• Establish team-culture (abbreviations, code duplication)

• A: Fix ALL defects (no priorities)

• R+A: work together, same goal (peers)

• No need to defend yourself: “finding more defects is better”


Role and mindset author Problem solver – solution driven – time aware

• Prepare review (static code analysis, review yourself, annotate)

• Remarks aim to increase quality of code

• not to discuss author’s ability to code (no defense)

• Normally answer questions with comment in code

• Review will almost never be read again, code will

• Address ALL found defects (no priorities)

• minor defects take very little time to fix (no discussion required)

• Handle clearly incorrect remarks respectfully

• Discuss off-line; comment in code?

• Author is end responsible for changes and quality


Role and mindset reviewer Guardian – quality driven – time-boxed

• Execute review promptly (do not become a bottleneck)

• Make only remarks to improve quality of code

• Do not offer solutions or “better alternatives”

• Do not “educate” the author (off-line, coaching)

• Thorough, relentless AND respectful

• Can never find too many defects (slow pace)

• Avoid religious wars, no personal flavors, only technical

• Explain why something needs improvement

• Ignore amount of rework to fix defect

• Always re-review after author updated code (prompt)


Tone of review

• Be neutral, explain your interpretation

• Be aware of different mindset

• Be respectful (no SHOUTING!, no telling, no lecture, use keywords)

• Explain with reasoning in case technical solution needs improvement

• Single problem may have multiple solutions

• Search for reasons of unclarity (do not ask why to quickly)

Remember goal

• author is responsible for code quality

• reviewer helps author to establish level of quality

• working together as peers to improve quality


Examples

- What is this about?

+ The context is unclear, can you explain…

- This sucks…

+ This causes issues like x, y, z…

- Did you read the documentation at all?

+ The documentation specifies x rather than doing y…

- You should implement this completely different!

+ Doing x causes issues y and z in…

- NO, NO, NO…

+ This causes issues x, y, z in…


Defect remark strategy

• Gather context information (design, user-story, JIRA-issue)

• Focus on changes, keep eye on context

• Search for patterns and inconsistencies

• Check complexity (bang-for-buck, keep-it-simple-stupid)

• Let unconscious mind help (bell ringing -> investigate)

• Act like logical compiler (do not interpret code -> read code)

• Ask if something is unclear (comment should be added)

• Mark all style defects (diminishes quickly, static code analysis)

• Code removal – check correct and complete

• Use checklists


Practice summary

Author is responsible for code quality

Reviewer helps author to establish level of quality

Author and reviewer work together as peers

Reviewer is thorough, relentless and prompt

Author fixes all found defects

Reviewer review all changes Be polite


Code review rules

Time-boxed period to polish the code

Thank you

Any questions?

William Deurwaarder Head of Developer Relations, TomTom E-mail: [email protected] Website: http://developer.tomtom.com

mailto:[email protected]

http://developer.tomtom.com/


Code-review figures

Indication of important figures

• Minimum review time per session 5 minutes

• Maximum review time per session 60 – 90 minutes

• Maximum review size per session 200 – 400 LOC

• Default number of reviewers 2

• Maximum inspection rate 300 – 500 LOC / hour


Checklist for code-review (1/4)

Check consistency with design (see change in bigger scope)

• Verify edge-cases

Check consistency interface changes

• Scope changed (private to public; why?)

• Order of parameters (same in all methods)

• Symmetrical methods

• Use of default parameters

• Implementation details leak through in interface

Check level of containment (increasingly risky, increase scope)

• Within method

• Within private methods

• Within public class methods

• Within public interface of system (NavKit)



Check complexity

• Keep algorithms clean (no exceptional cases)

• Verify edge-cases… throw exception in stead?

• Try what-if scenarios

Check exception handling

• Is exception caught?

• Adheres to exception handling policy

• Exception handling aligned with surrounding code

Check readability, clarity (decrease time to understand code)

• Remove code duplication (extract method)

• Check functionality of method (reduce size of method)

• Add comments to increase readability



Check includes/imports (needed? correct?)

Check NULL-pointer behavior (can reference be used?)

Check const-behavior (consistent, no const_cast)

Check algorithms for one-off errors

Check resource leakage (memory, file handles, …)

Check multi-threading behavior

• Race-conditions

• Dead-lock situations

Check usage of members and local variables

• No state duplication (only for measured performance improvement)

• Superfluous

• No re-use of variables with different meaning



Check type-casts (discourage them)

Check surrounding comments

Check correct usage of libraries (STL, OSAL, …)

Check “early” optimization

• Is measurement in place?

• Is there comment with explanation?

Check use of deprecated code

• NavKit-examples: NavKitEnvironment, Tdes, CString

Check use of discouraged patterns

• Singleton

Check if tests exists

Effective code reviews

Technology

Transcript of Effective code reviews