Technical review is a part of every software development process. After a developer has finished with a task, it’s standard to have another developer or team lead review the code. This code review can be a long process, depending on the length of the code and the number of changes that were made.
Although technical review is an integral part of the coding process, most developers would prefer to spend their time coding. This was one of the main reasons GitClear was created. By reducing the time it takes to review code, GitClear increases time available for developers to keep coding. This increases both employee productivity and job satisfaction. Here are three programmer tools from GitClear that help reduce time spent in reviewing code.
Grouping commits together
The first thing we looked at when creating GitClear was to upgrade the commit review process. We’ve said it before, and we’ll say it again: no developer is the same. Programming habits vary significantly from person to person — some devs group all changes into one large commit, while others split up their changes into several related commits. It can sometimes take hours of review to understand the true impact the code has had. To solve this problem, we’ve introduced a feature called commit groups. GitClear uses a learning algorithm to identify logical collections of commits and grouping them together. Analyzing code in this way can reduce the lines of code that need review by 75% or more. How, exactly?
By collecting the lines of code that endured throughout a series of related commits. We help you pinpoint how small commits grow into large-scale features. If you have a limited amount of time to spot-check your team’s code, we’ll prioritize the most impactful code changes during your selected date range. Since our code interpretation engine detects these changes and automatically groups them together, you won’t waste precious time reviewing incremental work that was subsequently removed during a later commit.
A better diff viewer
The second feature we wanted to create was an improved version of GitHub’s diff viewer. One of the main problems with GitHub's diff viewer is that it only highlights lines that were added or removed, which can be visually misleading. Other actions might have the same impact or take the same amount of work but aren’t displayed in their diff viewer. GitClear highlights these actions in the diff viewer to give a clear picture of your developers impact. Each action provides a different Line Impact value. We automatically calculate values for each action, but these values can be customized to best fit the needs of your team.
In addition to highlighting these actions in the diff viewer, we have enhanced the diff viewer functionality by using the previously mentioned feature, Commit Groups. Commit groups allow for a single view of changes made during a series of commits. Lines that were added in the first commit, but removed in a later related commit, will not be shown in the commit groups diff viewer since that code did not have an impact on the feature being implemented. The combination of these two features can significantly reduce the code that you need to review.
A timeline of commits
The third feature that will level up your review process is our commit timeline. When reviewing a developer’s commits, it’s helpful to understand their commit patterns and skim any commits made recently. That’s where the commit timeline comes in. At the top of each commit page, there’s a bar with colored squares representing each commit made by that author. The commit timeline shows all commits in the past couple of days, each separated by time passed between commits. While not a strong standalone metric, time between commits can provide insight into whether or not a developer is stuck. Each commit on the timeline deepens in color based on the relative impact.
Tying it all together
Grouping relevant commits together, highlighting changes beyond simple additions and deletions, and looking at commit quantity and quality over time are three ways to improve the efficiency of your technical review process.
No comments have been left on this blog.
Login to leave a comment