For example, if the task name is ABC-57: Add list with purchases, then a good name for a branch would be ABC-57_purchases_list. If you’re using a task management tool that gives your tasks a prefix or number (e.g., Jira), then you can use that prefix too - especially to set up some hooks, such as to move the ticket to “Code review” when a PR is opened or “To test” when the PR is merged. There are several good approaches you can choose from, depending on how you manage work.
In case your reviewer decides to check the code out locally, they will need to find that branch among many others. The branch name is your first opportunity to give your task context. What’s next?Ĭreate a branch in which you will be working. So you have opened your task manager, selected a ticket, and moved it to “Progress”. Start now Part 1: Before and during coding 1. For the practical example, I will be creating a Flutter application using GitHub as the Git client and Codemagic as the CI/CD tool. This article will consist of two parts: the theory and the practice. In general, all of these tips can be applied to almost any type of development and version control system (VCS). So, keeping empathy in mind, let’s discuss some practical tips that can make your code reviewers happier. Therefore, it’s nice to make the process easier for them, and doing so will probably result in a more efficient code review. But you can go a step further and remember that when you’re assigning reviewers to look through your code, you’re requesting another person’s time and energy. This includes the obvious: politeness, kindness, and respect.
And a good way to approach humans (especially the ones you need to work with) is with empathy. Check out the code locally: This approach consumes the most time and effort, but it’s sometimes the only way to actually understand what’s going on.Ĭode review is a purely human communication process.Review per file: This is easier to do if the pull request isn’t very big.Review per commit: This can only be done if the commit history is available and if it is clear enough.I have encountered different approaches to code review, depending on the pull request, reviewer preference, time available, etc. Documentation: Though more of an implicit consequence than a direct cause, if done right, the history of pull requests can serve as extra documentation for the codebase.It gives them an opportunity get to get their hands dirty with the implementation and learn better practices via code review. This is why retrospectives of developers’ code can greatly contribute to their growth. You can’t supervise the whole process of feature implementation, nor can you plan out all of the details in advance. Programming knowledge sharing: Code reviews are a great way for more senior developers to pass their knowledge and best practices to less experienced developers.It can also help to have someone else look over our work if they have more knowledge of or experience with a specific feature or piece of code. A second pair of eyes can catch things that we missed due to human error. We can get tired, and our eyes can get blurry, especially when we work on something for a long time. Second pair of eyes: We humans are the ones responsible for writing code (for now).Their review can give insights into the code’s maintainability and how it can be improved.
Code maintainability: Code reviewers are the people closest to those who will maintain the codebase in the future, i.e., without memory of a given feature’s implementation.Codebase knowledge sharing: In case mob programming isn’t your preferred approach, code reviews can help to keep your knowledge of the codebase up to date.While the goal of this article is not to compare these approaches, I still want to highlight some benefits of the code review process.
( Wikipedia: Mob programming is a software development approach in which the whole team works on the same thing, at the same time, in the same space, and on the same computer). There are debates going around about the need for pull requests and code reviews, with some developers suggesting pair programming and mob programming as alternatives.
In this article, I would like to share some tips and ideas on how to make the code review process as simple and painless as it can be - both for those reviewing and those preparing the code for review. But as helpful as it is, code review can still be quite stressful and time consuming. Having fellow developers check your code (and checking theirs in turn) helps eliminate mistakes, clean the codebase, and share knowledge across the team. Code review is a widely adopted approach in the world of software development.