Seamless Collaboration: Our Team’s Approach to Code Reviews and PRs

Introduction

Code reviews and pull requests (PRs) are not just essential steps in our software development process; they’re also moments of collaboration and cheer ! 🎉

At our team, we’ve embraced the spirit of “Seamless Collaboration”, a harmonious approach that infuses joy and enthusiasm into our code reviews and PR workflows. We believe in the power of efficient collaboration, where feedback is constructive, ideas flourish, and learning is continuous.

With each pull request, we start a journey of improvement, knowing that together, we’ll build something remarkable. In this article, I invite you to experience the joy and efficiency we find in our development process, as we unveil the secrets behind our ticket planning, code reviews and PRs. Get ready to dance with delight in the world of coding as we share our strategies to make every review an enjoyable and rewarding experience!

How to ensure a streamlined Code review process

To enhance clarity, I’ll divide the process into four parts that will build up a square that should happen on each PR(pull request), CR(code review) process and provide a brief description for each segment.

1. Beforehand Established Context (Feature Level)

Establishing context beforehand is one of the most important steps to achieving smooth and effective deliveries, it is done by:

• Utilising technical design.
• Initiating features kickoffs.
• Breaking down complex tasks into smaller decomposed tickets.
• Presenting a clear and comprehensive description of the ticket, including its objectives and intended outcomes.

2. Engage team conversations outside actual reviews
Avoid deferring all discussions until the review stage.
Instead, engage in ongoing dialogues with your team during meetings.
In our team, we convene a weekly ‘Engineering Talk’ session, focusing on matters related to our service approaches and methodologies, including hands-on discussions about code implementation.

3. Don’t Leave Code Review to Chance !

Set a dedicated time on your calendar for code review, Everyone has their own duties to do, meeting to attend and goals to meet, no company will have a fully dedicated person to do code reviews, but partially it can happen, each developer can dedicate a small window on his/her calendar to do code reviews, and after a while it will become a habit, no one will be blocked, no one will be blamed and deliveries will continue. 😀

4. Make sure to guarantee “Pull Requests” best practices

• Start with a Branch Name that Clearly Describes the task’s outcome.
  COMP-1234-bugfix/login–password-validation` and not `bugfix/login`
• Keep commits atomic: If you are adding a commit to a new definition of something to the Models package, why to commit changes in the Tests package.
• Amend existing commits instead of creating new ones when addressing PR comments, this prevents unfinished changes from confusing reviewers in previous commits.
  Currently, we find the time investment in this approach justified by the gains in maintainability, reduced bugs, and streamlined reviews for reviewers.
• Reach production Gradually with Focused PRs, try to encapsulate each functional change within a focused PR, you will find that this will reduce the risks, improve clarity, reduce the costs of a potential roll-back and finally the thing that we are focusing on in this article: it will enhance the Code Review process, With that being said, keep in mind that such focused PRs requires an upfront planning.
• The goal is to be able to read the commits as a story going from the start to the end.

Let’s assume that we are building a Car, using git commits.
Me as a reviewer should be able to understand what will happen, before even reading the code itself.

CAR-1001 | Create car shape design
CAR-1001 | Put in the engine and parts
CAR-1001 | Attach wheels and brakes
CAR-1001 | Add controls and wires
CAR-1001 | Cover car with panels
CAR-1001 | Make inside comfortable
CAR-1001 | Test for safety and quality
CAR-1001 | Finalise car assembly

Make sure to have an atomic commit, so you should not commit engine assembly inside an outer car body creation, and electricity wiring inside the car painting phase.

Code Review time

1. Frame your feedback as questions, and provide suggestions:
   This technique encourages thoughtful engagement and promotes a deeper understanding of the code. For example:

Instead of: ‘You should use a different algorithm here.’
Comment as a question: ‘Have you considered using a different algorithm in this scenario? Maybe using binary search instead of brute force will be better here ? WDYT ?‘

Instead of: ‘The variable naming could be improved.’
Comment as a question: ‘Could we enhance variable naming for clarity in this section of the code? So instead of getUsers maybe getUserByName would be more descriptive ?’

This method encourages constructive dialogue and invites the code author to consider alternative approaches, leading to more meaningful discussions and code improvements.

2. Accept other coding flavours and styles:
Many times developers have different coding flavours and styles, try to understand that, for example let’s see in how many ways we can achieve a condition statement:

Verbose Style:

if condition { 
       // Code block 
}

Single-Line Style:

if condition { // Code block }

Conditional Assignment Style:


if result := performOperation(); result > 0 {
    // Code block
}

Switch-Case Style (when multiple conditions need to be checked):
switch x {
case 1:
    // Code block for case 1
case 2:
    // Code block for case 2
default:
    // Code block for other cases
}

3. When a code review discussion becomes lengthy and complex, consider picking up the phone to facilitate effective communication and resolution. Just as things can quickly become viral online, a direct conversation can help address issues efficiently and ensure clear understanding among team members, make sure to write down the call conclusions in the discussion thread.

Conclusion

Let’s sum up the main points in this blog: Prior context is a key to guarantee a smooth development and code review process. It reduces misunderstandings and increases collaboration, fostering a cohesive team dynamic. Additionally, dividing your feature commits into logical units and providing a clear, comprehensive description of each is a fundamental practice that enhances code review efficiency.

It’s worth noting that, to fully gain the best out of this article, it’s important to give careful attention to have a strong design foundation.

By following these principles, teams can navigate the development journey with clarity and deliver high-quality code more effectively. Moreover, maintaining an open dialogue and embracing diverse coding styles further contributes to a productive and harmonious development environment.