I would like to share with you our internal policy we use to do Open Code Review, feel free to adjust it to your needs. I will be very glad if you share any experience, comments and thoughts you have!

Open Code Review process:

  1. What is needed:
    1. Two Moderators – one for each team to build team spirit – if team cooperates , it isn’t needed
    2. Moderators only guard the process, time-boxing and at the end gathering a summary, publish it on a Wiki
    3. Conference room booked for 1 hour (45 minutes for review, 15 minutes to summarize)
    4. Class source code printed out on A3 sheets (x2 sets) – less than 300 lines of source code – for largest class it will take more than one hour
    5. 6 attendees (conference room limit)
  2. Introduction:
    1. We are doing review of a code and not the person who wrote that code (!)
    2. Attendees should play role of maintainers of the code, are they able to find and solve a bug
    3. Split people for two teams, each of three persons
    4. Attendees should focus on:
      • Structure of a class
      • Readability
      • Are there any positives? – point that hard on the beginning
      • Testability
      • Are there any undocumented tricks / hacks?
      • JavaDoc comments are adequate to what class / method is doing
      • Is class intuitive to understand?
  3. Go:
    1. Allow to review the source code for 45 minutes, make notes (in English is preferable)
    2. Moderator should help to focus on above topics – if they stuck ask about above topics
    3. Finish the review after 45 minutes (definitively) – cut down any following discussion
    4. Summarize attendees ideas for 15 minutes – prioritize them
    5. Make recommendation / suggestion regarding coding style for the rest of team mates
  4. The end:
    1. Moderator should write down all the suggestions, recommendations and publish them on a Wiki with the source code
    2. Send an e-mail to all with the summary and with the link to the Wiki page