Code Reviews: what, why and how

An short introduction to code reviews.

August 17th 2012

Freek de Bruijn (NBIC)

Presentation overview

• what are code reviews, some different ways of reviewing code

• why would you want to do code reviews, what makes sense and what not

• how can you do code reviews, real world experience

• David will assist us to review the D2RQ project this afternoon

• we want to invite you to present a project for code review in a future meeting

WTFs/minute - Thom Holwerda

What are code reviews?

• take a fresh look at the source code• goals: improve quality, remove bugs and share knowledge• different ways:

• informal walkthrough (author leads through code)• pair programming (continuous or occasional)• formal inspections (extremely thorough)• discuss informally with a group like this: preferred ways of

coding, in-depth presentation of a project

• focus is on overall design, class structure, understandable names, optimal use of libraries, applicable design patterns and elegant code

• focus is not on things you can automatically check with tools (like for example CheckStyle, FindBugs and PMD for Java code)

Why do code reviews? (1 of 3)

Why do code reviews? (2 of 3)

• find and fix bugs as early in the project as possible• have constructive discussions on improvement opportunities• learn from studying each others code• distribute knowledge: collective code ownership• educate new team members• enhance team spirit and grow collective values• it just makes sense, like peer reviewing scientific articles

Looking forward to a code review - Todd Presta

Why NOT do code reviews? (3 of 3)

• doing code reviews take a serious investment and changes the way you work

• it takes too much time to really understand new code that does anything non-trivial

• developers prefer to spend their time on “their part” of the system

• most of the feedback is very general and/or focuses on minor details

• the team is too small to do effective code reviews• the code will only be used for a short period (or will it?)• management does not believe in code reviews• the code is already very good, there’s hardly anything to

review…

Be positive - Cyanide & Happiness

How can you do a code review?

• be constructive and positive!

• different ways:• informal walkthrough (author leads through code): transfer

code, introduce new team members, explain to a colleague why you think the code should work… ;-)

• pair programming (continuous or occasional): it is part of the process to look at the code and discuss different approaches

• formal inspections (extremely thorough): next slide• discuss informally with a group like this: we will try it out by

looking at the D2RQ code this afternoon

• you are welcome to suggest a (or your) project for a future code review

How can you do a formal inspection (IEEE 1028)?• management preparation

• planning the review

• overview of review procedures

• [individual] preparation

• [group] examination

• rework/follow-up

Using tools to support code reviews

Where can you find more information?

• interesting articles on Coding Horror with lots of commentscodinghorror.com/blog/2006/01/code-reviews-just-do-it.htmlcodinghorror.com/blog/2007/11/pair-programming-vs-code-reviews.html

• Code Review and Software Review described in detail on Wikipediaen.wikipedia.org/wiki/Code_reviewen.wikipedia.org/wiki/Software_reviewen.wikipedia.org/wiki/Fagan_inspection

• free book “Best Kept Secrets of Peer Code Review” from SmartBear Software (this company offers a code review tool)smartbear.com/solutions/white-papers/best-kept-secrets-of-peer-code-review

Any questions?

Bonus: culture at IBM (around 1980)

• Triumph of the Nerds (part 2, 5:30-6:52)youtube.com/watch?v=IbRmaIzGTOMpbs.org/nerds/part2.html

• “IBM is like Switzerland -- conservative, a little dull, yet prosperous. It has committees to verify each decision. The safety net is so big that it is hard to make a bad decision - or any decision at all.”

• “Rich Seidner, computer programmer and wannabe Paul Simon, spent twenty-five years marching in lockstep at IBM. He feels better now.”

• “At one point somebody looked at the process to see what's it doing and what's the overhead built into it, what they found is that it would take at least nine months to ship an empty box.”

Bonus: culture at a small startup (around 1980)• Triumph of the Nerds (part 1, 6:31-7:18 and 8:49-9:05)

youtube.com/watch?v=CFL9IyJ_qHkpbs.org/nerds/part1.html

• “Their hobby is their business and the culture they've created is identical to that of a thousand other technology companies. First, they dumped the idea of nine to five. In this industry, you can work any 80 hours per week you like.”

• Doug Muise (Software designer): “Eating, bathing, having a girlfriend, having an active social life is incidental, it gets in the way of code time. Writing code is the primary force that drives our lives so anything that interrupts that is wasteful.”