How to divide PRs

Let’s imagine you are implementing a decent sized shopping website project with the following functional requirements (FRs):

  • Users need to sign up or sign in to the website
  • On signing in, they must see a list of shopping categories
  • On choosing a category, the user must see a relevant list of options 
  • The users should easily be able to add items to the cart
  • On adding items to the cart, checkout must be easy
  • Users need to logout of the website after purchase

If we were to implement all the FRs mentioned above, it would result in huge lines of code. In addition, it would mean we would need to write and send all the codes at once for review. This would be a time-consuming and challenging task for the reviewers. This could further lead to more errors slipping by, resulting in more bugs.

Additionally, whenever we need to make small changes in the PR, either due to a review comment or a bug we find, we have to test every functionality in that PR to ensure it is not breaking anything. This is another time-consuming task.

Also, in most cases, when we send huge PRs for review, reviewers will not have the patience to go through the thousands of lines of code and say it looks good to me. In other cases, this might lead to P0 bugs if we miss out on some major logic while implementing or misunderstand something. We can avoid all these things if we break the PRs into small chunks.

So how do we make sure that we send chunks of code for review and ensure it would be meaningful and understandable for the reviewers to go through?

This is how I usually go about dividing thousands of lines of code into a small number of about 50 - 100 lines of code that reviewers will understand and be able to review in about 5 - 10 mins.

How to break down frontend PRs?

  • Divide all the FRs into main user actions

From our above FRs, we can extract mainly eight user actions - those are:

  1. Sign up, 
  2. Sign in, 
  3. Home page for showing all the categories, 
  4. Navigation between the categories, 
  5. Separate pages for each of the categories, 
  6. Adding items to cart, 
  7. Check out, 
  8. Log out.
  • Wherever it is possible to divide these main actions into sub-tasks, you can divide them. But make sure once you divide them, they should make sense and be understandable not just for you but also for others who don’t have much context around these features.
  • E.g., we have one of the main actions as a home page for showing all the categories. For this, assume that we have four main categories on this page, i.e., Women’s Fashion, Men’s Fashion, Kid’s Fashion, and Home Decor.
  • We can send one PR just having the code changes for implementing these broad categories. It still makes sense because when the reviewer looks into the PR, they will easily understand this PR is about the main categories we have for our landing page.
  • Now for the next set of PRs, divide these main categories into sub-sections. E.g., under Women’s Fashion, list all possible sections and then send separate PRs for each of these sub-sections.
  • So when you send PRs like this for review, reviewers will have enough context to review the PRs, and not lose context. Further, we can attach a small doc or test cases in the PR to give more context to the reviewers.
  • You can divide a PR up to as small as 50 lines of code. These lines of code can cover some logic or function that explain part of a feature.
  • There are certain actions where dividing them into sub-tasks doesn't make sense. E.g., sign up form, sign in form, log out form, etc. Here, you can simply send these actions to individual PRs, no need to divide them.
  • You can also divide the CSS part of the feature if there are very big changes around the CSS. E.g., certain pages require animations or some gradients in the page. Implementing these can be pretty big in itself. In these cases, you can send a PR for the CSS part alone. You can also attach a screenshot or a video giving context to the PR. If you send just the PR for the visualization in the first iteration, you can add the functionalities to the next PR. This won't make the reviewers confused & also helps developers fasten the review process.
  • Another thing to keep in mind when you are sending PRs for big frontend features is that you don't need to get the pixel-perfect implementations in the first PR itself. Just make sure it is at least 80-90% similar to the designs in the initial PRs so that once you finish all of the PRs, you will have some confidence & that will help you finish up the minor design details in the end. This is my personal opinion; you can use another approach if you don't like this.
  • Since you will be busy implementing, you might not get enough time to add the test cases when sending the initial PR. You can simply add a video, doc, or a small write-up in the PR if you feel the same way. This will help the reviewer have enough context to review the first level basic things & your PRs won't be sent back for additional information.

How to start on frontend PRs if the backend is not ready?

  • Assume your backend changes are not done, even then you can start the FE work without having to wait for the backend to be ready. 
  • You need to identify the things in the FE that will not require backend API changes, e.g., some major CSS changes, HTML templates, etc.
  • You can implement most of the UI using dummy data & once the backend APIs are ready, you just need to connect the APIs & it will be done. 
  • One thing to keep in mind is that if the backend APIs configuration is already written and agreed upon, it will help us further.
  • If the FE & BE tasks are happening in parallel, it is better to sync up & coordinate to prioritize the tasks so that neither team member will be blocked on each other to finish tasks.

Kavya H L

I am a Member of Technical Staff, while not coding I would love to experiment with my cooking and improve on recipes. Love to binge watch F.R.I.E.N.D.S

More of our stories from

The curse of being a Senior Engineer, how to deal with timelines, frustrations, etc

Being a good developer is 50% skill and 50% emotional support; here's my secret to balancing both at the right amount!

How did I build cropping of receipts in the mobile app?

Follow Yash's journey of what it takes to reduce manual work for our customers when receipts come in all shapes and sizes!

How did we increase Data Extraction accuracy by a whopping ~50%?

Wanna know the secret of data extraction, the complex machine learning models we use, the experiments we did? Read on...

The not so secret sauce of my work

From chaos to clarity, follow Chethan's not so secret sauce to excelling at work!

From Zero to Hero: The Policy Tests Journey!

The story of policy tests at Fyle

How Fyle changed my life from a naive intern to a confident Engineering Lead

A blogpost that documents Shwetabh's journey at Fyle.

Vikas Prasad @ Fyle

This document is a user guide to Vikas at work.

Gokul K's README

This document is a user guide to Gokul at work.

How we used AMP Emails to get feedback on AMP Emails!

This blog discusses the how's & why's behind us building a feedback & monitoring system for AMP Emails using AMP Emails


All Topics