Our employers, companies, and clients expect us to be professionals. They expect us to deliver quality products free of defects. How do we do that? Well, one way is to utilize code reviews.
Code reviews are a way of getting a second set of eyes on the code. When a developer is done with a particular feature, he or she may check-in a shelveset and request a review from another team member. The team member can provide a fresh perspective to the problem. They should be checking against the original user story. They should also be checking for any inconsistencies or potential problems in the code.
I’m primarily a .NET developer using Visual Studio and TFS. Formal code reviews can be completed easily within this environment. Reviews from within Visual Studio used to only be available through higher versions (Premium and above) of the product, but thankfully this feature has been added for Visual Studio 2015 Community and above.
Don’t just go through the motions
It’s important as a team to decide on what exactly should be reviewed. My personal preference is to review for both coding style and function.
If the naming conventions and coding style drastically differs from the rest of the application it may be quite jarring for the next poor soul that has to modify the code. When a developer is careless with his or her white space, or chooses poorly defined and meaningless variable and method names it’s questionable as to whether enough care was taken. A program should be consistent throughout and the reviewer should be aware of the style and provide direction if that style is not being followed.
If you’re the one doing the check-in and you’re looking for specific feedback, be explicit in your check-in comments. Follow up with the reviewer and work together to go over the items of concern. This is a great opportunity to pair-up and gain a better understanding during the review process.
Keep it short
Reviews should be short. In an effort to keep effected changes limited, the associated check-ins should be small. This should help keep the feedback loop fast. If you’re asking someone to review a major feature with hundreds of files and thousands of lines of code, that’s just too daunting a task to undertake in a single review. In the Agile spirit, keep the feedback loop small. Keep your changes narrow in scope and manageable.
Check-in against tasks and stories
For historical purposes it’s important that you check-in against Tasks and Stories. If you’re using TFS or VSTS for your code repository you can easily associate your changeset with a Task, Story, or Bug. I like to associate with a both a Task and it’s parent Story so that anyone looking for changes associated with a particular item can get the whole picture of what was involved with a particular change.
For reviewers as well as requesters it’s important to be courteous, constructive, and open to criticism. Remember, none of the comments should be personal and should be taken as such. The objective of the code review is to improve the quality of the product being delivered to the customer.
If, as a reviewer, you find yourself providing tons of feedback during a review, or if you’re overwhelmed by the amount of changes associated with the request, it may be best to seek out the requester. Spend some time with the individual and guide them to better practices associated with the code review process. Instruct them on better coding practices, if that’s where the majority of your comments were focused.
As a requester, take this opportunity to learn and grow as a developer. I’ve learned quite a bit from reviewers who were more knowledgeable than I with regards to a particular language, pattern, or application. Don’t be afraid to admit you don’t know something. Be willing to accept help when it is given. After all, the goal is to develop and deliver a better product.
Above all else, make sure the process is providing value. You may need to adjust the code review process to fit your team. Evaluate the process and see if there are any improvements that you could make. Make sure there is benefit to you, your team, your company, and your clients.
What other practices do you find important with regards to Code Reviews? What other processes has your team put into place?
A Microsoft MVP, John has been a professional developer since 1999. He has focused primarily on web technologies and has experience with everything from PHP to C# to ReactJS to SignalR. Clean code and professionalism are particularly important to him, as well as mentoring and teaching others what he has learned along the way.