At Woovi we have a culture that every dev should review all pull requests, due to that it's crucial that we follow good practices to make the reviewing process easier, and also give context on what we're working on.
A good pull request have a few characteristics to it, you can have more rules depending on the culture you're trying to nurture, but you should always try to follow these points:
Small / Atomic
One pull request should be responsible for a singular change when possible, this not only makes it easier to review, but it lowers the chances of introducing bugs to the code base.
Linked Issue
Ideally every pull request should have an issue linked on it. This makes it easier to track what's being done on the issue, improve the documentation of changes, and also makes reviewing it easier.
Tests
Regardless of how small a change is, almost all pull requests should have a test attached to it. Having tests for even small changes and bug fixes is important so we don't introduce the same bug on the codebase again. It's important that the tests are in the same pull request as the changes, not only it makes it easier to review the changes, it also makes it easier to review the tests.
Prints
If your pull request makes a visual change, it's important to always attach a print to it. It makes sure that everyone can easily see the change you made.
What Should You Do Before Making a Pull Request?
Before making a new pull request, you should make sure that the code you wrote is ready for merge, here's a few steps you can do:
- Run the tests you wrote, or any associated with the pieces you're changing.
- If your tests generated any snapshots, make sure to guarantee the snapshots are correct.
- Run any commands that will generate code, like for example i18n and make sure to do the needed changes after running them.
- Update any snapshots needed.
What Should You do After Making a Pull Request?
Your work doesn't end when you finish publishing your changes, after actually making the pull request you should also try to follow these steps:
- Review your own code
- Respond to comments and feedback the team gives you
Any feedback given in the pull request should be considered, when someone gives feedback on a pull request it means that they thought and properly reviewed your code, if you disagree with a point, make sure to respond with your own arguments. Feedback is not an attack on your work, so make sure to always respond to any feedback given. If you're thinking you're not getting constructive feedback, make sure to let it clear to team how you'd like feedback to be given.
Examples
Bad Pull Request:
Good Pull Request:
If you want to work in a startup in its early stages, This is your chance. Apply today!
Woovi is a Startup that enables shoppers to pay as they please. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.
If you want to work with us, we are hiring!
Photo by Cole Keister on Unsplash
Top comments (0)