Peering into the Process of Code Reviews
Hej!
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.blog.smartbear.com/sqc/4-reasons-developers-resist-code-review-and-why-they-shouldnt
Fix in Production
- Customer Reports
- Customer Service (CS) Verifies
- CS Sends to Project Manager (PM)
- PM schedules with Development
- Developer Verifies Bug
- Developer Fixes
- Developer Tests
- Developer sends to QA
- QA verifies
- Developer pushes live
- CS alerts Customer
Fix in Development
- 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
1
Build Feature or Bugfix in Feature Branch
2
Open Pull Request on GitHub and request a review
Review
3
Developer Reviews, leaves feedback
Needs Work
4
Developer Reviews;
Approves or Sends Back
Needs Work
5
Merge away
Tack så mycket
Questions?
(Or, ask me at the after-party)