There will be times in which you will be working on huge features (if you haven’t already 😎), some of which could take weeks and some even months. During your implementation, you will have to find a way to create better pull requests and try to write kickass code, all while figuring out how to make the review process better. After all, better reviews mean fewer bugs, right?
In our previous post, we discussed some ideas for improving pull requests after a pull request has been created. However, sometimes, improving a pull request may require actions to be taken before our initial commit.
So how can one create a better pull request before even committing their changes? The answer lies in carefully planning the steps of implementation before starting the actual implementation process. Whaaat? 🫨
Let’s decide on an example or a use case so that we can discuss our theory on common ground.
A full-stack feature use case
(This is a use case with simplified specs, used only as an example for this post, to ensure that we are both on the same page when discussing the topic at hand)
To illustrate, let’s suppose we were asked to implement a new full-stack feature. In our example, we’ll assume that we want to add a new comments section to our blog.
After having a design session with our team, the following specs were requested:
Use case – Feature specs
specs, short for specifications, are used to outline the requirements a new feature implementation must meet to pass QA testing and be deployed.
- In the existing post section, a new comments section will be added where readers can view and add comments related to the post.
- Both the writer and the admin will be able to add, edit, and delete any type of comment.
- A reader will also have the ability to add/edit/delete their own comments.
- Show statistics for each post’s comments.
Prerequisite changes
It’s considered good practice to always take a step back and carefully consider the steps you should follow to implement a feature before diving headfirst. As the saying goes:
Measure twice
Cut once!
But how does this relate to creating better pull requests?
Well, in my opinion, when thinking about a feature’s implementation, the potential outcomes typically fall into the following categories:
- Ways to achieve the desired outcome
- Challenging code areas that may need refactoring beforehand
- Necessary changes that are not directly related to the feature
(This list is not that comprehensive! 😋)
Both the last two items on the list are related to prerequisite changes that need to be made before the feature is successfully implemented. Some examples of these changes could be:
- Introducing a new package dependency that needs to be used by your feature
- Introducing some reusable components
- Performing some code cleanup before introducing new code
By identifying similar changes early on, you can significantly streamline your feature’s review process. Rather than creating one massive pull request that could make your colleague’s lives challenging, you could create initial pull requests with independent changes, merge them, and continue with your feature implementation. In the follow
Identifying our use case prerequisite changes
While thinking about the feature’s implementation, I realized that it would be beneficial to introduce some distinct roles for our users, such as readers, writers, and admins. Additionally, since we have decided that we need statistics, I did some research and came across a fantastic statistics package to use, for displaying how many comments a writer has over time.
Although both changes are connected to our feature implementation, its worth considering the extent of their interdependence. Could we introduce these two changes and deploy them without completing our feature? The answer is yes! But how?
These two changes, along with any necessary tests, could be included in different branches from which we would create pull requests and get them deployed.
One branch will contain the introduction of user roles and the other one will contain the installation and configuration of the statistics package.
These two branches can be referred to as prerequisite branches.
Both pull requests will likely (depending on the codebase and implementation) not affect our existing codebase and can be reviewed and merged independently. As a result, we can continue working on our feature, without having our work blocked, at least not initially.
Don’t get me wrong, eventually, we will need our prerequisite changes. However, until we reach that point, we will have found a way to continue our work and also start deploying pieces of code that do not impact our users or hinder our work.
Splitting commits
Now that we have reviewed and deployed our prerequisites we need to focus on the actual feature. If you also like to work on full-stack features you might find yourself following three paths while implementing a new change:
- Starting from the backend.
- Starting from the frontend.
- Diving in both.
Defining the best approach depends on your developer profile and the work needed. Each approach has many advantages but I’ve seen that shifting between approaches from time to time has the ability to transform and improve your mindset as a developer. So choose wisely and have fun!
Meanwhile, if you decide to adopt the one-side-at-a-time approach then why not improve your pull request using the same method? How? By splitting your commits as you progress with your implementation.
Splitting commits, for example by backend and frontend ones, may also help if you are working with a team that doesn’t have full-stack engineers but separate teams of front and back-oriented developers.
Splitting your work into smaller commits, may also enhance your review process and lead to better pull requests. This is because individual commits also help reviewers, concentrate on specific commit changes rather than the entire scope of your pull request.
Applying split commits to our example
To see that in action let’s assume in our example that we will be following the implementation steps below:
Backend implementation
- Implement the comments CRUD logic.
- Introduce role handlers needed for checking who can see what.
- Add any unit/integration tests.
Frontend implementation
- Create our new UI views and any additional components.
- Add the necessary routes.
- Add any unit/integration tests.
By creating two separate pull requests or one pull request with different commits, each containing the respective changes (backend & frontend), we can greatly improve the efficiency and effectiveness of the review process.
I get it. Sometimes, this may seem like overkill, but trust me, breaking work into smaller pieces, will unlock new paths in your thinking process which will boost your problem-solving skills in multiple ways.
In general, developers often neglect managing pull requests as we tend to believe that our work ends when pushing that final commit. I can assure you, though, that giving more emphasis on the other aspects of your workflow, as we’ve talked about in this post, can have a significant impact on your work.
