(the reason for this article is my micro blog. I want to say more. It's a bit messy. Where can I write it?)

These two days, I expressed the importance of code review on Weibo. Looking at the records on Alibaba's internal review board, it is found that code review is well done by some more technical teams, while the business oriented technical teams basically don't see the records of code review. Of course, this doesn't mean that they didn't do code review without records. So, I asked my colleagues who had worked in the business team before if they had code review. He told me not only that they didn't have code review, but also that they thought it was useless because:

1) The construction period is too tight, and the time is not enough for coding. The purpose is to go online,

2) The requirements are changing and the life cycle of the code is too short. So, the good code has no meaning, rotten rotten, anyway has nothing to do with performance.

I don't agree with this view very much. I think I am a programmer and an engineer. Like a doctor, I am not only good at treating patients, but also responsible for their long-term health. For common diseases, it's very easy to cure patients quickly. It's very fast to prescribe strong drugs and use a lot of antibiotics. But as we all know, this is obviously the practice of "drinking poison to quench thirst" and "fishing with all the water". Doctors need to have a sense of responsibility and medical ethics. I also think programmers and engineers need to have a corresponding sense of responsibility and cultivation. I have to be responsible for everything. I don't think this kind of responsibility and cultivation is finished when we do it, but when we do something beautiful. This is the difference between "Shanzhai" and "industry". But only to "make it out" as the goal standard, I can only think that such an approach is just a "step-by-step" stack of code, and labor-intensive "assembly line" and "bricklaying" is no different, it is better to leave in this environment.

To be honest, when I was in the business team last year, my team didn't do code review either, because there are various reasons. One of the important reasons is that I just came to Ali, so what I need to do is to adapt to Ali's culture. Any company has its own style and characteristics, and any company's practices have its own reasons and causes. For a newcomer like me, the first thing is to adapt and observe, not to make too many changes to the team, and following, understanding and trust are the key to integration. (Note: I had some resistance in building the Beijing team and not full-time testers), so I didn't play code review with the team. After a year's work, I feel that I have compromised a lot of things I have insisted on before, and I feel that my standard is decreasing. I want to think about pulling out the cool on my back, so I decided to stick to it, but also stick to the high standard.

For Code Review's very important point was criticized by some engineers, architects / experts and even senior architects in Alibaba after it was posted on Weibo. During the process of reply and discussion with them, I found that there was a "because of the settings of the other user" that I couldn't reply (I was blackmailed, and some of them were directly sarcastic and abusive, so I deleted it directly in Weibo ) These criticisms of my Alibaba Engineer / architect are summarized as follows: (by the way, there are still many teams in Alibaba who insist on code review)

1) To the business team experience, how many projects are forced to schedule? How many of them require one month in advance after the delivery date is set? Now it's not easy, let alone beautiful!.

2) Code review is a kind of dogma with little significance. There are tests. As long as there is no error, it is OK.

3) The goal is to improve the quality. The limited input always hopes to have the maximum output. Different ways of indulging in improving the quality are different. The business application development is as busy as the dog, and the business logic changes fast, the commonality is poor, and the cost of codereviw is higher than the bottom.

4) The main contradiction now is the contradiction between the inverted schedule and unreliable programmers. I don't think Cr is a silver bullet to solve this problem. It's too much to masturbate that we don't show the truth.

We can see that the above opinions have little to do with code review, but they are actually complaining about other problems. These ideas are actually the contradiction between the technical team and the business team, but I don't know why the idea of "code review is very important" was imposed on me, and then these ideas in turn hit "code review" and said "code review is useless". This way of discussing problems is very common. When you say a, I say B, originally a and B are two things, but they need to be confused, and then it is specious to use B to prove that your a viewpoint is wrong. (perhaps, these engineers / architects are resentful and need a way to vent)

I think that many times, people don't think clearly about problems, a large part of the reason is because they confuse many problems, even me sometimes. take warning.

Even if they are confused, I'll split them up. They are also the following three questions:

• Is code review useful.
• Problems that code review can't do.
• Business changes fast, fast problems, technology tired of following life.

Code Review

If you Google the key word code review, you will find that the benefits of code review are basically non controversial. There are many articles and blog posts about the importance of code review, how to do it better, and many companies will join the question of "code review" in the interview process. Open Wikipedia and you'll see a description like this——

Capers Jones has analyzed more than 12000 software development projects, among which the potential defect rate of formal code review projects is about 60-65%, and the potential defect rate of informal code review is less than 50%. In most tests, the potential defect rate will be about 30%.

