Code review is an essential practice of every successful project. It is necessary for achieving the desired level of code quality, and should be characterized it's collaborative and humane nature. In as much as code review protects code quality today, it is also one of the primary avenues of mentorship for an engineer.
GitLab's vision for code review is a place where:
The nature of code review will differ by project (commercial, open source) and contributor (full time, volunteer), but for all contributors code review should be a place to collaborate, grow, and improve so that everyone can contribute great work.
Interested in joining the conversation for this category? Please join us in our public epic where we discuss this topic and can answer any questions you may have. Your contributions are more than welcome.
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:
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.
In Progress: Smarter merge request diffs using merge refs
Code reviews are expensive, requiring engineers to carefully review the merge request diff to understand the changes being proposed. The accuracy of the diff is critical for effective code reviews. 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: Re-review and approval for merge requests
After a code review, the author will address the feedback with various changes and clarifying questions which the reviewer needs to answer and review before approving. This isn't a lack of trust, but a matter of quality and mentorship so that the feedback is addressed in full and correctly. This post-review pre-approval workflow is currently very difficult. We need to make this better.
Next: File-by-file merge request diffs
Diffs are the central place for code review in the merge request interface because that is where the code is actually viewed. Customers evaluating or switching from dedicated code review tools particularly highlight diff navigation, and performance as priorities. Larger merge requests suffer the most currently, both in performance and usability.
A file-by-file review interface will be much faster to load, provide better navigational affordances where the top/bottom of each file are in a predictable location, and scales from small to large merge requests predictably. The single-page scrolling diff interface is well optimized to very simple small merge requests, but becomes cumbersome quickly and manging performance becomes very difficult.
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.
Integrated code review packaged with source code management:
Dedicated code review tools:
Estimates place the version control systems market at USD 438 million in 2018, with forecast growth to USD 716 million by 2023 (source). Most Git hosting vendors (peers) offer integrated code review capabilities (GitHub, Bitbucket, Phabricator) and these are by far the most commonly used code review tools among current prospects and recent customers.
The dedicated code review tools market is much smaller, and the largest maturest dedicated product is bundled by Atlassian with rest of its suite.
Code Review and Source Code Management are typically seen as one and the same by most customers, particularly prospects already using an integrated product like GitHub. GitLab is competitive against it's peers, but this continues to be a well contested aspect of the source code management market, which is unsurprising given developers typically spend the majority of their time in a tool like GitLab performing code reviews or addressing code review feedback.
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.
The other important category of customer requests, that less urgent but requested are for improved workflow efficient in environments with complex approval policies:
Other notable requests include:
The top internal customer feedback is highly aligned with top customer feedback, with top feedback relation to improving the speed of loading and navigating diffs, and keep track of what has been reviewed.
Other important priorities include:
It is critical the merge request is reliably fast, accurate and efficient, as it is a blocking step in the software development lifecycle. It is important that GitLab smooth and streamline the process, and not become a source of friction or frustration to the adoption of best practice or high velocity.
Commits are the critical unit of work in Git, and used well are tremendously valuable. GitLab should be enabling and amplifying best practice behaviours using commits, so that the commit messages and each commit is a valuable asset for years. Great commit messages and meaningful commits allow developers to move quickly, and effectively make use of the entire ecosystem of Git tooling.
Coordination of responsibilities and handoff can be time consuming, particularly for changes spanning backend, frontend, database and perhaps other services. Tools to make requesting a code review, understand the progress of the code review, and hand off from reviewer back to engineer is important.
