What is code review and How to do a good code review

Code review is a crucial practice in software development that involves the systematic examination of code by one or more team members. This process helps ensure code quality, identify bugs, improve performance, and foster knowledge sharing among developers. Effective code reviews can significantly enhance the maintainability and reliability of software projects. In this guide, we’ll explore some common questions about code review to help you understand its importance and best practices.

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”.

What is the purpose of a code review?

The primary purpose of a code review is to improve the overall quality of the codebase. This is achieved by identifying and fixing bugs, ensuring adherence to coding standards, improving code readability, and sharing knowledge among team members. Code reviews help catch errors early, which can reduce the cost and effort required to fix issues later in the development process.

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.

Who should conduct code reviews?

Code reviews should be conducted by experienced developers who are familiar with the project’s codebase and standards. Typically, this includes senior developers, team leads, or peers who have expertise in the specific area of code being reviewed. It’s beneficial to have a diverse set of reviewers to bring different perspectives and insights to the review process.

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.

What are the best practices for conducting a code review?

Effective code reviews follow several best practices:

• Focus on the Code, Not the Developer: Critique the code constructively without making it personal.
• Keep Reviews Small and Manageable: Review small, incremental changes rather than large chunks of code to ensure thoroughness.
• Be Clear and Specific: Provide clear, actionable feedback with specific suggestions for improvement.
• Use Automated Tools: Utilize automated code review tools to catch common issues and enforce coding standards.
• Encourage Discussion: Foster open communication and collaboration to resolve ambiguities and share knowledge.

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?

Also Read: Choosing The Right Personal Area Network

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.

How can I prepare for a code review?

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.

To prepare for a code review, follow these steps:

• Write Clean, Readable Code: Ensure your code is well-documented and follows the project’s coding standards.
• Test Your Code: Write and run tests to verify that your code works as intended and does not introduce new bugs.
• Provide Context: Include comments or documentation to explain the purpose and functionality of your code changes.
• Be Open to Feedback: Approach the review with a positive attitude, ready to learn and improve based on constructive criticism.

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 tools can help with code reviews?

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.

Several tools can assist with the code review process, including:

• GitHub: Offers pull requests with inline comments and discussions.
• GitLab: Provides merge requests with integrated code review features.
• Bitbucket: Supports pull requests and inline code comments.
• Phabricator: A suite of open-source tools for code review and project management.
• Review Board: A web-based tool for peer code review that supports multiple version control systems.

What to do when you are asked for a 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.

• 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.
• 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.
• 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.
• 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?
• 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.
• 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.

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.

Also Read: Feedback in IB Math: Fostering Mathematical Minds

Conclusion

Code reviews are an essential part of the software development lifecycle, promoting higher code quality, improved collaboration, and knowledge sharing within a team. By understanding the purpose of code reviews, following best practices, and leveraging the right tools, developers can ensure that their code is robust, maintainable, and free of critical bugs. Embracing a culture of regular and constructive code reviews ultimately leads to better software and more effective development teams.