Best Practices for Pull Requests
Written by: Tripti Kumar, Agile Software Engineer, TribalScale
📫 Subscribe to receive our content here.
💬 Have any questions about our development capabilities? Click here to chat with one of our experts!
Treat the project code as a Bible 📖!
During my initial software development days, my only focus was to develop bug free code. Sometimes this would lead me to send big chunks of code as a pull request. Indirectly, it contributed to either getting the PR rejected or getting lesser feedback and hence, lesser chances of improvement.
Recently I was asked to do a PR which contained thousands of lines of code. Being a senior developer, this put me in a big dilemma since I could see the hard work being put in. But at the same time, I felt this Herculean task would not benefit either me or the developer who sent the PR.
Let’s look at some of the best practices to turn this complex process into a cakewalk…
1. Don’t expect code utopia
In a perfect world, your code would always work fine. Review your code and test it thoroughly before sending a pull request. It would ensure that your PR gets accepted quickly.
2. Atomize the development tasks
A useful rule of thumb would be to divide the development tasks into smaller parts. Smaller tasks would have lesser code lines. The reviewer would definitely thank you for doing this!
You can get a quicker approval and also better feedback. It’s a win-win situation for both you and the reviewer. This leads us to our next best practice.
3. Send a PR for every task
Don’t wait for the work to pile up before sending a big PR. Take an oath of allegiance to send a PR after every task is complete. Trust me you are making the QA’s job much easier, since they’ll get to do consistent testing. Also, the client would be singing hymns of praise.
4. Implement best coding practices
This is the first thing we learn as a software developer. So what is there left to learn? You would be surprised how often we could be doing a better job. If you see the below code snippet, it seems like nothing is wrong with it.
But there is a better way to implement the same piece of code, saving both your time and the reviewer’s. In the above code snippet, instead of using a struct we can extend the String class directly.
You can thank me later for this 😎.
Follow TDD (Test-Driven Development) for catching those nasty bugs and errors earlier.
Implement Continuous Integration by enabling it on Git using a CI tool like Github Actions or Bitrise. This allows for automated testing whenever a PR is open. It makes it much easier to detect errors and makes the debugging easier.
Github also provides support for code coverage tools. This is helpful in knowing how much running code is checked by the test suite.
Provide your team with a well-written PR template. This would ensure that whatever kind of changes being performed (e.g. feature, bug fix, refactor, hotfix) are being specified.
5. Throw your ego in the closest garbage bin🗑
As a developer, sometimes it gets hard to accept feedback on our work. We feel like we always know what’s best. Try to keep an open mind while reading the reviews. If you feel that an explanation can be provided, try to be as precise as you can stating the facts and examples or URL links. Now keep in mind, this might still result in getting the PR rejected. So accept the feedback with a positive mindset, implement it and move on!
6. Take the feedback to heart
This is the fastest way to grow as a developer. Learn from yesterday and live for today! If it’s difficult, make a list and chant it everyday before starting your work..🧘🏽♂️
7. Be strict about the temporary code
Any print statements, commented out code, hotfix or temporary refactoring to make a component work shouldn’t be included as a part of PR. Short-term solutions can quickly grow into bigger future problems.
8. Envision the bigger picture
This is the crux of my past 11 years of experience. You are not just writing a piece of code, but a small integration to a bigger project. Always ask yourself the following questions before using your keyboard:
- How will the code benefit the project in terms of maintenance?
- Will the code be valid six months from now?
- Is it a scalable solution?
Always remember a pull request is not a SOLO task. It’s just one piece out of an extensive and complicated system. Follow the principle of not harming the code and let it guide you towards deciding if the modification is an “approval” or a “rejection”.
Tripti is a curious techie and a philomath, working at TribalScale as an Agile Software Engineer. A big fan of “How I can” rather than an “If I can” mindset. She spends her time caring for plants and pets, doing yoga and meditation, and volunteering for Isha Foundation.
TribalScale is a global innovation firm that helps enterprises adapt and thrive in the digital era. We transform teams and processes, build best-in-class digital products, and create disruptive startups. Learn more about us on our website. Connect with us on Twitter, LinkedIn & Facebook!
