Agile code reviews

Here’s the TL;DR on this video from Olivier Gourment on Agile Code Reviews.

The video refers to slides you can’t see (extra download), historical facts and books, and audience participation, here’s the short version:

  • Have a check-list for things you should do in your code review.
  • Why? Because  humans make mistakes.
  • Many industries used check-lists very successfully to reduce fatalities, improve safety, quality and to eliminate the potential for human error. It has been proved to work tremendously well.
  • Humans tend to give up if the items in the check-list are out of date, lack value alignment or are too numerous.
  • Agile teams can use check-lists in an agile way – constantly inspect and adapt them.

How do we Introduce them?

  • Humans naturally choose to rely on habits and behaviours that they find easier.
  • If you want to make a change in your organization, you have to make it a habit….. Friends don’t let friends get away with committing  un-reviewed code.
  • Keep it simple, short and valuable.
  • Once it is in place at a basic level, and habitual, the team can start adding items.
  • Code reviews are best done together. The conversation alone can invoke better ideas.
  • Decide as a team what the policy is for interrupting/scheduling reviews.
  • Try not to have more than 1 day’s worth of code, or 200 lines per review.
  • Senior developers can be reluctant to expose their code to reviews, or perform them. – it is a difficult challenge.
  • Reluctance issues can be resolved by getting those individuals to elaborate what check-list they would create for another developer, find out what is valuable to them. (Ownership and autonomy)
  • Be wary of adding contentious items, they will affect buy-in. For example,”Errors should be caught” – is non contentious. “Coding style” – is more contentious.

Do you do code reviews in your organization? Do they help train good behaviour, prevent escaped bugs? Or are they tiresome chains around your wrists? Discuss below!


5 thoughts on “Agile code reviews

  1. I’ll add another bit to this, too — if you can automate in the build, do it. There’s no point getting a human to do what a computer can do better. So you push the devs up a level, to talk about code structure and architecture, and not brackets and such. Disallow checkins that break the rules, and buy tools for prettifying code; ReSharper’ll prettify a solution in moments.

    We don’t allow checkins without running jslint on our JavaScript, for instance. (grunt.js is your friend here…)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s