| Stage | Maturity |
|---|---|
| Create | Loveable |
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.
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: Progressively load merge request diffs
The product discovery sprint conducted to kick off File-by-file merge request diffs made it clear that loading the merge request diffs progressively in any way requires significant work.
Merge requests are used by the majority of GitLab customers, and for these customers it is a critical path in ensuring quality and getting work done. Many large numbers of customers have reported performance problems working with large diffs, or those with lots of discussions. Conversations with customers, and experience says show although it is best practice to have many small merge requests, this is not always possible in situations like refactors, large changes, or pulling in changes from a diverged fork managed by a different company.
Today the merge request interface loads all diffs and disscussions in a single request, which causes timeouts, poor page performance, and frustration for only moderately large merge requests. Addressing this is the highest priority because the merge request is a critical workflow, other capabilities of GitLab are integrated into and rely on the merge request, and we are obstructed from addressing the most important UX feedback.
Next: Smarter merge request diffs using merge refs
Early backend preparation work has been made in support of GitLab CI.
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.
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.
Integrated code review packaged with source code management:
Dedicated code review tools:
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:
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.
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.
