Why Code Reviews are Integral to Software Development

As a software developer you’ve most likely heard the term “code review,” or you’re already doing them in your everyday practice. Regardless of your code review experience (or lack thereof) to this point, they should be an integral part of every software development team’s workflow – here’s why.

Why Do Code Reviews?

Programmers are human (at least for now), and all humans make mistakes. Just like journalists and authors who have their writing proofed by editors, developers should have peers review their code. A team member catching your coding mistakes is infinitely better than reading about them in public-facing customer reviews of your product!

Catching mistakes, however, is only the tip of the iceberg when it comes to the benefits of code review.

Sure, code reviews help catch bugs before they are merged into production code, but they also improve team cohesion through constant two-way peer feedback. Additionally, they increase visibility and accountability of the codebase across the entire team, thereby providing an increased sense of ownership to all members.

For all these reasons, code reviews should be an integral and non-negotiable part of any software development process, no matter what size team you have.

How to Conduct a Successful Code Review

A code review is the final step in the process of merging new code into an existing (or a new) codebase. The developer who has made the change, requests that another member of the team review the code that he/she has written. This request is usually made in the form of opening a “pull request” in a distributed software versioning control system environment, such as Github. It is important to limit the size of the change to be reviewed to a reasonable chunk – nobody wants to review 300 lines of new code!

What should be included in a code review?

Reviewee should:

  • Include a clear and concise description and summary of the changes that were made, as well as why the changes were made – ideally including the outcome associated with the changes.
  • Be open and receptive to feedback, and be prepared to make suggested changes.
  • Respond to questions from the reviewer.
  • Implement agreed-upon changes that result from the code review.

Reviewer should (ideally against a pre-established checklist):

  • Determine whether the change delivers business value.
  • Check that the program (still) works.
  • Check that the intended outcome, as described by reviewee, has actually been achieved.
  • Look for errors in logic that may only manifest in edge cases.
  • Look for style, and readability issues, which includes sensible naming of variables, functions, and files which all play a role in code maintainability.
  • Look for possible improvements in overall code quality:
    • Does the code adhere to the DRY principle?
    • Is the code over-engineered?
    • Is the code sufficiently commented?
  • Give constructive, respectful, well thought out, and meaningful feedback on:
    • Any mistakes encountered
    • Code maintainability concerns
    • Potential improvements that can be made
    • Things that are done well!

Code reviews should be viewed as a collaborative effort, from which the developers and the organization benefit. A growth mindset and a safe environment that encourages and respects feedback are required ingredients to establish and maintain a successful code review practice.

Summary

When teams operate within a “code review culture” they automatically feel more connected to the entire software project, and feel a greater sense of ownership. They also gain better visibility into the larger project, fostering a more engaged and effective team.

A common adage in the world of software and systems is “fail early” or “fail fast,” this means that it’s better to find out quickly that you’re on the wrong path so that you can get back on track before committing too many resources on moving in the wrong direction. Code reviews, properly and consistently performed, brings this adage to life. Code review is an opportunity to catch bugs very early, and even though resources must be consumed in order to perform code reviews, this practice pays off in the long run. It takes significantly less time to fix a bug after a code review uncovers an issue, than it does waiting for QA to find the bug and reject the code (QA then has to send it back to the original developer for improvements or corrections, before it can be re-submitted to QA).

And finally, code reviews foster an environment of shared learning, increasing every team member’s productivity and value to the organization.



Posted in Mobify Customer Resources