Developer perspective: Get ready for review!
Some time ago my good colleague Mojtaba wrote about our code review process. In his article, he lists our best practices. For instance, defining short user stories and generating short code review tasks (in terms of time). This is actually very important as we all noticed that code reviews can sometimes become time consuming tasks for the reviewing participant.
For example, my colleague made this nice new feature which spanned many components, etc., and I was the lucky one who got to look through it. I decided to look at the changeset(s), comparing code from before and after modification, but the sheer size made this approach challenging. I had basically broken our own best practices.
This got me thinking more about my own check-ins. How could I make the review experience less of a hassle for the reviewer, whom is also a developer that needs to go on with his/her own development tasks. Sitting an entire day or more looking through a big pile of code modifications is not optimal.
So, I spend much more time today thinking and dividing my work into smaller sub tasks and/or stories with much clearer goals. Check-ins have check-in comments, and the code checked in shall relate to that comment. No more ‘one big check-in with everything’ and no multiples with different focuses. This results in more, albeit smaller, check-ins, which are easier for a reviewer to understand, therein putting much less stress on him/her. These can even be divided among multiple reviewers for even increased knowledge sharing. I really see this situation as a win-win for reviewers and reviewees.
There you have it: code review does ensure beautiful code, but also beautiful check-ins!
Written by: Frederik Williams, Software Developer