Code reviews are important to deliver quality and well-crafted software. But what if the PR lingers in the review queue waiting for reviewers for an extended period? We faced a similar issue in one of our team where few stories were delayed due to pending reviews from the members. In this article, I would like to share about how we improved the Code and Functional Review process resulting in high quality and happiness.

*This process was identified and implemented for one of the projects and every project could have minor customization based on the nature and requirement of the project.

What is Code Review?

Code review is an essential part of the software development process, where peers scan the code for the potential bug, performance bottlenecks, logical issues, etc. and provide suggestions to improve the code quality for scalability and maintenance. (Here, we will not discuss code quality feedback about style guide as that can be easily automated using linters for example. Rubocop in Ruby on Rails applications.) This helps in delivering a reliable, predictable, and maintainable software product. Besides, it helps programmers build relationships and work together more effectively.

What is Functional Review?

A functional review ensures that the code developed by the software craftsmen is as per the requirement. It also checks if the code changes satisfy the acceptance criteria and no security concerns are raised in the existing application.

Benefits of Code and Functional Review

  • Improves business knowledge of the team members.
  • Detect bugs and defects at an early stage before they become a part of the product.
  • Reduces the number of bugs reported by the QA and the cost of testing.
  • Ensures that the code follows standards defined by the organization's coding guidelines.
  • Helps to keep consistency in coding style (of course, this can be an automated process in GitHub PR review process using various add-ons and tools).
  • Improves the maintainability of the code base.
  • Acts as a knowledge-sharing platform by fostering enhanced communication.

Existing Code and Functional Review process

When the implementation of a feature is completed, we raise PR and assign reviewers to the PR. We then deploy (auto or manual depending on applications) the branch to a dedicated application server, here the peers can check the code functionally. As our team is large, it would take time for each team member to review based on their availability. So once, we get 2 to 3 max approvals we move the PR to the next stage.

Here is the Code Review checklist we follow.

Challenges with existing Code and Functional Review process

  • The number of PRs to review - Due to the large team size, every day quite a few PRs would be raised and developers had to find time for reviewing those over their scheduled tasks.
  • Cycle Time taken to review the PR - Each time a PR passes back and forth, developers are required to switch context and focus back on each change request.

We wanted to seek the team's viewpoint on the benefits and challenges, hence we conducted the following survey:
(the following images shows the survey questions and the responses from the various team members)

The survey questions were asked to the team to introspect and ponder upon the benefits and challenges. Based on our survey results, it's evident that the team is very well-aware of the importance of "Code and Functional Reviews". But most of the reviews get delayed due to factors namely - length of PRs, lots of file changes, lack of business knowledge, and difficulty in prioritizing the PR for review. This survey helped us to streamline the process and introduce creative mechanisms, which was a win-win situation for all stakeholders.

“Awareness is the power that is concealed within the present moment. The ultimate purpose of human existence, which is to say, your purpose, is to bring that power into this world.” ― Eckhart Tolle

Inclusions to the Existing Review process

  • Pairing Reviewers
    So, we decided to do the PR review in pairs. We paired up the team members and requested them to do the initial Code and Functional Review of their partner’s PR on priority. The PR would be released for team review once their partner approves it. This way each member can focus more on the PRs raised by their partner and none of the PR goes un-reviewed.

    Besides this, we came up with SLA for the review cycle. The maximum time limit was set to 24 hours from the time the PR is available for review. Due to this, the Pairing Reviewer gets sufficient time to plan their day and make room for functional review. This inclusion helped us to overcome the challenge of a list of a huge number of open PRs.

  • Demo of completed features
    Once the PR is ready for review, the respective developer gives a quick demo after daily stand up. This helped -

    • The entire team to understand the new feature.
    • Improve business knowledge.
    • The pairing reviewer to be better equipped to conduct a functional review of the PR.

  • Test First Approach
    We follow TDD for all the stories wherever applicable. Coverage of all scenarios in the unit test help reviewers to get the detailed context of the story.

Improvement after incorporating changes

  • Enhanced team collaboration and requirement analysis due to pairing among team-members.
  • Improvement in business knowledge of all team members due to the demo of completed features.
  • Improved specs coverage as the TDD approach is followed.
  • Reduced the number of bugs reported by QA, 80%+ stories were delivered to QA without bugs.
  • Flawless & timely delivery of stories, as most of the scenarios, were covered during the development and review cycle.
  • The above improvements garnered positive feedback from the client.

“What good is an idea if it remains an idea? Try. Experiment. Iterate. Fail. Try again. Change the world.” – Simon Sinek

Thank you for reading.

References