Published on 05/05/2022 byNevulo
Getting a second opinion matters. When you’re shipping new features to, it’s important that all the requirements get implemented and everything works properly under lots of different situations. Otherwise, users are going to have a poor experience.
I can personally say it’s too easy for one person to miss simple problems that lead to bugs. It’s helpful to have more sets of eyes looking at the solution and seeing if it’s optimal and what comments/suggestions could be applied to improve it for everyone.
Code reviews have helped a lot in my career to catch mistakes, typos or other major/minor bugs when writing code to be used by thousands. But, what is a code review, why is it helpful, and how can we incorporate code reviews in a project?
A code review is where engineers in your team can inspect the code you’ve submitted to be shipped to production, and collaborate on comments and suggestions, before it goes live.
When you’re making any change to a codebase, typically you’ll publish those changes remotely to a repository, like on GitHub.
You can commit changes directly to the
main branch, which represents the most up-to-date copy of the code, and usually, whatever is on the main branch eventually gets sent to production, meaning real users see that change.
Instead of committing directly to the main branch, we can create a new branch off the main branch and just push the changes relevant for one piece of work.
When your changes are ready to go to production, you’ll create a “”, which is literally a request to pull your changes into the main branch.
In this request to introduce changes to the repository, others in the organisation get the chance to view the changes you’ve made, write comments on the changes, or provide suggestions for alternative solutions.
Reviewers can also:
Giving other engineers the ability to review your code gives them the opportunity to:
No matter the size of the change, developers in a code review should look to review the quality of the changes coming in and think about potential improvements.
Exposing yourself to code as much as possible is a surefire way to expand your vocabulary, identify anti-patterns, and ultimately help you and your team write better code.
Offloading the review process to other developers, who can offer different perspectives, helps teams remain agile and keep releasing new high-quality features quickly.
It’s also a great opportunity for others to learn new techniques or get suggestions to.
Other engineers can comment on readability, syntax, and other aspects of the code to improve the quality. These might be small changes like flipping an
if statement to improve the logic flow, or adding an early return.
Beyond reviewing just code and its literal syntax, code reviews also offer the opportunity for others to voice feedback on other aspects of changes like styling or functionality if something doesn’t seem right.
Develop guidelines and standards for reviewsand have written about what reviewers actually look for in a code review; things like architecture, functionality, readability, security, and much more.
Ask questions like:
Make sure changes are adequately tested
For particularly complex changes, automated tests help assert that all the requirements are being met under certain conditions. It will provide more confidence to teammates being able to see that all tests are passing in the CI/CD pipeline. This is known as “test coverage”.
To learn more,
Keep changes short, simple and readablethat performance is likely to drop in developers reviewing more than 300-400 lines of code, and it’s well documented that reviewing for long periods of time leads to worse performance.
Subscribe to the Nevuletter so you never miss new posts.