“Code review.” My knee-jerk reaction to that phrase? Nap time.
I’ll be honest, I never really felt engaged during “code review” meetings at the end of an iteration. It always took too long to get and discuss the code. The room would get warmer. We’d discover things we’d want to change. Many of those changes would never be made.
Since today is Boycott a Meeting Day, I thought I’d offer an alternative we’ve used lately.
Here’s the flow. Read Josh Susser’s post for the git commands.
Many teams use this “feature branch” pattern. The “code review” part is the Github pull request flow stuck right before the code goes into master.
Here’s what a pull request looks like:
jm-cm-client-sets-up-recurring-payment branch is compared to master.
And here’s what a comment on a commit looks like:
You could use normal git tools to check out a team member’s feature branch, view the history, etc., but Github one-ups bare git by adding a streamlined user interface and commenting.
Test-Driven Development moves code failure earlier in the development process. It’s better to have a failing test on your development machine than in production. It also allows you to have tighter feedback cycles.
Code reviews that happen right before code goes into master offer similar benefits:
I’ve personally loved this process. Give it a shot!
Written by Dan Croak.