There was no code navigation, some syntax highlighting but arguably not the best, and it didn’t feel as intuitive as reading code in your IDE of choice. The first is that gitlab’s tool for reading code worked largely like just reading over a text file. It can be merged once someone gives it the thumbs up. A developer would create a merge request and notify the team, wait for someone to look over it. We were originally using GitLab for code reviews.
This works well because it means we have a second set of eyes to check over the code and look for issues before it moves past the development stage, and turnaround time on bug fixing is always lower the earlier it happens. When the programming work is finished, the developer who wrote the code must seek out a review before it can move on. A code review is the last step before a JIRA ticket may be marked as finished development. We use a fairly standard agile workflow with JIRA where a developer picks up a ticket which describes a feature or user story, creates a git branch for it and moves it out of development when it’s complete. Finally, when you have a large team managing a very large codebase, having constant code reviews makes sure that we don’t get stuck with only one or two people knowing how something works and thus being the only people able to work on it. We also like it to share the knowledge around, by reading others’ code and having your own examined, you get to learn from everyone else’s technical knowledge, making us all better programmers. We use code reviews as a safeguard for code quality – nothing gets deployed to production without a review. Some Shiners have recently started using a new tool called Upsource that has helped us become quicker and more effective at code review. They improve code quality, share technical knowledge and keep everyone up to date on what’s going on in your codebase.