On code reviews

What I learned today — 26 March 2018

We’re currently in the midst of a debate about how much effort should be placed on correcting code following a review. The other side of the debate says, “If it’s not bust, don’t fix it, but learn from it and do it better next time.” I, for one, am sceptical of how well that learning will take place if the person who wrote the code isn’t fixing it. That is one of my chief ends when conducting the code review — I want my team members to improve their skill as developers.

There is also the matter of quality. I feel that it’s unprofessional of a team to not write the best code that they can. I’m not talking about gold-plating. If we knowingly produce code that is not the best that we can create under the constraints that we face we are unprofessional and we are passing deficient code on to the developers to come after us, or to our future selves. I won’t even mention the risk of obscure bugs hidden in poorly written code.

As a compromise it was suggested that when doing code reviews we simply fix the simple issues that we uncover and require the author to fix the more significant problems. This led me to wonder: What if we pair programmed on those more significant problems? This will be an even more efficient way of fixing the issues and an opportunity to really solidify the learnings desired. Along the way we may also cover the smaller issues in the course of regular pair programming.