For some key software (such as the embedded software of safety critical system), the general code review speed is about 150 trip codes per hour, and the review speed of hundreds of lines of codes per hour is too fast to find the problems in the program. Code review can generally find and remove about 65% of errors, up to 85%.

There are also studies to analyze the types of defects found in code reviews. Of the defects found in code review, 75% are related to computer security risks. For software companies with long product life cycle, code review is an effective tool.

I don 't think it is necessary to say more about the benefits of Code Review. The main purpose is to make your code better organized, easier to read and more maintainable. At the same time, it can achieve knowledge sharing. Finding a bug is just a by-product. It's not new anymore. You can find many articles online. I won't talk about it. Just as you write programs to judge errors, code review is the most basic common sense thing.

I have been immersed in strict code review since 2002. My personal growth has a lot to do with code review. If I haven't experienced code review in my growth, I can't imagine it.

I think the code has these levels: 1) compiled, 2) run, 3) testable, 4) readable, 5) maintainable, 6) reusable. The code passing the automatic test can only reach level 3), while the code passing the code review will be less at level 4) or higher. For code review, you can refer to "several tips in code review" on this site

It can be seen that code review is directly related to your engineering ability!

Problems in code review

There are several situations that will make your code review ineffective.

The first thing to bear the brunt is "lack of personnel ability". I have experienced such a situation. In the process of code review, everyone stared at each other. They had no good idea, did not know what was good code and what was bad code. As a result, most code reviews are in code style. Today, I'll tell you that code style is a matter of self-examination by every programmer and should not waste everyone's time. In this regard, I have two suggestions: 1) your team's people are wrong, it's time to change blood. 2) Let your team take the time to read the code book (and, of course, a lot of basic knowledge books).

The second thing is that "the result is more important", that is to say, it's more important to do it, and it's not important to be beautiful. Based on how many works I've done! Instead of how perfect they are! It reminds me of the engineers who use spring MVC to do crud pages every day. I admit, they are very skilled. A lot of repetitive work. In fact, a lot of things can be framed, templated or generated automatically. So, in order to pile up so many pages, we stop to pile up. There are many things to do, but there is no growth. You may have done a lot and got a good year-end bonus, but you also lost a lot and the chance to become an outstanding engineer. You could have doubled your monthly salary after 1-2 years, but after one year you only got a few year-end bonuses.

Then there is "the attitude of the staff". On the one hand, they are lazy and don't want to keep improving. They just need to finish the work and hand over the work. To this end, you need to vigorously carry out code review, so that the code written by this kind of person can be exposed to more people, so that he can be ashamed of the code with poor quality. On the other hand, some people will think that it's someone else's module. I don't understand it, and I don't have time to understand it. I just want to say that if your team has more things like "self cleaning in front of the door", then the team will have less initiative. Without initiative, it's impossible to be a good team and do well. And for individuals, the less likely they are to grow.

Then there is "the problem of changing requirements". It is recognized that the requirements become fast, the code life cycle is relatively short, and good code is not needed. Anyway, in two days, these codes will be abandoned. If it's a one-time thing, the quality doesn't need to be too high. Anyway, throw it when you use it. However, I think it's more or less necessary to review this one-time bad code. If all your projects are temporary code, is your team also a temporary team? If you want to cope with the change of requirements, you can read the articles of "requirements change and IOC" and "UNIX design ideas to cope with the changing requirements". From these articles, I believe you can see that the code quality needs to be higher for the change of requirements.

Finally, "time is not enough". If the business forces you to rush, it's not a good question of code review, it's a question of requirements management and project management, as well as other non-technical issues. I will say next.

In any case, the above problems of code review should not be the reason or excuse for "code review is meaningless", which is like "stop eating because of choking". There will be difficulties and problems in doing everything. Some people have retreated in this way, but some people see that the advantages outweigh the disadvantages. They still insist. The differences between people are in this place. That's why sports get hurt, but people still go to sports, and some people flinch because they are afraid of injury.

Forced too much by business

Forced by the business, the demand changes in disorder, which has little to do with code review. I want to tell you a story about this.

I was at jushita in Ali last year. When I first went there, jushita was making a big reconstruction - a big adjustment to the architecture. As a result, many business demands were pressed. After the project took 2-3 months to complete, 30-50 demands were poured in at once, and it was stipulated to complete in one month, which made the team exhausted. After two weeks of tiredness, I carefully analyzed these requirements and found that many of them are repeating what Alibaba cloud has already done, and some of them are caused by the nonstandard and nonstandard jushita platform. So I did three things:

