I have always believed that Code Review is one of the best practices in software development, which can effectively improve the overall code quality and find possible problems in the code in a timely manner. Including companies like Google and Microsoft, Code Review is a basic requirement, and someone must review and approve the code before it can be merged.
However, for most of the software development teams I have observed, there are very few serious Code Reviews, some are formalities, some may not have Code Review at all, and code quality only depends on post-testing. There are also teams that want to do a good job of code review, but don’t know how to do it better.
There are already many articles on how to do Code Review on the Internet, here I combine some of my own experience, but also summarized the best practices of Code Review, I hope to help you do a good Code Review.
What are the benefits of Code Review?
Many teams or individuals don’t do Code Review, and the root cause still doesn’t feel that it’s a meaningful thing to do, and they don’t think there’s any benefit. This question is to be seen from several perspectives.
- the first is the perspective of team knowledge sharing
in a development team, the level is high and low, and each person focuses on different areas. how to make a high level of help newcomers grow? how do you keep everyone in touch with knowledge outside of their area of focus? how can someone leave and someone else be able to take over quickly? these are all concerns of team managers.
CODE REVIEW, ON THE OTHER HAND, IS A GREAT WAY TO SHARE KNOWLEDGE. THROUGH CODE REVIEW, THE MASTER CAN DIRECTLY POINT OUT THE PROBLEMS IN THE NOVICE CODE, AND THE NOVICE CAN IMMEDIATELY LEARN GOOD PRACTICE FROM THE FEEDBACK OF THE MASTER AND GET FASTER GROWTH; THROUGH THE CODE REVIEW, THE FRONT END CAN ALSO LEARN THE CODE OF THE BACK END, AND THE FUNCTION MODULE A CAN UNDERSTAND THE FUNCTION MODULE B.
some experts may feel that giving novice code reviews is a waste of time and that they have not gained anything themselves. in fact, if the new person grows, he can help the master to share the heavy task more; the time spent in the code review is less time to help the new person fill in the pit and wipe the ass; good communication skills, the ability to find problems, and help others grow, are all indispensable skills for technology transfer management or technical advancement, and through code review, you can effectively practice these aspects of the ability.
- then there’s the perspective of code quality
real-life projects are always understaffed and tight, so what is compressed is often automated testing and code review, which affects the quality of the code, owes technical debt, and finally has to be repaid twice.
there are also people who hope for manual testing after development, but for code quality, many problems cannot be tested through testing, and can only pass code review. for example, the readability and maintainability of the code, such as the structure of the code, such as the dead loop triggered by some specific conditions, logical algorithm errors, and some security vulnerabilities are easier to find and prevent through code review.
there are also people who feel that they do not need code review at a high level. for masters, letting others review their own code can let others learn good practices; while letting others review, when explaining their own code to others, it is equivalent to reviewing their own code. this is actually the same as when we do math problems in school, and the ones who can really get high scores are often those who will be carefully checked after doing it.
- there is also the perspective of team specification
EACH TEAM HAS ITS OWN CODE SPECIFICATIONS, ITS OWN DEVELOPMENT SPECIFICATIONS BASED ON ARCHITECTURE DESIGN, BUT OVER TIME, YOU WILL FIND THAT THERE ARE MANY CASES OF NON-COMPLIANCE WITH CODE SPECIFICATIONS IN THE CODE, AND THERE IS A LOT OF CODE THAT BYPASSES THE ARCHITECTURE DESIGN. FOR EXAMPLE, DIFFICULT TO UNDERSTAND AND NON-STANDARD NAMING, SUCH AS THE UI LAYER IN THE THREE-LAYER ARCHITECTURE BYPASSES THE BUSINESS LOGIC LAYER AND DIRECTLY CALLS THE DATA ACCESS LAYER CODE.
if these code violations are corrected late, it will be costly to modify them later, and the team’s specifications will slowly become useless.
through code review, you can find and correct these problems in a timely manner to ensure the implementation of team specifications.
There are many more benefits to code review, and I won’t list them all. I still hope to realize that Code Review, like writing automated tests, is the work of a woodcutter who sharpens the knife and does not mistakenly chop wood, and investing a little time in it will harvest code quality in the future and save overall development time.
what to do?
Now many people have realized the importance of Code Review, but they don’t know how to practice it, and they don’t know how to consider it a good Code Review practice.
Make Code Review a mandatory rather than optional part of the development process
I’ve tried to review code as part of the code flow a long time ago, but it’s only an option, and it’s possible to merge code into a master without Code Review. The result of this is that you will do Code Review when you think about it, and when you check it, there are too many code changes, which is very difficult to review, and even if there is a problem in the review, it is difficult to modify.
Our current review of the code is a must in the development process, and every time a new feature is developed or a bug is fixed, a new branch is opened, and the branch is merged into the master with two requirements:
- all automated tests passed
- There is at least one person who passes the Code Review, and if it is a novice PR, there must also be a senior programmer Code Review passed
Image credit: How to Do Code Reviews Like a Human
In this way, the Code Review is a mandatory part of the development process, which ensures that the code has a Code Review before merging. And the benefits of this process of requiring code review before merging are also obvious:
- since there is a code review before each merger, the amount of code that is generally reviewed at a time will not be too large, and the pressure on the reviewer will not be too great
- If a problem is found during the Code Review, the reviewee hopes that the code can be merged as soon as possible, and will actively modify the reviewed problems so as not to be too resistant to the review results
If you find Code Review difficult to implement, try to make Code Review a must in your development process first.
Turn Code Review into a development culture, not just a system
After taking Code Review as a mandatory option in the development process, it does not mean that Code Review can be implemented very well, because the implementation of Code Review depends to a large extent on the careful review of the reviewer and the active cooperation of the reviewee, both of which are indispensable!
If it is just a process system, then it may become a formality. The end result is that there seems to be a Code Review, but no one carefully reviews it, just looks at it and passes it, or finds a problem and is not willing to modify it.
To really do a good job of Code Review, you have to make Code Review a culture for the team, and the developers accept it from the bottom of their hearts and implement it carefully.
to form such a culture, it is not so easy, nor is it as difficult as imagined, such as these aspects can be referred to:
- First, developers have to recognize the benefits that Code Review brings to themselves and to their teams
- then, there must be a few people who are good role models, and the power of example is very important
- also, for managers, what you motivate, you often get
- Finally, like writing automated tests, make Code Review part of the development task, and set aside time for both reviewers and reviewees to do it, not just thinking about the horses running fast and being reluctant to feed the horses
How to form such a culture, if you have the heart, there are many ways to try. Only by truly making everyone agree and practice can we do a good job in Code Review.
Some code review tips and tricks
In the matter of doing a good Code Review, there are still some empirical techniques to refer to.
WHAT TOOLS TO CHOOSE TO ASSIST IN DOING CODE REVIEW?
Now many source control tools come with their own Code Review tools, typical like Github, Gitlab, Microsoft’s Azure DevOps, especially like Gitlab, you can also build your own local environment, flexible configuration according to your own needs.
what kind of development process is better to work with?
Branch-based processes like Github Flow are particularly well-suited to Code Review. In fact, no matter what kind of development process, the key point is to do Code Review before the code is merged into the master (trunk).
what if i really have an emergency and it is too late to review the code?
Although in principle, a Code Review is required to merge, but sometimes there will be some emergency situations, such as online fault patches, and no one else is online, then in this case, it is best to create a Ticket in the task management system, which is used for follow-up tracking, to ensure that the code Review is followed, and there are subsequent code updates to the Code Review results.
design before coding
Some newcomers find that their code is submitted to a PR (Pull Request) and receive a bunch of Code Review comments that have to be made a lot of changes. This is mostly because before starting to do it, I didn’t do a good job of designing, and I found that there were many problems after making it.
It is recommended that before doing a new feature, write a simple design document, express your design ideas, find a senior one to help you do a design review, and find design problems. There is no problem in the design, and then start to develop, then when it comes to Review, the relative problems will be much less.
BEFORE SUBMITTING THE CODE TO CODE REVIEW, THE AUTHOR HAS TO REVIEW AND TEST IT HIMSELF
When I do code reviews, I sometimes find some very obvious problems, some of which I haven’t even tested myself, just waiting for others to review and test to help find problems. This kind of dependence is very irresponsible to both oneself and the team.
A good developer, before submitting the code review, must first review itself, write the automation test code that should be written, and run the basic test cases by themselves.
I HAVE A REQUEST FOR THE PR SUBMITTED BY THE TEAM TO ADD A SCREENSHOT OR SCREEN RECORDING TO THE DESCRIPTION OF THE PR, THAT IS, THROUGH THE SCREENSHOT OR SCREEN RECORDING, TO ENSURE THAT THE PERSON WHO SUBMITTED THE PR HAS TESTED IT FIRST. IT IS ALSO AN EFFECTIVE ADJUNCT.
PR SHOULD BE SMALL
When doing Code Review, if there are a large number of file modifications, it is very difficult to review, but if the PR is relatively small, it is relatively easy to review, and it is easy to find problems in the code.
THEREFORE, WHEN SUBMITTING PR, PR SHOULD BE SMALL, IF IT IS A RELATIVELY LARGE CHANGE, THEN IT IS BEST TO SUBMIT IN BATCHES TO REDUCE THE PRESSURE ON REVIEWERS.
rate comments
When doing Code Review, you need to add comments to the lines of code that are problematic, if it is only a comment, sometimes it is difficult for the reviewee to identify the meaning of the comment, whether it must be modified.
It is suggested that reviews of Review can be graded, and different levels of results can be marked with different tags, such as:
- [blocker]: a [blocker] tag is placed before the comment, indicating that the problem with this line of code must be modified
- [optional]: add an [optional] tag before the comment, indicating that the problem of this line of code can be changed or not
- [question]: add a [question] mark in front of the comment, indicating that the code line is not understood, there is a question to be asked, and the reviewee needs to reply to the question for clarification
Ratings like this can help reviewers visualize the Review results and improve Review efficiency.
comments should be friendly and avoid negative words; there are unclear questions to communicate in person
While comments are the primary code review communication method, don’t rely too much on them, and sometimes face-to-face communication is more efficient and easy to dispel misunderstandings.
in addition, civilized language, do not use some negative words.
summary
Code Review is a very good development practice, if you haven’t started, you may wish to practice it step by step; if you have done it badly, you may wish to check it to see if Code Review is a mandatory option in the development process rather than an optional option? Has Code Review become a development culture rather than just a system?