Peering into the Process of Code Reviews

Jag heter Mike

Code Reviews can be scary.

Why do Code Reviews?

It Saves Money

It's 40 times as expensive to fix a defect in production as during early development.

Fix in Production

  1. Customer Reports
  2. Customer Service (CS) Verifies
  3. CS Sends to Project Manager (PM)
  4. PM schedules with Development
  5. Developer Verifies Bug
  6. Developer Fixes
  7. Developer Tests
  8. Developer sends to QA
  9. QA verifies
  10. Developer pushes live
  11. CS alerts Customer

Fix in Development

  1. Developer Fixes

Training & knowledge transfer

Big Clients Demand It

All Clients Appreciate It

Sleep Better

What Should I Look for?

Dictatorial vs. Conversational

Does this code work?
How can I break this?

Is this code readable?

How could this be more performant?

How could someone exploit this code?

Has this been fixed in every place in the codebase?

How Does this Work in Real Life?

Gitflow (modified)

Our Process


Build Feature or Bugfix in Feature Branch


Open Pull Request on GitHub and request a review


Developer Reviews, leaves feedback

Needs Work


Developer Reviews;
Approves or Sends Back

Needs Work


Merge away

Tack så mycket


(Or, ask me at the after-party)