The headline of this article was conceived of by one of our engineers, @BrianCanzanella, during a brainstorming session to come up with a tag-line for CodeStream’s light-weight, pre-commit, pre-pull request (or pre-merge request) code review functionality. Many of us thought it was brilliant given all the frustrations developers voice over code review but, for whatever reason, it didn’t perform that well when used in the banner ad below.
But we still liked the tag-line so we figured, let’s try it out as a headline for a blog article to discuss how CodeStream addresses common code review frustrations. Below are some of the common things we hate, or rather used to hate, about code reviews and how CodeStream alleviates them.
Big code reviews are indeed big interruptions to one’s productivity. The obvious recommendation is to do smaller code reviews but with many developers relying purely on PRs or MRs for code review there is a conundrum in that more PRs mean more friction and different headaches. Commit. Push. Pull. Again. And again. Who wants more of that? The solution is to decouple the code review from the PR. With CodeStream’s Feedback Requests one can request a review of code in any status including pre-commit. This realistically enables smaller reviews without adding more PRs, more commits, and more friction. You can still have a monster 500 line PR at the end of the development cycle, but with Feedback Requests most of those 500 lines could have been reviewed in smaller, iterative, and less interruptive chunks prior to the PR. You can read more about this particular issue at Smaller Pull Requests are like Faster Horses.
There’s no place like 127.0.0.1, and on a developer’s desktop home is the IDE. When it’s 3AM and there are no incoming emails or Slack UMIs lighting up and you’re super in the zone, are you scrolling through Jira tickets or PR comments in a web-browser, or are you writing code...your mind and keyboard and keybindings all acting as one?
While sure, doing a code review may require a break from writing code, but you’re still in a developer’s mindset, and if it’s a small review as discussed above, you should be able to get right back to coding without skipping a beat. Unless you were distracted from your development, and any time you leave your IDE you’re risking distraction.
With CodeStream, whether doing a lightweight pre-PR code review with Feedback Requests, or doing an old-fashioned MR or PR code review using our GitHub or GitLab integrations, you can conduct the review right from your IDE with no emails, UMIs, or open browser tabs to get in the way.
Most web-based tools for doing PR and MR code reviews only let you see a few lines of code making it difficult to truly evaluate what’s being reviewed outside the limited scope of syntax or variable nomenclature. To really understand one more often than not should be able to review the code in the context of the full-file or even other files in the project, but since doing that is a headache (see the next section) it’s very easy to just give a cursory “LGTM” which kind of defeats the purpose of code review.
Besides eliminating context switching and the risk of distraction, moving code reviews into the IDE with CodeStream, again for both our frictionless Feedback Requests and also for PRs, lets reviewers view code where it’s most natural....where one writes code with full file access and all the code-intelligence embedded in your editor.
Smaller PRs is an illogically inefficient suggestion for the author given all the headache and friction involved in a PR. But it’s also completely inefficient from the perspective of the reviewer where if they want to see changes in the context of the full-file, and not just a web-based snippet, it requires the unwelcome dance of pulling and stashing, and then reverting back when complete. For a quick review, it’s likely there’s more time spent on this effort than actually reviewing. With CodeStream Feedback Requests a reviewer does not need to alter their environment. CodeStream will automagically display the changeset, with full-file diffs, from the perspective of the author...even across different branches. After giving some feedback or updating status it’s back to work on your own branch. Yes, magic.
Regardless of which side you’re on in the above scenario, it’s very much an “eeew” of code review. But the effort of commit (which implies committing to) and push plus the reluctance of interrupting someone else’s work is a formula for saving the code review (when tied to the PR) to the end of the development cycle. Finish work. Request PR/Review. Smaller reviews, as discussed above can also mean more iterative reviews on work-in-progress which can reduce the frustrations associated with late feedback, but also as discussed above, smaller iterative PRs are simply not a realistic expectation. CodeStream’s Feedback Requests, however, allow developers to easily request feedback on work-in-progress, even before committing, and allow reviewers, without needing to switch windows, context, nor branches, take a look and provide quick feedback. By using Feedback Requests for small reviews along the way, even if there’s a more formal big PR at the end, you can eliminate “you need to start over” scenarios.
Above are a handful of items that used to frustrate developers when doing code reviews tied to PRs but have been greatly reduced when moving to CodeStream’s lightweight reviews via Feedback Requests. If there are others that we missed please let us know.
Please share your thoughts and feedback @teamcodestream.
New Relic CodeStream integrates all of your essential dev tools, such as GitHub, GitLab, Bitbucket, Slack, Teams, Jira, Trello and more, into VS Code, Visual Studio, and any JetBrains IDE.
During our daily stand-ups we demo features in development to allow everyone, which now includes you too, to stay in the loop and provide early feedback.