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



[fblike style=”button_count” showfaces=”false” width=”90″ verb=”like” font=”arial” float=”left”] [fbshare type=”button” float=”left”] [google_plusone size=”medium” float=”left”] [twitter style=”horizontal” float=”left” lang=”de”] [linkedin_share style=”right” float=”left”]

Verwandte Beiträge