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!