Code reviews: a short introduction
-
Upload
freekdb -
Category
Technology
-
view
500 -
download
1
description
Transcript of Code reviews: a short introduction
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.”