I don’t know if you have encountered such a scenario. A serious bug occurred just after a feature was launched. The team worked overtime on weekends to deal with the emergency. You complained constantly; you and your boss are demonstrating new product features to customers. At that time, the system suddenly crashed, and the people present were embarrassed and hurriedly explained that this piece had not been dealt with.
What should I do if I encounter this kind of problem? Is everyone responsible for only one of the modules? Does the person who encounters the problem handle it? No, such busy classmates will be so busy, and idle classmates can do nothing; what about recruiting a test classmate? No, we do not have a recruitment budget;
In fact, to solve this problem is to do a good job in code quality management, and the most important method of code quality management is "Code Review", which is code review . For simplicity, I will use CR abbreviation below.
Code review explained in Wikipedia:
Refers to the systematic review of computer source code, often carried out by software peer review. Its purpose is to find and correct errors not found in the initial stage of software development, and to improve software quality and developer technology.
Simply put, CR is a way to improve software quality and developer skills by reviewing code.
Why do Code Review
So why can CR improve software quality and developer skills? And why do we do CR?
First of all, for beginners, CR is a good way to learn, because the person in charge of the main review often has more experience and knows where there are pits and what writing will cause problems, so that you can maximize the improvement from the code process personal skills.
Especially when senior colleagues give guidance and explanations to newcomers, the effect may not only be at the knowledge code level, but also have a profound impact on future work attitudes and learning seeking truth. It is important to know that work attitude is more important than knowledge and skills in the work.
I remember that when I was just doing my internship, I got the guidance of the company’s technical VP cosine boss, and colleagues around me also reviewed my code strictly. It was so sad to correct it line by line. Can clearly feel that I am improving.
Secondly, for senior developers, through CR, they can find that this kind of error is easy to occur, and they need to pay attention to avoid falling pits.
In addition, there are some functions in the development process and the methods you use may not be the best. When a colleague puts forward his opinions, ideas or skills, you can collide with sparks of thinking and benefit each other.
Finally, CR makes better use of human nature, that is, it is more able to find other people's problems. This mutual approach can greatly reduce the point of failure. According to statistics, a formal code review found a defect rate of 60-65%, and an informal code review of less than 50%, but many problems can also be found.
In this way, we have not only improved the development skills but more importantly, the software quality has also been guaranteed during the continuous exchange and discussion.
How to do Code Review
Having said that, what is CR, why should I do CR, let's talk about how to do CR first.
Usually, it is mainly based on the way that Github's Pull Request initiates a request to merge code, by pointing to one or more people responsible for the merger.
Code reviews are generally divided into three categories: formal code reviews, pair programming, and lightweight informal code reviews.
Let's look at the official gitlab example picture:
The above picture mainly shows what the request was submitted to do, and whether our integration test passed or not.
This mainly sees the changes in our code, which is convenient for people doing code reviews to read.
Let me talk about a simple CR step process:
1. 保证所有的单元测试和持续集成跑过，你这个提交做了什么事（避免浪费别人理解时间）
2. 这个代码至少有两个及以上的团队成员意见通过并且评论回复LGTM（回复任意的都行，有chrome插件可以检测这个数量）
3. 最终进行合并代码入库（可以指定固定人合并也可以不指定）
Explain the second step and ensure that there are multiple people to review and review, not only to ensure the quality of the code, but also to ensure that there will be no single point situation, for example, if you ask for leave, at least a colleague is familiar with the code you wrote. This is what we call high availability.
In the process of doing CR, we need to pay attention to:
When the code is not right for the person, it is often necessary to pay attention to the art of communication, especially when communicating asynchronously.
Try to unify the style as much as possible, but not to entangle the style, keep a tolerant attitude
To ensure that these two points we can discuss technical issues happily, and improve the quality of the software by the way.
summary
At the end of this article, let us review the main content of the article.
First, we introduced a method to solve these two quality problems through a serious bug and system crash-Code Review.
Then we explained that Code Review can improve code quality and team skills. By making good use of this method and human characteristics, it is not only a great help for novices, but also for experienced drivers.
Finally, we briefly talked about the process of Code Review and the points to note during this process.
So I would like to ask, is your team doing Code Review? How is it done? You are welcome to leave me a message and we will discuss it together.