Code reviews, feel that squirming feeling?
For the past year that I have been working within this company I have found myself with a number of significant applications that have fallen under my mandate. Some of these applications have been designed by myself, others by third parties external to the company and some I have inherited as legacy applications. There is not one set framework between all these applications, some are coded in Ruby, others in Java, PHP, VB, Rails...the list is pretty much endless. So as you may know I have handed in my required notice for the company and with about 1 and a half months of notice remaining here I have begun the unenviable task of documentation.
Yes, yes, I hear your cries of procrastination, yes much of the documentation should have been completed with their original owners, however times have changed. This company is no longer a startup, processes are beginning to mature and documentation must be completed at all costs. So now as I sit before the lists of applications which must be handed over I'm discovering all sorts of pesky yet vital applications which I have had some impact on in some form or other this past year. Apparently I am the technical owner for all of these applications, some of which I have never heard of before. Most modern IT companies are like this, back 5-10 years ago it was natural to fire up access and pull up an application that does a bit of importing of raw data, tidies it all up and shoots off a pretty looking report full of breakdowns.
Much of the code is well written, others not so much. Not all of the code contains comments and some code contains such horrors that leave me wanting to gouge out my own eyeballs after viewing it. Such treats that I talk about should never be mentioned or ever see the light of day. Code reviews are vital however are not as common as perhaps they should be within many companies. I will be facing a number of code reviews whilst doing these handovers over the coming weeks and came up with some thoughts on the process
Review the code, not the developer.
Let's face it, people can be assholes at least some of the time during their life. Don't be one during a coding session, everyone makes mistakes but it is how they learn from them that counts.
Short regular sessions
Don’t make it too long, an hour is ideal per session. Reading code at the best of times can be a tedious exercise, reading other peoples code can be even more so. Remember that this should be an on-going process and is a vital necesscary part of creating productive and efficient code.
Be prepared
I had this sudden image of the scouts motto there. Anyhow most of your time should be spent in preparation. Of course, you want the handouts, program listings, documentation, diagrams, flipcharts, and other meeting necessities prepared in advance so as to not waste people’s time.
Own your code
Don't be afraid to stand by your code. It is a learning experience and these sessions will make developers write better code in the future. All participants in a review should feel that they can speak openly. As a reviewer, give comments in a constructive and positive way. As the developer, don’t take comments personally. You’re all there for the same purpose.
At the end of the day, laugh about screwups, don't take it personally and learn from the experience. Everyone wins!
Write a Comment