| Section | Stage | Maturity | Last Reviewed |
|---|---|---|---|
| Dev | Create | Loveable | 2020-01-24 |
The Code Review strategy page belongs to the Source Code group of the Create stage, and is maintained by James Ramsay.
This strategy is a work in progress, and everyone can contribute. Please comment and contribute in the linked issues and epics. Sharing your feedback directly on GitLab.com is the best way to contribute to our strategy and vision.
Code Review is an essential practice of every successful project. It is necessary for maintaining and improving code quality, and is one of the primary avenues of mentorship for software engineers, but it is also time consuming.
GitLab's vision for code review is a place where:
GitLab should make these tasks efficient and easy, so that velocity and code quality both increase.
The primary metric by which we measure the success of the Code Review category is: reducing the duration of the Code Review. This is measured as the duration from the first merge request version to merged.
Code Review is a critical quality gate and shouldn't be artificially truncated, but being blocked waiting for feedback is obstruction to reducing cycle time. Improving the efficiency of code review by making them faster, easier, and real time should, we hypothesize, reduce the barriers to best practice code reviews.
Category-level UX baselines conducted quarterly will provide qualitative feedback to validate perceived efficiency and our hypothesis.
Code review is used by software engineers and individual contributors of all kinds. Depending on their context, however, the workflow and experience of code review can vary significantly.
The code review process involves at least two roles (author, and reviewer) but may involve many people, who work together to achieve code quality standards and mentor the author. Furthermore, many reviewers are often not Developers. Reviewers may be Developers, UX Designers, Product Managers, Technical Writers, Security Engineers and more.
In support of GitLab's vision for code review, areas of interest and improvement can be organized by the following goals:
In Progress: Smarter merge request diffs using merge refs
Code reviews are time consuming, requiring engineers to carefully review and understand the proposed change. The accuracy of the diff is therefore critical.
Additionally, both Atlassian and GitHub have made their diffs smarter, showing the actual difference between the source and target branch, not the source branch and the merge base of the target branch.
In progress: Code intelligence (e.g. symbol docs, jump to definition)
The purpose of code reviews is to identify defects, and ensure the code meets quality guidelines for style, readability, and maintainability. In order to do this, the code reviewer must understand the proposed change well.
We know that code intelligence is an important tool for understanding code, and has been available in local development environemnts since the 1980s. Because of this many developers rely on local code intelligence when performing code reviews. Providing this to all reviewers in GitLab will improve the quality and efficiency of code reviews.
Next: Comment on multiple lines
Feedback doesn't always relate to a single line, and it can be restrictive to be unable to comment on a range of lines. Similarly, suggested changes to merge requests can also span multiple lines in a diff, but it is difficult to use this feature without a natural interface to select multiple lines.
Next: Improved merge request reviewer assignment
Detecting defects, and providing meaningful code review feedback requires understanding the code being changed. This is most effectively done by subject matter experts, which are typically people who have previously edited or reviewed the areas of the code being changed.
Helping authors find the right reviewer will yield better code reviews, and carefully distributing them across many engineers will prevent individual engineers becoming over burdened.
This category is currently at the Loveable maturity level (see our definitions of maturity levels).
GitLab competes with both integrated and dedicated code review tools. Because merge requests (which is the code review interface), and more specifically the merge widget, is the single source of truth about a code change and a critical control point in the GitLab workflow, it is important that merge requests and code review in GitLab is excellent. Our primary source of competition and comparison is to dedicated code review tools.
Prospects and new customers, who previously used dedicated code review tools typically have high expectations and accustomed to a high degree of product depth. Given that developers spend a significant portion (majority?) of their in application time in merge requests, limitations are quickly noticed and become a source of frustration.
GitLab’s current code review experience is largely modeled after GitHub’s, with most of its pros and cons. Gerrit and Phabricator are frequently mentioned as the best alternatives to the GitHub code review model. See the competitive analysis for a closer look at the user experience and feature set of competitor tools.
Integrated code review packaged with source code management:
Dedicated code review tools:
IDE-related:
The highest priority customer requests are for improved application performance, accuracy and efficiency for reviewing merge request diffs of all sizes, small and extremely large.
Other notable requests include:
Investigating: Commit focused code review
Small changes are easier and faster to review, and commits are the smallest unit of change. Some of the largest projects in the world use commit based workflows for this reason.
We are investigating how we can amplify best practices in commit focussed workflows, and bring these into GitLab to improve code quality and efficiency.
Investigating: Real-time merge request collaboration
Merge requests are highly asynchronous today. A code review is requested, and then at some point later the author returns to address the feedback. This causes all but the simplest of merge requests to go through multiple slow review cycles.
GitLab aims to help teams compress cycle time and increase velocity. To this end, reducing the number of review cycles, and preventing frequent context switching should help.
Since we know many teams are located in similar timezones, if not located in the same physical location, we can improve notifications and workflows to help people work together on the same merge request in real-time.
Read more in our blog post.
Investigating: Track unread merge request comments and commits
When reviewing a merge request with multiple commits, a large number of changes, or that requires many revisions, it's hard to know what requires your attention, and what you have previously reviewed. This is a factor in making code review inefficient.
