Peer Reviews are a Good Thing™

An ounce of prevention is worth a pound of cure.

— Benjamin Franklin

What we read about, found out, and learned about Peer Reviews

• develop and choose workflows best suited for your team, project and the task to be reviewed:

  • code review / buddy checking: reviewer is reviewing alone
  • walkthru: the author shows step by step what has been done, why it has been done, and how it works:
    • here, often the benefits of rubber duck debugging apply:
      • the author, guiding the reviewer through the code, often finds issues while pointing out how everything should be working
  • group review
  • you might develop own checklists for code quality or project specific requirements (docs, comments, other conventions)

• general steps

  • read, interpret and understand original task (acceptance criteria)
  • find relevant code changes (feature, branch, commit, …)
  • read, understand code
  • test (run tests, test manually, …)
  • is everything super-good?
  • everything fulfilled?
  • code is at least as good as you would do it yourself or acceptable? (common style, guidelines)
  • do you see any edge-cases not covered? (empty values, …)
    • any missing tests?
  • what do you like about the code? tell the author!!
  • if you find small fixes you want to do yourself, tell the author and fix them
  • if it’s anything bigger, assign the task back to the author

• this is a usefulful procedure for both, the reviewer and the original author, all of the team and the project itself

  • the reviewer learns about other parts of the code, and the author’s personal style
  • it can lead to something like a common style
  • no piece of code will exist, that has only been seen by one pair of eyes
  • often, with a complex task, you’ll be happy about somebody checking your stuff:

  _

  “Hey, I think I finished ticket 1328, can anybody have a look at it please?”_

• avoid asking the author ‘why’ questions
  • these will be taken personally and we don’t want that, since:
  • this is not about blaming anybody, it is about the code
  • just re-phrase ‘why’ questions (unless you really don’t understand it)
  • you’ll thank me later
• take your time, this is just as important as developing
• bugs found at an early development stage
  • will cost much less to fix (~0.25)
  • are much less of a PITA to fix
• regularly cleaning out the tasks-to-be-reviewed ensures:
  • normal work speed
  • reducing bugs affecting other features developed at the same time