Code review can be likened to eating broccoli.
Many code reviews are superficial and less efficient than they should be.
Are there any ways we can encourage code reviews that are more thorough and lead to better code? I think so.
This article will provide tips for both the code reviewer as well as the code reviewee. These will help you to get more value from code reviews and make it a bit less unpleasant.
These suggestions, except the first, assume that your code has been reviewed in a pull-request workflow like GitHub flow and trunk-based programming with PRs. Other methods of code review exist, but they are less common so I am not addressing them.
Let’s get the obvious answer out the way.
Pair programming involves two developers working simultaneously on one piece of code. This can be done by sitting at the same keyboard, or perhaps via screen sharing.
The driver is the person who controls the keyboard. They may switch roles with the navigator or observer at regular intervals or on an as-needed basis.
All code can be viewed in real-time by two developers. As the advocates point out, the unique roles of driver, navigator, engage different parts in the brain which allows the pair to be more productive than one developer working alone.
This allows code to be reviewed in detail as soon as it’s written.
Although many teams believe this eliminates the need to have an asynchronous code review later, opinions may differ.
Pair programming may not be possible for all teams or at all times. You should not pair up with someone who works in a different time zone, has different schedules, or is otherwise prohibited by company policies. If you aren’t comfortable with pairing or believe it would be beneficial to do another review, please continue reading.
Also read: Top 7 Best ECommerce Tools for Online Business
Although it may seem counterintuitive, the best way to get code review done is to make your PRs smaller.
It is a well-known fact that humans prefer small, easily digestible bits of data. Splitting large data sets into smaller pieces allows us to consume more data, even if the total amount is not the same. Newspaper columns are short because articles are divided up with illustrations and subheadings.
It follows that, logically and empirically, a series of 10 100-line PRs will receive better reviews than a single 1000 line PR, even though they contain identical changes.
Your PRs should be small and easy to read. If you are a reviewer and see a large PR, ask him to split it into smaller PRs.
This is related to small pull requests. You don’t want to be tempted by the temptation to write a 1,000-line patch and then divide it into 10 PRs for review. Instead, think about the benefits of working in smaller batches.
Perhaps the most surprising reason to use smaller PRs is:
We tend to review more code when it takes several hours or days for code to be reviewed. This results in larger pull requests. Reviewers are more likely to delay reviewing larger pull requests because they take longer to review. It can take hours or even days for code to be reviewed.
We must take on every step of the process to break this negative feedback loop. As we have already mentioned, smaller, more frequent pull requests are only one part of the solution. Frequent code review is another key component.
This simple rule will break any team from this bad habit: Review code before you write code.
Before you start your day, check to see if any code is still available in your IDE before you go.
Before you start your next task, check if there is any code that needs to be reviewed before you create a PR.
Tribbles attack code reviews, such as Tribbles, can multiply and spread quickly if they’re not exterminated immediately.
This and the other suggestions will quickly show that your entire team operates at a rapid pace of write-review merge, which takes no more than an hour. To speed up the process, peer programming might be a good next step.
Stop looking at coding style. Seriously. It’s time to stop. It is a huge waste of time and energy. It’s also fraught with unneeded emotions.
A code formatting tool is useful. It can be added to your pre-merge automation. Any code not conforming to the standard should be removed from the PR. It doesn’t matter which style you choose, it is more important than the fact your style is enforced automatically.
I don’t know if you agree, but I prefer a tool to tell me that tabs should be used instead of spaces than a colleague telling. Although I may get mad at the tool, I can still use it at lunch. This time and energy can be used to review the code’s structure and functionality.
Also read: 50+ Trending Alternatives To Quadpay | A List of Apps Like Quadpay No Credit Check/Bills and Payment
Many languages have a lot of linters. Make use of them. You can use many of them. Linters can improve code quality, security and complexity. They also offload some cognitive load from the code editor.
It is subjective to be able to read code. It’s nevertheless very important.
Write your code with your human audience in mind, as a code author.
If you find yourself wondering “WTF?” while code reviewing, please leave a comment to improve. Even though you can figure it yourself, it is a great way for the author learn how to write more readable codes.
This is why juniors should actively participate in the review of seniors’ codes.
Every pull request, every commit should do only one thing. Have you found a bug in a feature that was added? Make the bug fix public in a separate PR.
Is it necessary to reformat an entire file in order to comply with new formatting rules? This should be a separate PR.
It’s not difficult to try and review a bug fix or a new feature.
Make a commitment early. Make sure to commit often. Commits and PRs are completely free.
Code review doesn’t have to be about. A pull request should also include PR and commit messages. It can be frustrating to try and debug something that was done 9 months ago by someone who is no longer employed by the company.
Also read: Top 10 Web Hosting Companies in 2021 | Detailed Review
Never use code reviews as an excuse for your technical skills. Always be polite. Make suggestions for improvement. Be humble. When your suggestion is an opinion and not a deal-breaker, be honest.
A rude reviewer is not something anyone likes and they will try to get rid of them. To get code authors to be more open and make code reviews enjoyable, it is important to create small, easily-reviewed PRs. This is a way to make them friendly and offer them the opportunity for bi-directional learning.
Thursday January 12, 2023
Friday December 23, 2022
Tuesday December 13, 2022
Thursday December 8, 2022
Friday December 2, 2022
Friday November 11, 2022
Wednesday October 12, 2022
Saturday July 2, 2022
Tuesday May 17, 2022
Tuesday April 26, 2022