On Code Reviews - Part 1 of 3
I've been pondering writing about this topic for a while and never really had the time to corral my thoughts and write it up.
Until I flew to GHC and had time at the airport and on the plane :).
This is not an exhaustive coverage of code reviews and is meant as a basic understanding and guideline for engineers.
It amazes me how many engineers (both young and old) still don't know much about code reviews and I have encountered some who have been working for several decades and have never had to do a code review (begs the question what sort of architecture/design/implementation have they produced?).
Some, usually the latter category, are vehemently opposed to having their code "poked" at by others and believe that they are entitled to writing/designing whatever they choose regardless of what others might think. Generally, one tends to avoid working with such engineers, but, they do seem to pop up rather alarmingly frequently.
So, in short, code reviews are essential and all good software (and hardware interface engineers, if applicable) perform them religiously.
NOTE: A basic requirement for code reviews is to "Check your ego at the door". Your work is going to be reviewed/dissected and comments will arise that will not be easy to digest. This is a good thing.
A code review is not about you, it's about the code/product quality. And you won't be the only one - everyone has to go through it. So, deal with it graciously, be thankful that you have good reviewers and that you are, eventually, going to become a better engineer because of it.
What is a code review?
A code review is quite literally a reading/understanding and critical thinking process that is applied to programs/code that either needs to be shipped as part of a product or used internally by developers to build products. Written and/or oral feedback is given to the author on whatever is being reviewed so that s/he can incorporate the feedback and improve things before checking in the code into mainline or a branch.
By no means is this an exact method for eliminating all errors in a given piece of software, but, it is reasonably effective (if used properly) at identifying errors, potential errors and, eventually, providing quantitative and qualitative feedback to the author about her/his technical approach and implementation.
The review might also include architecture/design of the component that is being reviewed as a background for the reviewers, particularly if the code is a critical path in the product and/or interfaces with other critical paths in the product.
There are a whole host of other definitions for a code review, but, this is the one that makes most sense to me.
Why do we need code reviews?
Code reviews are and have been one of the few ways of mitigating programming and design risk associated with a product - early in the development cycle. Usually, it is a human process to understand and evaluate architecture, design and programming paradigms as well as algorithms in order to visually and conceptually understand how a given piece of a product works and is implemented.
In the end, code reviews help a developer/engineer become a better developer/engineer and, also, establishes technical standards within a group of developers/engineers, resulting in a better product in the end. It also provides a way for a team to understand and evaluate code that they might not otherwise know, should a bug in that piece of software appear in the field, and the original author may not be available to triage and fix it.
Apart from that, code reviews help developers identify integration issues well before the code is checked in and this alleviates the burden on QA/QE and, eventually, results in a better product in the end (again). The entire goal is to create a more robust, well-architected and well-designed product that has few bugs in the field and happier customers.
Leading to more money so you can afford that ridiculous mortgage and send your kids to a decent school... (I see this among all my married w/ kids friends).
Coming next...... Types of code reviews and pointers on how to conduct them effectively