Reviewing code from fellow developers should be considered a best practice. While its main goal is to make sure your teammate didn’t lose track of what a good software developer should do, it can also help the reviewer extend his knowledge of a project and get inspired by other’s code.
Things to have in mind/check when you review code include these 5 golden rules:
My team is using GitFlow on our own Git servers (i mean “no GitHub”, so no “pull request”). My way to actually review code is the following:
Identify what is the delta between this branch and its base branch (let’s say
First, get the base revision tag:
$ git merge-base branch-to-review develop ee682bdaf3a578a8de647006b500c87ca72c7ffc
Then, use your diff tool to visualize what changed (i personally use Kaleidoscope)
$ git difftool ee682bdaf3a578a8de647006b500c87ca72c7ffc HEAD
Clean up Git branches behind you
$ git branch -d branch-to-review $ git push origin :branch-to-review
Reviewing code that doesn’t include tests can be disappointing for a reviewer and adding some tests after an implementation feels like cheating. Here is a quote from Daniel Eggert - from the excellent objc.io - that both reviewers and reviewees should have in mind when reviewing/developing:
Tests should help us speed up development and make things more fun.
[...]Generally, if you find something difficult to test, that’s a hint that your design may be broken and that you should refactor some of it.
[...]You’ll get diminishing returns as you add more tests. First and foremost, add simple tests. Branch into more sophisticated territory as you start to feel comfortable with it.
Other resources discuss the subject:
I’ll try to add some examples and additions to this page as I process code reviews in the future. Again, feel free to get in touch to provide some feedback and as this page is open source and available on GitHub, pull requests are welcome. I’ll review them with a great pleasure.