1. The reviewer should come from inside the project
The basic rule is that the code review should be done by someone who works with the code on an ongoing basis or knows it from the beginning. The code has to be technically correct, of course, but it also has to be in the style of the project and its standards. Each app is specific, and sometimes the theoretically right solution won't be optimal due to the technological and business nuances of the app.
A developer outside the project won't know the big picture and may waste time evaluating something appropriate for that particular project. He may also not know that some element has already been written, so he may accept duplicate code.
2. The code reviewer should be more experienced, but…
Code review aims to mentor and educate the programmer too. For both reasons, it should be carried by a developer with more experience, who has seen more, knows more, and can share their expertise.
Of course, when reviewing a senior's code, another senior should be doing it, sometimes from outside the project, because only some projects have more than one senior.
At the same time, you can't refuse code review even to juniors. Their approval isn't final, but reviewing the code of older colleagues is a great learning experience. And sometimes, a junior's review may occasionally surprise you because they pay attention to the foundations of coding, which seniors tend to forget. ;)
3. Don't be afraid of meetings and calls
Nothing consumes more time during a code review than discussing issues through comments; proper feedback could occur through real-life conversation. A quick (or not) phone call or f2f meeting will save you time for the commentary ping-pong.
If you catch yourself that your comment resembles an essay, just leave it and grab the phone ASAP.
4. Avoid perfectionism
When reviewing code, you must always find a balance between an ideal and optimal solution. For example, you don't always have to include all variables in the code five years ahead, especially in prototype startup projects.
Let me give you an example: we recently did a project that supports three social networks. Ideally, we'd write this code generic enough to easily plug it into other platforms. However, due to the prototype nature of the app, we gave up the ideal version in favor of a cheaper and more functional one.
I often see the "only perfect is enough" mindset among reviewing developers, and sometimes it probably is. In most cases, however, "better done than perfect" is more down to earth and works better.
5. Stick to the facts, not your preferences
Coding facts and standards should always be above private preference. If you're inspecting the code and feel like you'd name a variable differently, ask yourself: is the name bad, or do you just not like it? Suggest corrections if the code is wrong, but let it go if it's just about code style and private preference.
There's no need to fight for your code. Instead, find a balance between what impacts the project and what doesn't.
As a side note, comments like "that's not bad, but I would do it differently" usually confuse programmers and make them question the reviewer's opinion. Avoid them unless you have established procedures regarding what a code review looks like and the team knows what such a comment means and how to treat it.
6. Be honest and expect the same from the developer
This is more of a remark to the whole team or the company, but programmers should review themselves in an open and honest atmosphere.
The one who reviews should feel free to write what they think (with no aggression, obviously). The one whose code is reviewed is not to be offended by feedback but accept it humbly and be open if they don't agree or need help understanding it.
7. Build and test before reviewing
Stick to this rule without exception: until the app passes the tests, don't check it manually, and keep developers from asking for feedback. Automatic tests will catch many errors you won't have to focus on, saving you much time. Also, checking the code that needs to be changed in a moment to pass the tests is pointless.
8. Review small pieces of code
Finally, a little practical advice: code review should be done on relatively small pieces of code because the further into the code, the less qualitative feedback. Parsing long code is just tiring, and, in the beginning, you comment a lot, but then you let go more and more often because you don't want to pick on it since there is so much to improve anyway.
At the same time, short code reviews won’t give you the big picture of the code’s architecture, so you want to do a longer review occasionally (e.g., after a sprint or two) to see that the structure is maintained and useful.
Good luck, and enjoy your reviews! 🙂
