16 Tech Leaders Share Smart Best Practices For Reviewing Code featured img

16 Tech Leaders Share Smart Best Practices For Reviewing Code

While tech leaders encourage each developer on their team to carefully craft and double-check their own code, that’s only one element of creating a clean, error-free product. It’s essential to have other experienced developers look over the finished work to make sure it’s error-free and efficient. A well-structured code review process takes time, but it can save significant problems down the road.

Still, there are ways to speed up the code review process and make it more than just a proofreading exercise. Experienced tech leaders often combine tools and techniques to make reviewing code not only run more smoothly but also provide a way to enhance mutual learning and team-building. Below, 16 industry experts from Forbes Technology Council share best practices they and their teams rely on when it comes to reviewing code.

1. Leverage Tools For Information Sharing

For us, code review is a continuous process. One tool we have found to be extremely helpful is loom.com. Integrating it with our kanban board allows us to significantly enrich the context of each ticket by adding screen-shared videos from the project manager requesting the ticket, feature demos and technical overviews by the developers, and any questions by any member of the team. This is a great way to retain knowledge and keep ourselves in check. – Joey Baruch, Alvarez & Marsal DIG

2. Establish ‘Rules Of Two’

We follow the “Two-Person Rule”: Each pull request needs to have at least two reviewers. One reviewer can be a peer, while the second reviewer must be a skip-level engineer. Also, each code review should have at least two revisions. It makes the code review process a bit slow at first, but it creates a culture of collaboration, promotes higher-quality code, and forces developers to learn more about each other’s work. – Shashank Agarwal, BridgeML

3. Focus On Logic Rather Than Formatting

We require all our projects to have automatic linting/prettying. We have documented patterns and best practices with the goal of making code reviews less pedantic—not focused on code style, patterns and formatting but instead on the business logic and bugs. – Ryan Vice, Vice Software, LLC

4. Make Code Review A Daily Activity

Our best practice is reviewing code on a peer-to-peer basis among team members at equal levels. Every team member can give a fresh set of eyes to detect bugs before a code revision round by the tech leads. It is one of our daily, routine activities, and that approach accelerates the software development process. – Dmitry Baraishuk, Belitsoft

5. Develop Written Guidelines

Pointing out mistakes in others’ code can be a sensitive process. I rely on written coding guidelines to enforce best practices. This way my team members just need to point to the relevant guideline rather than making the other person feel as though the reviewer is enforcing their personal opinion. – Himanshu Gahlot, Storepath

6. Set Up A Review Meeting Prior To Deployment

We handle code reviews during a meeting prior to deployment to provide context, background and rationale for the proposed changes. We encourage the discussion of alternatives, which sometimes results in additional changes that improve the quality of the code being delivered. We also reject pull requests without unit tests to ensure test coverage remains high and future pull requests don’t break the change. – Ethan Anderson, MyTime

7. Keep A Lookout For ‘Dirty Code’

Developers should never comment on the code. Instead—and only if necessary—add comments to describe the business logic or the requirement/functionality that the code blocks are intended to meet or perform against. Good code should be self-explanatory, easily readable, and understandable. “Dirty code” often has code comments, which can be a clear expression of poor coding. – William Diggin, Accenture

8. Provide Rapid Review And Feedback

The key best practice is providing speedy review and feedback. The longer a code review takes, the more likely the developer has moved on, and it will require a lot of mental effort for them to switch back to incorporate feedback. Reviewers need to prioritize code review above other activities rather than seeing it as a secondary part of their job. – Peter Zaitsev, Percona

9. Set Up A Team Of Review Specialists

Although all our developers are responsible for reviewing and bug-testing their own code, we believe in having a team of “code busters,” as we call them—people who review the code and ensure that the minimum viable product is up and running. Only when this process is completed is the MVP handed off to our enterprise scale-up teams for scaling up and enterprise-wide deployment. – Ian Chapman-Banks, SQREEM Technologies

10. Automate The Review Process

If development teams do not have an automated process for reviewing code, they are not efficiently or effectively identifying defects that can impact the quality, security, and functional safety of the software they are building. Additionally, by automating the review process, you encourage development teams to practice collaboration and the sharing of best practices throughout the software development life cycle. – Vince Arneja, GrammaTech

11. Ensure Reviewers Have The Needed Context

Reviewers need enough context to understand if every edge case is covered. This makes a solid case for writing good descriptions of what the pull request is trying to solve and why. A thorough explanation will decrease the number of iterations and comments, increasing the team’s velocity. It will also help everyone on the team understand how the new code will affect the current version. – Alex Kalinovsky, AgileEngine LLC

12. Leverage Error Detection Software

Load the code into color-coded error detection software once it’s complete. Having a quick way to find repairable surface issues is much more efficient than manually checking for them. Then, go back through and check manually to make sure the automation didn’t miss something. We also like to run code by other team members for user testing to make sure everything works as it should. – Yenn Lei, Calendar

13. Review In Shorter Bursts

Be specific about your time. Reviewing code can be cumbersome, but it is necessary. To move through reviews efficiently, our teams use time-blocking to structure the review process. By evaluating the code in short intervals—for no more than 60 minutes, and ideally around 25 minutes—our teams are more accurate. Bursts of intense focus lead to fewer mistakes and drive our teams to be more productive. – Venkat Viswanathan, LatentView Analytics

14. Review Code In Pairs

Partner a seasoned professional with a less experienced one. Treating the review session as a learning moment develops leadership skills in the experienced professional and development skills in the novice. Ensure both parties enter the review environment with personal safety—it is not a place to punish. The only mistakes are those where the end goal is not learning. – Cleve Gibbon, Wunderman Thompson

15. Maintain A Spirit Of Empathy And Teamwork

We encourage teams to keep code reviews empathetic. It is important to maintain a positive and collaborative culture within development teams. Therefore, we use code reviews not only as a technical process but also as an opportunity to learn and communicate with peers. Developers acknowledge the hard work of their teammates, talk through their comments, and appreciate follow-up discussions. – Borya Shakhnovich, airSlate

16. Engage Engineers And Stakeholders

Code review is a critical step for any engineering team, as it allows for coaching and quality assurance and ensures that the code is light and performant. We rely on two key things. First, no piece of code is considered “done” until it has been peer-reviewed by a senior engineer. That’s a step in the process that can’t be skipped. Second, we do “walk-throughs” that involve PMs and testers who review and confirm that the feature works as intended. – Antonluigi Gozzi, LiveHire Ltd

 

Source: Forbes