The diagram above visualizes a repository with two isolated lines of development, one for a little feature and the other for a big feature. By developing them in branches, it’s not only possible to work on both of them in parallel, but it also keeps the main branch free from questionable code. In this way, we make sure that just after we have fully completed X feature after the code was reviewed,
What is a code review?
Code review is a software quality assurance activity in which one or several people check a program mainly by viewing and reading parts of its source code. At least one of the persons must not be the code’s author. The persons performing the checking, excluding the author, are called “reviewers”. By doing code review, we tend to have a high quality of the code, share knowledge between collaborators, find bugs easier, and recommend the best way of implementing a feature to each other.
What makes a good pull request?
Not all pull requests are well created and easy to review. If you open a pull request that contains many different unrelated changes that are out of the scope defined in the ticket, it is hard to perform a good review.
In order to get the most out of your code review process, try to minimize the line count of changes and focus just on the requirements of the ticket described. You should fulfill all the requirements and try to write clean code, instead of writing pieces of boilerplate repetitive code. Format the code before making pull requests and don’t let unnecessary empty lines.
Good pull requests contain:
- Ticket URL
- Screenshots (optional)
- Video records (optionalThe title should be small and concise and tells the reviewer/reviewers what is implemented in general terms.
The description should tell the user the reason and the context of what is implemented in detail. This can give the reviewer a much better understanding of the problem it solves. You should include documentation or design files that rely on the ticket requirements.
In many practices you can create a description based on the questions below:
- WHY - Which tickets/issues/proposals you are working on?
- WHAT - What have you done?
- HOW - What the reviewers should know?
Ticket URL should be included as part of the pull request, we do so to give the reviewer a chance to take a look at what was required for the changes that he is looking for. In some cases, based on my experience, there are chances that the reviewer does not have access to the ticket URL. In those situations, you should copy/paste the ticket requirements into the pull request description to give the reviewer a better understanding.
Screenshots can be included in the pull requests, they are recommended but not mandatory. By doing so we can give the reviewer a look at what was implemented. We can show before/after screenshots for better understanding.
Video records are recommended but not mandatory. These are very productive in situations where we have implemented a flow of screens and want to share it with the reviewer.
Below are a few reasons why creating small pull requests can be beneficial:
- Reviewed more thoroughly
- Reviewed more quickly
- Easier to merge (frequent merges lead to fewer conflicts)
- Less wasted work if rejected