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