Let's say, hypothetically, that you have just started working for a new company. Finally, a perfect job you have always dreamed about...or at least, that's what it seems to be before you've taken a first look at the code. That's when the first crisis comes along. After you give it some deep thought, you realize that you can face it. You're not giving up so easily. After all, it's you who will be working there and you can (and should) make it better (and I mean here much, much better). You have to come up with a plan.
What can you do to both improve how things are right now and gain some knowledge about the project, which for certain will be useful in the further steps of your brilliant plan? The obvious answer comes to your mind: code reviews! Just think about it; it means that no more code that doesn't meet good coding standards will be created (or at least merged). You, of course, still have to deal somehow with the code that already exists, but at least it won't keep getting worse. (Actually, it may not be ideal, either, because every new feature is highly coupled with a really poorly designed company framework...but still.)
What Are Code Reviews Not About?
Some people perceive code reviews only as a way of controlling junior devs with more senior ones, making sure that they don't make any mistakes and don't break anything. Actually, a comprehensive suite of tests is a solution to that problem. The reviewer should, of course, give some thought to code correctness, but mainly by looking at tests and checking if they are covering every aspect of a story being implemented.
So, What Are They About?
Attention to Quality
When you write code with a belief that somebody is going to read and criticize it, then you are putting in more effort. Even if you won't write it perfectly (which most probably you won't because nobody does that), then the reviewer can suggest to you how to write it better. Maybe he knows some construct you haven't heard about, maybe some neat solution which will allow you to write less code.
Improved Code Readability
When you write code, it’s easy for you to say what it does, but when somebody else looks at it and has millions of questions, that means you have to improve it. You should keep making it clearer until that person will be able to understand it.
...both programming in general and project-related. This is especially important when there is a new team member who is still kind of lost in a project. Others can give him or her hints about how different modules are supposed to be used and prevent using hack solutions.
There won't be a single line of code about which only one person knows what it does. Developers will have wider view of a project, which may help them design better solutions. They will know not only the code they have written. That allows more flexibility in assigning tasks; no one will a have to stick to one topic for the whole time. They decrease the bus factor.
Code reviews help you to get a feeling of your team's coding style and to establish code conventions (it's always good to keep your code consistent).
How Should Code Reviews Be Done?
Here're a few tips which will help you to get the most out of code reviews:
- Everybody should be participating in the process, both as a reviewer and reviewee. If you are on a small team, everybody can review every line of code. In a bigger one, you can think of some rotational system.
- Code reviews should be done quickly. Don't make somebody wait a long time for your feedback. Faster is better, but it would be probably good enough to do them once a day.
- Ideally, code should be reviewed after all tests were run and tools in order to avoid comments like, “you have unused import here.” Of course, this should be made automatically after a pull request is created. However, that requires some infrastructure to be in place as well as a good suite of tests. In some cases, there might still be a long way to go, but the most important thing is to go in the right direction, even if you're making very small steps.
Code reviews can be a really valuable technique that reaches far beyond code correctness. Performed correctly, they’ll move you towards better code quality and a collective ownership. Basic code reviews guidelines include: everyone is participating in the process; reviews should be done as soon as possible; and reviews don’t serve as a replacement for static code analysis.