Code reviews are an important part of the mobile development project. Basically, it is the communication between several developers, sharing their opinions on the project and trying to figure out the best ways to optimize at early stages. As you may have guessed, it is very beneficial for both: the project, which will be looked at from different perspectives and the team, whose members will exchange their knowledge and boost the overall proficiency level.
In this article, we have gathered all useful tips and things on how to do code review as much effortless and effective as possible. So, let’s dive in.
Code review guidelines or things to look out for
The code review process is a very complex analysis of the product. The high quality review usually includes several different areas of attention. Here are the things to look out for in terms of style, design, and architecture:
• repetitive pattern: issues found in one part of the pattern may as well occur in the rest of the unit;
• code dupes: if the code is copied two or more times, it is better to change it to split out the common functions;
• single responsibility principle: a class or a method needs to have only one responsibility. In case the code does not meet this requirement, the level of abstraction might need reconsideration;
• bug prevention: the expected way of loop termination, possible off-by-one errors;
• errors: the way of handling errors, custom errors created and the overall effectiveness of custom errors;
• implementation efficiency: finding the most optimized way to handle each operation;
• code improvement: in case any modifications are applied by the reviewer, by the time the review is complete, the code should be a better version of itself;
• method and variable naming: weak naming is a common issue which can be easily prevented with a little thoughtfulness. Make sure that the function is not misleading and actually does what it says in its name. As for the names of the variables, try your best to use the most expressive variants in order for the code to be comprehensive;
• acceptable length: it is recommended to split the classes above 300 lines long into smaller objects to make the code easier to understand. Same goes for file length; the larger files have to be divided or reduced to make the whole unit optimized;
• code comments: there is no need for commented code and it is recommended to remove it;
• method arguments quantity: in case methods or functions have over three arguments, there is a chance that the organization of content could be improved;
• docstrings: the presence of explanatory docstrings for complex methods is yet another important point for overall readability of the code.
Another important part of our code review guidelines is testing. A highly qualified reviewer realizes that all the parts of the testing unit are important. Which means that prior to implementing the test, the test itself should be paid attention to. The size, the speed, the functional coverage, the overall thoughtfulness of the test are crucial for the result we are willing to obtain.
One more thing to keep in mind is that the test complexity should match the result we are expecting. In simple terms, if we need to know what a regular user might encounter, we need to test like a regular user and there is no need to under- or over- complicate if that was not our initial task.
The number of mocks is another point for consideration. In case there are over three of them being tested, most probably, the testing is way too broad or the function is too heavy. And that leaves us a room for optimization.
Checking all the requirements and making sure that they are met is an important final touch. In case at least one criterion is not addressed, it is better to return to the coding stage and fix it before it is passed to the QA team.
Being a reviewee
Receiving critics on the product you have put your knowledge, creativity and effort into can be a challenging experience. In order to be able to accept useful critics, you need to keep in mind the initial purpose of the code review. It is not done to mock you in any way and questioning your proficiency is also not the case. It may be hard to believe, but it has nothing to do with you personally. The true purpose of the review is to ensure the quality of the end product and to help to improve it.
Minding that the product quality is the main concern, keeping an open mind to any improvement recommendations is crucial. Not only will it open the door for the project’s success, but it will also give the developer a chance to step up his game.
When discussing the code, it is important to take off your defensive mode and look at the situation from a third party perspective. If some part of the code causes questions, maybe it is not as comprehensive as it could be and there is a potential for improvement. If certain reasonable changes are suggested and you do not have arguments against it, just calm your ego and try it out. Collaborating with the reviewer instead of competing can speed up the work and make the whole process way more effective.
Another important point which defines the quality collaboration is the instant reaction. While communicating with the reviewer, the developer receives a bunch of useful suggestions and gets his own ideas based on their discussion. The best way not to loose all that useful data is to document it and apply as soon as possible. The longer you wait, the harder it is to remember all the issues you are supposed to address.
Most of the time it is rather painful when certain code weaknesses are brought to light during the review. And when the things found by the reviewer are nothing but silly mistakes made due to rush or inattentiveness it is even worse.
High-quality professionals do not submit their work right after they are done with coding. They are their worst critics and usually review their own work in order to double check every code decision they take. Checking the whole unit once again before submission is probably boring, yet it is one effective way to minimize the future fixes.
Being a reviewer
You may have brilliant development skills and tons of knowledge which could be shared with your colleagues, however without mastering the craft of delivering the information, your sharing possibilities are very limited.
Start with questions. As many meaningful questions, as you can come up with. It will give you the fullest information in order to make accurate assumptions and provide a relevant piece of advice.
Make sure that your comments are targeting the code, not the person behind it. Try to make your comments as less personal as possible, without much room for second guessing. The idea of facing critics is already stressful enough and adding more edge to it will create unnecessary tension and will be counterproductive.
Provide full information. If you are saying that something is wrong, explain yourself. If you are thinking that another way of handling an issue is better, give some quality feedback. The grounded reasoning is the best way to carry on a constructive dialogue and to stay on the same page.
Sometimes, comments may be long and complicated. Sometimes, the communicating parties may forget that they are a team and the communication turns into a competition. In such situations scheduling a face to face meeting can be a good solution. It gives the opportunity to discuss complex ideas quicker. Also, it shows that your opponent is not a faceless mail agent, but a person just like you who cares about the outcome of the project as much as you do.
When suggesting some improvements, it is necessary to prioritize the requested changes. This way, they will not be overwhelming for the person who will implement them. Also, you will be able to analyze the influence of the changes on the quality of the project as a whole. In case updates will trigger new issues, it will be easy to track them down to the source action.
Last yet probably the most important tip is to acknowledge the work quality of the interviewee. We all strive for perfection so much, that many times we forget to appreciate what we actually have. Show your appreciation to the person and verbalize that their progress is seen and is acknowledged. Such simple things are often forgotten, however, these are the very things that build trust in the team, bring in loyalty and inspiration.
Code reviews: conclusion
Code reviews best practices will bring a number of significant benefits if done right. With the help of the useful tips provided in this article and a little bit of motivation, you will surely be able to implement code reviews in your team and make the best out them!