7 Steps to Better Code Review

Steps to Code Reviews

In a field like software development that demands attention to detail, peer review is essential. When the slightest mistake can cause serious errors throughout the project, another set of eyes (or several) will help ensure that everything reaches its full potential. While there are automated tests you can perform to vet your code, nothing beats the human touch.

Code review had been demonstrated to significantly speed up the development process. But what are the responsibilities of the code reviewer? When running a code review, how do you ensure constructive feedback? How do you solicit input that will expedite and improve the project? Here are a few tips for running a solid code review.

  1. Establish goals. Code reviews are more than just finding errors and bugs.You may be thinking about adding new features and how to implement them. You may be trying to ensure that the code meets certain style standards established by your organization. Whatever the goals are, it’s important that you make them clear at the very beginning of the process, and that everyone on the team understands and works towards them. If each team member has a different goal or viewpoint, it will be difficult to reach a consensus and make progress.
  2. Do your first pass. Try to get to the initial pass as soon as possible after you receive the request. You don’t have to go into depth just yet. Just do a quick overview and have your team write down their first impressions and thoughts.
  3. Use a ticketing system. Most software development platforms facilitate comments and discussion on different aspects of the code. Every proposed change to the code is a new ticket. As soon as any team member sees a change that needs to be made, they create a ticket for it. The ticket should describe what the change is, where it would go, and why it’s necessary. Then the others on your team can review the ticket and add their own comments. Not only will this system help you keep track of all proposed changes, but the discussion will lead to further improvement and refinement of the overall code.
  4. Run tests. You can try to spot tiny errors by looking at line after line of code, but it’s often easier to run the piece of code in question and see how it works. In doing so, it’s easier to find bugs in the context of how they affect your application. It can also provide insight into what features are missing or could be improved.
  5. Test proposed changes. Put the code into your testing environment and see how it functions with the proposed changes. Do the changes work? Has the software improved, or have the changes caused more problems? Do these changes work for the project’s overall budget? What still needs to be done? Create more tickets for discussion, based on the tests.
  6. Do your in-depth pass. Now it’s time to sift through the lines of code with a fine-toothed comb and find the bugs, the style issues, the misplaced parentheses, etc. Some people prefer to do this before testing the proposed changes from the first pass. They’ll wait until the end and then test all the changes at once. But testing the changes from your first pass can help inform your second pass. Plus, testing as you go can save you time and money, as opposed to saving all of your testing to the end.
  7. Submit the evaluation. Minor changes such as coding errors and typos can be fixed as you go along. But major changes should always be discussed with the code’s author first. Ask yourself, is the change you’re proposing really a problem, or just something that you would have done differently? Because in the end, it’s their code, not yours. Once you’ve submitted your evaluation of the code, talk to the author and find out why they did things a certain way. Then tell them your approach and see what they think. Hopefully, you’ll be able to see things from each other’s point of view and use those insights to make the code the best that it can be.

A code review is one of the most important aspects of programming. It allows you to address problems more quickly and efficiently, and ultimately deliver higher-quality code and a better software product.

How will you make the best use of code reviews in your next project?



Author: Rob Whitcomb. Rob is senior software engineer at Surge. He has been building enterprise applications in a multitude of technologies for a decade. Surge is a company of Catalyte.


Originally posted on InfoWorld