The two words “Code Review” can strike fear into the heart of any developer. But it doesn’t have to be that way! If you do everything possible to get out of a code review then maybe you’ve been doing it wrong. Without doubt, ETL code reviews are time consuming processes that take you away from coding. But over the years I’ve learned to use code reviews to my advantage, and here are 8 reasons that you too should be doing code reviews.
1. Ensure code satisfies requirements, adheres to design, and follows standards
Wait! I thought a code review was for getting get rid of bugs? It sure is, and we’ll cover that reason next, but from a project/company perspective it could be argued that this reason is more important. If the code doesn’t satisfy the requirements, then there is no point in going any further. Similarly, if the code doesn’t follow the design and standards, then it may not be suitable for production.
2. Eliminate bugs not found in unit testing
This is what most people think a code review is for. You’ll certainly be on the lookout for bugs. In my experience, I eliminate a lot of my own bugs when I compile the code review document itself. This is even after the unit testing is complete. In my code review document, I add additional information that isn’t readily apparent from the code or the documentation/comments included with the code.
Tip: If you find yourself adding verbiage to the code review document to explain what the code is doing then consider adding that same verbiage back into the code itself.
3. Verify ETL performs in acceptable manner
I’ve seen enough ETL code since 2007, and SQL over the past 20+ years, that I can often look at code and tell if it is going to perform well or not. But in a code review, the developer should provide documentation that proves that the performance is acceptable.
4. Confirm the code is maintainable
Nobody wants to have to maintain spaghetti code. This is your opportunity to make sure that code that could be a nightmare to maintain doesn’t make it into production. After all, it could be you that has to maintain it!
5. Rein in overly creative solutions
Does it look like the developer set out to use as many unknown features as possible? There may be a solution that doesn’t involve as much complexity.
6. Develop new standards
When I run into a situation where the existing standards don’t cover what I’m coding, I try to get a new standard created and approved before the code review. But this doesn’t always happen – so during the code review it may be recognized that a new standard has to be developed.
Tip: Consider deferring the development of new standards to a process outside of the code review. There often isn’t enough time during the actual code review to thoroughly spec out new standards.
7. Educate junior developers
There are published studies that discount this item and for that reason it’s almost at the bottom of the list. But I want a junior developer in on a code review (as a reviewer) long before they are the subject of a code review. I want them to know what to expect.
The other side of this item is that a code review is an opportunity for more senior developers to instruct junior developers on how to write better code.
8. Reduce time in QA/UAT
Eliminating bugs before the code goes to QA/UAT requires less time and effort. Once the code is out of development there is often a lot more red tape required to change the code. SmartBear Software referenced a study by a customer in their white paper “Best Kept Secrets of Peer Code Review” that highlights the cost of not finding bugs early.
What project wouldn’t like to have an extra $216,000? That’s the amount that would have been saved by eliminating 162 bugs before the code ever made it into QA. And notice how the cost of fixing the bug INCREASES the longer it exists in the development life cycle.
I may not like having other developers find my bugs, but it kills me when a customer or end user finds my bugs. I prefer to kill bugs before they kill me.
I hope you will join me as I go through an ETL Code Review Checklist blog series – that includes a couple brief posts discussing the types of code reviews and some overall best practices.
Photo Credit: Spaghett! by pgsvensk, on Flickr