Reactive Programming - Part 2

In our second Sharpen the axe session, our team discussed the importance of a PR review process and came up with a guideline that we are now strictly following at Techwondoe.

Why do we care about Pull Requests so much? 🤔

Though at times the whole process of pull requests can be very tedious, it must be an integral part of the development lifecycle of all software development teams across the globe as it provides the following key benefits -

• Improves the quality of the project and the codebase.
• Domain knowledge sharing within the team is a byproduct of this process.
• Acts as a mentoring tool for junior developers.
• Just like a good commit history, a good PR history is also important to get a clear timeline of the changes that have happened in the code base over time.

This is only beneficial when done the right way, and everyone involved in this process understands its importance. Hence we broke this down into two parts -

1. How to author a PR?
2. How to review a PR?

In this session, we discussed point 1 in detail, and here is the outcome -

• Meaningful title and description: To help understand the story better the first thing the reviewer would look at, would be the description on the PR and having a meaningful description really helps to set the tone and provides decent context for the reviewer to review the PR properly.
• Link to a ticket: Each PR must be linked to a ticket for which that piece of work is being carried out.
• Make it visual: If a PR is authored for some UI changes then it must have screenshots or videos of the changes attached to help them understand what changes were exactly done.
• Appropriate status: To respect everyone’s time and energy, a PR should have an appropriate status on it. Usually, PRs should be raised only after the final changes but if there is a requirement to raise it early to get some suggestions or some early feedback, then it should be marked as a Draft.
• Keep them small: PRs should be small and limited to a story, task, or bug. It not only makes the reviews more convenient, but also makes the process to revert a merge commit cleaner and more straightforward.
• Meet the ACs: The work done as part of a PR must meet all the acceptance criteria defined on the associated ticket.
• Squash commits: To keep your git commit history clean, it is always considered good practice to squash the commits whenever possible. Most modern version control systems provide this offering out of the box.

We are not done yet on this topic. We still need to get together and discuss the responsibilities of the reviewers in this process, as it is an equally important conversation. Don’t worry, once we have that session, we will update you with the outcome until then please enjoy some memes from the internet on this topic.

Key Takeaways

The essentials, distilled.