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:
Sign up,
Sign in,
Home page for showing all the categories,
Navigation between the categories,
Separate pages for each of the categories,
Adding items to cart,
Check out,
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.