Code Reviews: what, why and howAn short introduction to code reviews.August 17th 2012Freek de Bruijn (NBIC)
Presentation overview• what are code reviews, some different ways of reviewing code• why would you want to do code reviews...
WTFs/minute - Thom Holwerda
What are code reviews?• take a fresh look at the source code• goals: improve quality, remove bugs and share knowledge• dif...
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...
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 to...
Be positive - Cyanide & Happiness
How can you do a code review?• be constructive and positive!• different ways:   • informal walkthrough (author leads throu...
How can you do a formal inspection (IEEE 1028)?•management preparation•planning the review•overview of review procedures•[...
Using tools to support code reviews
Where can you find more information?• interesting articles on Coding Horror with lots of comments  codinghorror.com/blog/2...
Any questions?
Bonus: culture at IBM (around 1980)• Triumph of the Nerds (part 2, 5:30-6:52)  youtube.com/watch?v=IbRmaIzGTOM  pbs.org/ne...
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...
Upcoming SlideShare
Loading in...5
×

Code reviews: a short introduction

525

Published on

Presentation from the August 2012 NBIC (Netherlands Bioinformatics Centre) BioAssist programmer's meeting. Overview of the content:
1. what are code reviews, some different ways of reviewing code
2. why would you want to do code reviews, what makes sense and what not
3. how can you do code reviews (or formal inspections), some real world experience
4. using tools for code reviews
5. some links for more information
6. two bonus slides with a few links to gems from the Triumph of the Nerds documentary, well worth watching!

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
525
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • IEEE Std 1028 defines a common set of activities for "formal" reviews (with some variations, especially for software audit). The sequence of activities is largely based on the software inspection process originally developed at IBM by Michael Fagan. [3]  Differing types of review may apply this structure with varying degrees of rigour, but all activities are mandatory for inspection: 0. [Entry evaluation]:  The Review Leader uses a standard checklist of entry criteria to ensure that optimum conditions exist for a successful review. 1. Management preparation:  Responsible management ensure that the review will be appropriately resourced with staff, time, materials, and tools, and will be conducted according to policies, standards, or other relevant criteria. 2. Planning the review:  The Review Leader identifies or confirms the objectives of the review, organises a team of Reviewers, and ensures that the team is equipped with all necessary resources for conducting the review. 3. Overview of review procedures:  The Review Leader, or some other qualified person, ensures (at a meeting if necessary) that all Reviewers understand the review goals, the review procedures, the materials available to them, and the procedures for conducting the review. 4. [Individual] Preparation:  The Reviewers individually prepare for group examination of the work under review, by examining it carefully for  anomalies  (potential defects), the nature of which will vary with the type of review and its goals. 5. [Group] Examination:  The Reviewers meet at a planned time to pool the results of their preparation activity and arrive at a consensus regarding the status of the document (or activity) being reviewed. 6. Rework/follow-up:  The Author of the work product (or other assigned person) undertakes whatever actions are necessary to repair defects or otherwise satisfy the requirements agreed to at the Examination meeting. The Review Leader verifies that all action items are closed. 7. [Exit evaluation]:  The Review Leader verifies that all activities necessary for successful review have been accomplished, and that all outputs appropriate to the type of review have been finalised.
  • Code reviews: a short introduction

    1. 1. Code Reviews: what, why and howAn short introduction to code reviews.August 17th 2012Freek de Bruijn (NBIC)
    2. 2. 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
    3. 3. WTFs/minute - Thom Holwerda
    4. 4. 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)
    5. 5. Why do code reviews? (1 of 3)
    6. 6. 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
    7. 7. Looking forward to a code review - Todd Presta
    8. 8. 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…
    9. 9. Be positive - Cyanide & Happiness
    10. 10. 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
    11. 11. 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
    12. 12. Using tools to support code reviews
    13. 13. Where can you find more information?• interesting articles on Coding Horror with lots of comments codinghorror.com/blog/2006/01/code-reviews-just-do-it.html codinghorror.com/blog/2007/11/pair-programming-vs-code- reviews.html• Code Review and Software Review described in detail on Wikipedia en.wikipedia.org/wiki/Code_review en.wikipedia.org/wiki/Software_review en.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
    14. 14. Any questions?
    15. 15. Bonus: culture at IBM (around 1980)• Triumph of the Nerds (part 2, 5:30-6:52) youtube.com/watch?v=IbRmaIzGTOM pbs.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 whats it doing and whats the overhead built into it, what they found is that it would take at least nine months to ship an empty box.”
    16. 16. 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_qHk pbs.org/nerds/part1.html• “Their hobby is their business and the culture theyve 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.”
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×