I’ve asked thousands of developers about code reviews and they all agree that code reviews are a key part of the development process. All developers know about the importance of code reviews, but only some companies have a defined policy and just a few of them manage them effectively.
So here is where my question arises, what’s wrong with code reviews? Since GitHub started to grow, pull requests became very popular for open source contributions. Now, companies are also using them to reinforce their internal code review process.
Are pull requests the best way to do intra-company code reviews?
Maybe for small features it could work, but let’s say that you are working on a 2-week sprint feature or a huge refactor. Are you sure you want to wait 2 or 3 weeks until someone reviews your most junior developers code?.
We think that code reviews should happen before someone says “I’m ready to merge this into that branch, please take a look at it and let me know your thoughts”. In the end, that’s what you are saying when you create a pull request.
Partial Reviews
At Gitcolony, we love partial reviews. We built a workflow system that allows teams to proactively review code as it’s being built instead of reactively waiting for a pull request. We call this, LIVE BRANCHES.
Partial reviews are very important for companies, so they can tackle issues before it’s too late, do a correct follow up on less experienced devs, get continuous feedback and have everyone in the dev team involved on the daily basis. This makes the review process much more actionable and meaningful.
I wanted to finish this post with one of our mantras: “Ask a developer to review 10 lines of code and he’ll find 10 issues, ask him to review 500 lines and he’ll say it looks good”.
