Feature branch code reviews

“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.

1. Start a user story.
2. Code the feature.
3. Push the feature to a branch.
4. A Github hook starts a CI build.
5. A Github Campfire hook posts your work to Campfire.
6. Click the link that’s in Campfire.
7. Click the Github “Pull Request” button.
8. It will smartly select all commits in your branch that are not in master.
9. Create the pull request.
10. Ask your team in Campfire for a review of the pull request.
11. The team comments in-line, right on the code.
12. Make the suggested changes.
13. Merge into master.
14. Push to master.
15. CI runs again.
16. Deploy to staging.

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:

Notice the 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.

Why we like it

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:

• The whole team learns about new code as it is written.
• Mistakes are caught earlier.
• Coding standards are more likely to be established, discussed, and followed.
• Feedback from this style of code review is far more likely to be applied.
• No one forgets context (“Why did we write this?”) since it’s fresh in the author’s mind.

I’ve personally loved this process. Give it a shot!

Written by Dan Croak.