A code review is feedback on programming code, that is generally provided by team members. Code reviews are important as they help in improving code before an application is sent into production. It is hard to get the code review process running smoothly and to ensure that it does not slow down the development process. Thus, when opting for code review services it is important to optimize for the speed at which developers can produce a product opposing to optimize for the speed at which an individual developer can write code. Although the speed of the individual developers is important, it cannot be more important than the velocity of the entire team.
Following are a few things that happen when the code reviews are slow:
The velocity of the team is decreased – Well, we know that individuals who do not respond quickly to the reviews, get other work done in time. However, new features and bug fixes for the rest of the team members can be delayed by days, weeks, or months.
Developers feel frustrated with the code review process – if a code reviewer only responds after a few days, but requests major changes to the Change List (CL), then it can be a frustrating experience for the developers. This is also expressed as complaints about ho strict the reviewer is being. However, if the reviewer requests some substantial changes but responds quickly every time the developer makes an update, the issue disappears.
Code quality can be affected – When reviews are slow, there is alot of pressure on the developers to submit CLs that are not as good as they should have been. The slow review also have an impact on code cleanups, refactorings, etc.
How fast should code reviews be?
Code review services should be effective and efficient so that issues and bugs can be resolved before code is sent into production. In case reviewers are not in the middle of a focused task, they should do a code review as soon as it comes in. typically, it should only take one business day for a code reviewer to respond to a code review request.
Speed vs. Interruption
It is important for team members to pay attention to one task at a time. If they are in the middle of a focused task, for instance, writing code, they should not interrupt to perform a code review. Research shows that it can take longer for a developer to get back into a smooth flow of development once interrupted. So interrupting when coding is more expensive for a team that making another developer wait a bit for a code review. It is recommended to wait for a break-point in the work before responding to a request for review. This could be done after the current coding task is completed.
Fast Responses
When talking about the speed of code reviews, it is the response time that matters the most. This speed is more important than the time it takes a CL to get through the whole review and be submitted. Ideally, the entire process should be fast but it is equally important for the individual responses to be faster than it is for the whole process to complete.
In certain cases, even if it takes a long time to get through the entire review process, quick responses from the reviewer can also help through the review process easily. In case the reviewer is too busy to perform a full review on a CL when it comes in, they can still send a quick response that lets the developer know when it needs to be resolved.
Cross Time-Zone Reviews
Remote teams work in different time zones. So when team members are facing time zone differences, it is most likely to get back to the author when they are still at their office. If they have already left the office, they make sure that their reviews are performed before they get back to the office the next working day.
Code Reviews Improvement
If code reviewers follow the above-mentioned guidelines and remain strict with them, they should find that the entire review process tends to go faster over time. Developers learn what is important for healthy code, and send CLs that are good from the start, and so they require less review time. Reviewers learn to respond quickly and do not add any unnecessary latency into the process. They do not compromise on the code review standards or quality that they have imagined to improve the code reviews over the passage of time.