Seven Advantages of In-IDE Code Reviews
When compared with code reviews using a Pull Request or a Merge Request as the primary driver of collaboration, In-IDE code reviews offer important advantages that result in higher author and reviewer satisfaction.
Code Reviews are an important tool for ensuring code quality, sharing knowledge among developers, and explaining how decisions are made. According to surveys conducted by CodeStream in 2020, over 75% of developers who perform code reviews do so using GitHub, GitLab or Bitbucket. Smartbear produces Collaborator, a code review tool. They also conduct surveys to better understand their customers. Smartbear’s State of Code Reviews survey indicates that only 45% of developers are satisfied with their code review process. That leaves a lot of room for improvement.
When compared with code reviews using a Pull Request or a Merge Request as the primary driver of collaboration, In-IDE code reviews offer important advantages that result in higher author and reviewer satisfaction. There is a strong correlation between code review satisfaction and code quality satisfaction, so getting the process to be easy, compelling and truly useful is a great way to improve quality.
At CodeStream, we have developed an in-IDE code review solution that simplifies the process for both the author and the reviewer(s), eliminates many of the drawbacks of performing a code review in a web browser, and saves time. Let’s look at the seven ways in which CodeStream code reviews accomplish this.
1. No context switching
Unlike web-based solutions, requesting and performing a code review with CodeStream keeps you in your natural coding environment: your IDE. No need to go back and forth between your browser, your notification tool (email, Slack, Teams), your terminal, and your editor. Everything you need to review code is right there in VS Code, IntelliJ or PyCharm (CodeStream supports 12 different IDEs at this time). Just two clicks are required to request a code review. The reviewer is notified via CodeStream’s in-IDE activity feed and notifications, and optionally via Slack, MS Teams or email. The reviewer performs the review entirely in-editor and can reference and comment on any code, not just the code that’s subject to review.
2. Two-click Request-A-Review Process
By just clicking on the Request button, CodeStream packages up all the changes in the current state of your repo and presents them to you for inspection.
Notice that unlike a pull request approach, you can request a review on Work In Progress or local commits in addition to pushed commits. Select the type of changes you would like to submit, the notification vehicle (Slack, MS Teams or email) and then click Submit. You are all set.
3. Request Feedback Earlier
Most of us are used to requesting feedback on pushed commits. In many cases, we could have used some input earlier in the process (shifting left), as we were stubbing out a class or sketching out a solution, in order to avoid costly rework or technical debt. Unlike traditional approaches to code reviews, which have significant friction, the in-IDE solution lends itself to requesting feedback earlier with zero effort. If you can change your methodology towards earlier, shorter and faster code reviews, your team will produce better results in less time. Shifting left when it comes to code reviews is a big advantage that results in higher reviewer satisfaction and team alignment.
4. Document Your Code Automatically
When discussing code during a code review using GitHub, GitLab or Bitbucket, PR comments are exchanged and resolved, and serve their primary purpose of reaching a resolution. Still, the valuable explanations as to why a particular decision was made live in a separate system, away from the code itself, and are almost never referenced again. At CodeStream, our in-IDE code reviews include the ability to turn those discussions automatically into documentation, attaching the resolved conversations to the code blocks they refer to. Anyone with access to the code will also have access to the conversations that explain how it all works. As new developers join the team, onboarding time is reduced and solutions are better aligned because answers about past decisions are available and accessible.
5. Review with Full Source Tree Context
Your editor is designed to give you access to the full source tree, along with the key bindings, extensions, and code intelligence tools that make navigating and understanding code easier and faster. Performing a code review in your IDE means having your code superpowers at your fingertips. Other web-based code review tools only provide the reviewer with a tiny snippet of the code that surrounds the changes. CodeStream in-IDE code review solution lets you suggest changes and share knowledge in the comfort and familiarity of your IDE so you don’t need to switch windows or break flow.
6. Point to approved examples in any file or repo
Sometimes the best way to provide feedback is to point to an example that shows the code author the right approach to solving a problem or building a feature. If you are performing a code review in a web browser and can only comment on code that is changing this sprint, there is no straightforward way to present that example in context, right next to the issue you are addressing. When the review is performed in your IDE with a tool like CodeStream you can add one or more code blocks to any comment — just by selecting it — and explain exactly what you had in mind. The author can then simply click on the block and be taken to that exact location anywhere in the repo without leaving the code review and complete the necessary changes.
7. Shift Left, Save Time, Boost Team Performance
When you put together all the different advantages of in-IDE code reviews over the browser-based solutions, it becomes clear that shifting left is a time saver. We are all familiar with the exponential increase in the cost of fixing bugs over the five broad phases of software development.
If we break down the coding phase, we find that the earlier a developer gets feedback on code, the sooner a defect or wrong approach will be corrected and time and money will be saved. The ability to get feedback on just a few lines of code that are not even committed provides such a mechanism when you use an in-IDE code review solution. By sharing early work in progress a developer will be better aligned with the best coding practices of the team and the team will spend less time on frustrating web-based code reviews and more time producing great code that exceeds expectations.