Code Image Photo by Chris Ried on Unsplash

Significance (The WHY):

Mostly whosoever I have talked to about code reviews have their own perception of HOW code reviews should take place. I have encountered few people who talk about the WHY of code reviews & this is concerning because until you understand the WHY, the HOW doesn’t really matter (this is true not just for code reviews but for every aspect of life).

Let me start by pointing out the results of a study conducted by Stripe. You can read the detailed report here.

‘Bad code’ costs companies $85 billion annually. An average developer spends more than 17 hours a week dealing with maintenance issues, such as debugging and refactoring. In addition, they spend approximately four hours a week on “bad code,” which equates to nearly $85 billion worldwide in opportunity cost lost annually.

No matter how small or big of a company you are a part of, the fact that not doing code reviews consistently has a tremendous financial liability, and it will catch up with you sooner or later.

If that was not enough, here are some other reasons why no company or team should skip code review process:

  1. Code reviews enable time off & help make better estimates: Code reviews can help facilitate the sharing of codebase knowledge across the team. This is not just helpful in case of attrition but also reduces too much dependence on one person & facilitates a healthy discussion between the team when having discussions around feature development/effort estimations.
  2. Risks: Code reviews limit the risk of bugs. Even the most senior people can sometimes get tunnel vision when writing code & knowing that someone has your back is always a good thing.
  3. Code Quality & Mentorship: Consistent code reviews will dramatically improve the code quality because the programmers will always have in mind that someone is going to look at their code. This also ensures that senior people can guide their juniors about code optimization/performance techniques & help them avoid common pitfalls which in turn will hone the code author’s skills.
  4. Requirements Check: Code reviews can also act as a requirement vs delivery check. It ensures that what ends up being delivered is actually what was being expected and not what the code author’s perception was.
  5. Respect & Empathy: Code reviews if done right, will foster a healthy relationship between the peers & set an open & progressive culture amongst the company where everyone will feel more comfortable & confident.

Expectations (The WHAT)

  • Errors/Bugs: Are there any obvious logic errors in the code?
  • Feature Requirements: Are all the cases fully implemented as per the requirement specification doc? Has the code author done premature optimization for cases anticipated in the future?
  • Test Coverage: Have tests been written for the new functionality? Will existing automated/integration tests have to be rewritten to account for these changes in the code?
  • Code Architecture: Separation of Concerns has been followed (Presentation, Business and Data layers)
  • Code Checks:
    • Limited use of global variables
    • Good naming conventions
    • Proper Indentation
    • No Duplication of Code
    • YAGNI (You A’int Gonna Need It): Don’t write code you MIGHT need in the future.
    • Functions should not be very lengthy.
    • Exception Handling
    • Object-Oriented Analysis and Design & Principles like SRS, Liskov substitutability principle, Interface segregation, Dependency Injection, etc
    • Check for common code smells
  • Non Functional Requirements:
    • Maintainability & Readability:
      • High level & low level comments
      • The code should be self-explanatory. Use of appropriate names for variables, functions, and classes.
    • Reusability: DRY (Do not Repeat Yourself) principle
    • Reliability:
      • Exception handling
      • Cleanup (dispose) unused resources.
    • Performance:
      • Correct use of data types
      • Caching
      • Parallel processing, lazy loading, etc
    • Security:
      • Protection against most common vulnerabilities like SQL injections, Cross-Site Scripting, etc
    • Consistency: Does the new code conform to existing style guidelines?
    • Configurability: Keep the configurable values in the database.

A lot of the above checks can also be automated using tools & libraries (Some recommendations for Python). You can also use tools like pyup to check for security vulnerabilities across your code dependencies. Nowadays, you can also get AI-powered code reviews & suggestions by using tools like DeepCode.

Process (The HOW)

  • Respect: Code Reviews are not meant to demean anyone. Code reviews should be more of a discussion, than a dictation.
  • 60 minutes hard deadline: No reviewer should review code for more than 60 minutes at a stretch & check no more than 400-500 lines of code at a time.
  • Selecting Reviewers: Always pick the best person to review your code, for example, if someone has worked on that feature before or has the most knowledge around the requirements or a senior member of the team if the code is around optimization/solving tech debt.
  • Providing Enough Context: It is the responsibility of the code author to ensure that the code review process is as seamless for the reviewer as possible. This includes writing both high & low-level comments in the code and clearly stating the feature requirements for the reviewer beforehand.
  • A note for code reviewers: Whosoever is reviewing the code needs to embrace the fact that they are equally responsible for the code that they’re reviewing. Reviewers also need to keep in mind any timelines/delivery commitments that the code authors might have & honor those.

You can also read about the code review process followed by Google here.