Code review is one of the most important stages of software development. Lately I’ve noticed that the topic is being treated a bit neglectfully. How to do a good code review? I will try to answer this question as best as I can, or at least give some hints.
How efficiently software is developed depends on many factors. Among other things, it is the team’s cohesion (whether there are no conflicts) or how well the tasks are “priced”. A well-coordinated team allows for a free exchange of opinions. It’s easier then to say the code sucks. No one will complain about it, and it may mobilize to write better, more readable code.
Table of Contents
What is code review?
First of all, it’s a discussion. Discussion between the author and other developers. No one should be afraid to express their opinion or ask questions here. The end result of a code review should be code that is not prone to errors. And the people involved in this process should come out richer in knowledge. Sometimes code review is the art of making difficult compromises, and sometimes wasting time on “philosophizing”.
Most would probably agree that code can be broken down into three categories:
- It works but is hard to maintain. This means that any major change in the code may negatively affect the existing functionality.
- It works and reads well. This is an ideal situation that every company would like to have. However, this
- requires a lot of discipline in teams or programmers.
- A combination of the two points above. Probably the most common situation in code.
- There are places in the code that can be placed in the first and second point.
- Also at the code review stage, it is determined in which of the above categories the code will be located. In our team, merge is done when the code is accepted by everyone.
So how to do a good code review?
There is certainly no golden mean here that will solve all problems. The matter will certainly be facilitated by company standards (guidlines) instructing how to write code. In the case of the frontend, some things can be done with tools such as prettiers or various types of linters. Unfortunately, these types of add-ons are responsible for the visual part of the code. They will not replace the human element.
What can be done by submitting the code for code review?
Think about whether the code reads well , whether something can be written better or shorter. Is the file in the right place and is there any justification for it? Or maybe something can be separated or made usable?
Don’t commit everything as one big commit . Break code into smaller chunks whenever possible. Fewer changes are much easier to analyze. After that, you can trace the process of change.
Add comments to your code describing your solution. This will allow the person on the other end to understand your intentions and the reason (context) for the changes. It may turn out that the proposed solution is optimal in this particular case.
If you make code changes, don’t commit them as cr fixes ! It says nothing. Describe the actual changes to the code. Conventional commits will work perfectly here (pro tip: when making changes to the code, you will want to precede your commit message with refactor:).
What to do when you are asked for a code review?
1. Do it quickly if possible
Code review is only part of the entire software development process. Such code still needs to be tested by QA. The longer you delay doing this task, the more you block the process. Of course, if the amount of code is greater, it is obvious that it cannot be checked and “pat” in five minutes.
2. Does the code look good?
Are too many arguments passed to the function or component? Does this piece of code do what it needs to do? Is it in the right place? Or maybe some condition is too complicated and something should be simplified? Or maybe the names of the variables or functions are not well named? All of these (and probably a few other things) affect code quality and maintainability.
3. Run the code locally
It is a very good habit to check if a team member has implemented the functionality correctly or corrected a bug. Is everything working as it should, are the basic cases covered. In our company, before submitting the code for testing, another person from the team (not QA) must check if everything is implemented correctly. Thanks to this, we reduce the chance of an error appearing at a later stage.
4. Testy!
It’s good to check if the code has been tested (there are even machines for that). I know that tests are different and it depends on many factors. This is worth paying attention to. Covering the code with tests, even the hard-to-maintain one, will partially reduce later problems. If there are tests, it is worth paying attention to what is in them and whether it makes sense. Are snapshots of React components (or css styles) sufficient?
5. Create a dedicated meeting to discuss code or issues
Code meetings work very well for my current team. Each of us shows what he did and why. Then everyone asks questions that turn into interesting discussions. We’ve written a lot of comments before, but they didn’t work well for more complex problems. Such a meeting is a good time for live coding (or pair coding) in which we solve a given problem together.
6. Be kind
I don’t think this needs to be mentioned. Sometimes I encounter situations in which some people like to add biting comments in the code for a rule or have cooler relations with someone (e.g. in the team). Also, remember that if you see an interesting solution, don’t be afraid to show it off.
Also read: What is electronic logbook