1) Redefine the main objectives and scope of jushita, and determine what to do and what not to do.

2) Set standards for jushita, make alicloud APIs basically the same, and set access standards for cloud resources.

3) Promote the reconstruction of Alibaba cloud's portal system, no longer realize what Alibaba cloud has done, and closely integrate with Alibaba cloud.

It's not easy to push these things forward. The business side of jushita didn't understand it at the beginning. I did business side work with products, and Alibaba cloud was also forced to be miserable by me (thank you here, especially Alibaba cloud's classmates. To be honest, the cross team cooperation with Alibaba cloud is the best one I've felt for so many years, which is very good). Through this matter, the demand for jushita will drop in quality. So there are several engineers to tell me that if you do this, jushita will be OK. Let alone engineers' understanding of jushita. I just want to say that I have greatly reduced the demand, united the people who should be united as much as possible, rather than building the car behind closed doors, and made the goal and direction of the product clearer. After doing these things, we not only don't have to work overtime, but also have time to charge to learn technology and think about the future direction and development of jushita. Last year, when the company was in 996, my team was still in 965, and there was still a lot of time to study new things.

I didn't tell this story for the sake of success, but because some people criticized me on Weibo as a hypocritical pretender who only talks about concept and reason. So, I'll tell you how I did it in jushita. I wrote it publicly here. You can also ask relevant students to verify whether what I said is true or not. I can also prove to you that I may be a pretender, but I am not just a pretender who talks about concept and reason.

Don't complain when you are forced by the business side. You don't have time to work like a beast. At this time, what you need is to pause and think about why it works like a beast? And that's the chance to be smart.

Let me summarize for you,

1) Do you go to review business department to give you so many requirements, which are reasonable and which are unreasonable. At Amazon, development engineers are taught to ask, "why? How influential is the business? How many users benefit? " , I can't answer this question clearly. I won't do it without the support of data. Therefore, the product manager should do a lot of data digging and user research work, rather than clap his head, and listen to a few users' complaints about the need.

2) Product managers also need to manage and educate. You should tell your product manager: "you are a good product manager, because you not only have a good grasp of users, but also of software technology. You will not only provide external functional requirements, but also internal non functional requirements to make the software system more perfect. You are not accommodating users, but guiding them. You don't add unlimited functionality, but you take control of the product soul and simplify functionality. You will be equally proud of what you have to do and what you don't do. " You have to tell your product manager, "it's better to make half a year's products than to make a half a year's products" (for more views, please refer to "rework excerpt and Reflections")

3) We should be efficient in doing things. Amazon likes to use an evaluation method called t-shirt size estimation to prioritize the "happy case" with small input and large output. You can see the article "overtime and efficiency" about what is efficiency and what is t-shirt size estimation.

4) Demand always changes. Don't complain that demand changes too fast. What you should complain about is why we didn't take the right direction? Old change? It's like playing football, where you're going is where the ball is going, not where the ball is. You need to know where the ball is going, you need to know how the ball moves before. After finding the trajectory, you need to know where the ball is going. If you don't know where the ball is going, you're a headless fly. Go east and West.

When you are as busy as an animal, you should stop and ask yourself, is the reason why you become an animal because you think like an animal when you do something?

Other

Finally, in my sharing of "technology shaping life" to Alibaba's new graduates this year, I set up 5 or 6 homeworks for them to share with you:

1) Refactor or write a module to make it the real elegant level.

2) Share one or several technical articles with you and get 10-30 likes.

3) Reduce existing repetitive or maintenance work by at least 20%

4) Reject or simplify a requirement (requires all the stakeholders in the project to agree)

The reason for the deployment of these assignments is that I hope the new students will adhere to high standards for their work. I know you will compromise because of the reality of bone feeling, but I hope you will adhere to the highest standards in your heart even if you compromise in reality. Don't get used to being natural, and finally be influenced by the society. Because you're at least responsible for yourself. To be responsible for yourself is to vote with your feet and leave if you can't stand the compromise.

Zhilan was born in the empty valley, not because no one but not Fang! A gentleman cultivates himself and cultivates his way. He doesn't change his mind with poverty!

Thank you for listening to me.

(end of the paper)

Follow coolshell wechat public account and wechat applet

——===Visit cool shell 404 to find the missing child. = = = --

Loading...