Google is sharing “How to do a code review” as part of its engineering practices. Unlike many similar guides online, I find this document to be a lot more comprehensive. It covers both the technical bits of the process, as well as suggestions that improve overall team communications and efficiency.
A particular type of complexity is over-engineering, where developers have made the code more generic than it needs to be, or added functionality that isn’t presently needed by the system. Reviewers should be especially vigilant about over-engineering. Encourage developers to solve the problem they know needs to be solved now, not the problem that the developer speculates mightneed to be solved in the future. The future problem should be solved once it arrives and you can see its actual shape and requirements in the physical universe.
I am (and have been) a member of several teams and projects, which heavily rely on BitBucket (and BitBucket pipelines) for their day-to-day operation.
Happy 10 million milestone, BitBucket! Keep it the great work!
The cool bit about their documentation is that it covers both how to avoid the issues and how to solve them if they happened.
“How To Speed Up The Code Review” is a collection of excellent tips and strategies on how to make your Pull Requests easier to review. These work equally well for Open Source projects and for proprietary repositories.
The gist of this article is: don’t make large pull requests, and don’t mix different types of changes within the same pull request. Read the whole thing for suggestions on how to actually do that.