Three years 0 failure summary

Recently my boss and other teams have been emphasizing code quality and reducing failures (the frequency of failures seems to be a bit high recently). It has been almost three and a half years since I joined the company, and it has been almost three and a half years since my last failure, so I would like to share with you some feelings in this regard. From my personal experience , my understanding of code quality , and my work habits for code quality are three To analyze and summarize.

Personal experience

The biggest influence on my code quality is in a foreign-funded company. In this company, I think the following aspects are very good.

Unified team coding style
- How unified is it? Without looking at the author of the code, it is difficult for you to distinguish who wrote the code (some teams in the current company can also meet this standard).

personal opinion:

What's the benefit of doing this? It is easy for everyone in the team to read the code, reducing a lot of communication, maintenance costs ( the number of code readings is far greater than the number of changes ), and the mood is very happy. Some people must think that the pleasure is a bit exaggerated, for example: there is some code, if it is not related to the work content, do you have a feeling that you are reluctant to touch it in your life. But there is also some code that you can read in one go, feel good, and give you the urge to keep reading (and you also have the idea that you don't want to break the unity).
The more unified the basic level, the higher the efficiency (not only refers to the unified coding standards, but also the basic principles of doing things) . For example: our team stipulates that the personal weekly report must be sent out before going to work every Friday, otherwise a fine of 10 yuan . Previously, the team's weekly report was relatively late, and as soon as the rules came out, it was significantly improved (the situation of absenteeism from meetings was also significantly improved). Are fines unreasonable? How much is a reasonable comment? Instead of spending a lot of energy discussing these innocuous issues, it is better to unify the norms in a timely manner (generally formulated norms are not bad) and strictly implement them. Follow-up even if you make adjustments to the problem. The key is uniformity and strict enforcement.

code concise
- Don't write 2 lines if you can solve it in 1 line (without affecting readability)
- Redundant code (such as commented code or meaningless) must be removed

Personal opinion: Everyone knows it, nothing to say

code review
- The team's PLA (team backbone) conducts codereview, and the code quality awareness/and code specification among the PLAs in the team are very unified. There will not be one team, multiple standards
- Every five weeks, we will review the problems from this week's code review and draw conclusions. Put the example on the wiki as a reference for subsequent encounters with similar problems. New students can also refer to this content to learn the rules to avoid similar problems. A lot of content in the specification is accumulated in this way.

personal opinion:

In a team I have experienced in Alibaba, there are 3 and 4 PLAs, who are responsible for their own business. There are few codereviews between PLAs, and there seems to be little exchange of awareness about code quality. However, the ordinary development students of the team are alternately codereviewed among these PLAs, and the evaluation standards for code quality are quite different. This may lead to two phenomena: students who tend to review loosely in development, because the loose review finds fewer problems (not just bugs), the change cost is not large, there is no risk of failure caused by changes, and the project progress will not be affected (but Subsequent maintenance and communication costs will increase significantly); another phenomenon, development raises doubts to different PLAs, PLAs unify code quality standards, reach consensus within the team and form documents for follow-up reference.
The code quality of a team mainly depends on several PLAs in the team. It is recommended that the team unify the code quality awareness and specifications of PLAs in the early stage . For example: First, 1-2 PLAs will review the development of the entire team. The workload of this review will be very large in the initial stage, and the team's work efficiency will not be high, but the workload of the later review should be significantly reduced, and the code quality will also be significantly improved. , the team's work efficiency will be significantly improved.

The month when I first joined the foreign company was the most painful month for me. I felt very uncomfortable with the code review: it was quite different from the previous coding habits, and the review was too strict (variable names, blank lines, and comments with grammatical errors). I will also correct it), I feel that the freedom of coding is limited.... After more than 1 month, I realized the obvious benefits: less coding bugs; less communication, code and comments have solved most of the problems; reading code is efficient; I feel that others have written it The code seems to be written by myself, very friendly. After more than a month, the PLA of revew my code has obviously relaxed the content of my review, because he has not had any problems with the review many times, and let me review every time. You can tell the content that needs to be reviewed in advance.

Execution and pressure
- Once the problem from the codereview comes to a conclusion, it will be executed immediately. If in doubt, the discussion can continue until a conclusion is reached. The content of the specification can be improved, but once the specification is formed, it must be strictly enforced.
- Once any non-standard code is submitted, an email will be sent to the team PLA and the boss. If the number of reminders is too many, similar problems will continue to occur, and they will even be persuaded to quit.

personal opinion:

Several departments I have experienced in Ali have good standards, but some are more lax in implementation. Because the project schedule is tight, the quality of the code is easily compromised. The common phenomenon is "I will change it in the next version", "This should be no problem for the time being", "This code is not done according to the specification, but the risk of change is too great. What to do if it fails". At this time, if you compromise here, it will be difficult to maintain the basic code specification in the future. Because once ugly's code is online, the code is likely to spread in the project (similar to the broken window effect).
Many people have a strong awareness of code quality/standards, but a few may feel less obvious or have not realized the benefits brought by these, or they may be different from their own habits and feel repulsive. At this time, they have to use external pressure to stimulate one time. For example, the problem of the week of review every Friday mentioned above - no one wants their code to be often cited as a negative teaching material. It is enough to force him to develop in a positive direction and to do the right thing and not the person. The newcomer may feel the pressure more obviously. The pressure will make you more cautious in doing things, and it may also make you timid in doing things. At this time, you should pay more attention to the newcomer.

Code quality understanding

The readability of the code is the first priority, and the code should be as good as don't make me think . It has been done countless times, you improve the readability a little, it will save a lot of people's time, your code is likely to be imitated by many classmates )
Code without bugs is not necessarily high-quality code, and writing code cannot be strictly satisfied with functions
Your code specification doesn't have to meet the open source specification standard (the best), but don't be lower (loose) than the team's code specification.
Write code with awe. Think about if you were asked to develop a manned rocket program, would you dare to write it at will? The website also needs attention.
The team's code quality is more important than the individual code quality. If you only meet the improvement of personal code quality without helping the team improve code quality, you are likely to step on the pit left by others, and you are likely to encounter various inconveniences in your work (of course, you should also avoid leaving it for others. pit).
Good code practice doesn't necessarily make you avoid bugs. But it can help you/others find bugs faster and work more efficiently
Reading excellent source code (books) and paying attention to some details is very helpful to improve the quality of the code.
codereview is not just for reviewing bugs. This is also a process of knowledge sharing. Students with more experience in the team will make suggestions on your code; reviewers can obtain business/technical-related information; the reviewers have to improve their own code because someone will review your code. The quality of the code, and the familiarity of the code.
Code specifications will not affect development efficiency, and your development efficiency should be improved in other ways. On the contrary, he will save you a lot of cost (reading, communication)
The number of failures has little to do with one's own technical ability, but has a lot to do with one's own work habits (I have seen a lot of failure cases, most of them are not developers and do not have the corresponding technical ability)
You must have a clear understanding of what you are good at and what you are not good at. Some faults are caused by being too confident in your ability in a certain area. If you are not good at consulting other experienced students, it will not appear that your ability is poor. , instead give the impression to others that you take your work seriously and work discreetly.

working habit

When you get the requirements, analyze the importance of the function points of your requirements (the requirements of different importance levels, the level of attention and the energy spent are also different).
Spend more time thinking about the design, coding is usually faster
Unit tests must be written, this is the bottom line (unless the cost is very large)
I have used tools like findbugs and pmd a lot in the past few years, but they have been used very rarely in recent years. The reason is that there are few problems found and the probability of misjudgment is still high. Now it is only used in a few cases. But newcomers recommend using it more often.
Find classmates in the team who have higher code quality requirements than yours to review your code and discuss problems together, which can help you improve quickly. Where there is doubt, a consensus must be reached, implemented immediately, informed the team, and formed a norm.
Try not to do work that requires a lot of thinking when you are depressed and physically exhausted (I personally prefer sports, and there are more cases of physical exhaustion. Haha).
When writing code, it is inevitable that there will be bugs/faults. Another solution to avoid failures is how to know the abnormal situation as soon as possible (such as monitoring), solve it as soon as possible before the user complains, or make a preparation plan in advance (usually more important needs).
Don't ignore it because of small mistakes, it will become your habit.
Minimize posting on Thursday, you may not have enough time to observe/verify, especially when posting.
Reading source code is one of my favorite things to do. On the one hand, you can be familiar with some technical principles/businesses, and you will be more confident when developing. Of course, the probability of bugs will be less. Of course, you may spend more time (you have to measure). This practice is also a last resort: some departments There are problems with documentation/code comments, and communication may be inconvenient. Reading the source code will solve the problem faster.
When others give you advice, be open-minded, you will get more opportunities for help/suggestions from others

continued

This article has received far more attention than I imagined. Originally, I did not intend to describe some phenomena that affect the quality of the code in the article, but the problems mentioned in the comments (such as how to land) are all involved. These. The article mainly looks at the code quality from the perspective of ordinary development. Regarding how to land, I know that it is not easy to land, and there will definitely be a lot of pressure from inside and outside the team. Here are a
few chestnuts:

Is your boss okay with the general low productivity in the short term (if using the codereview solution I mentioned in the article)?
Do all team members share a code quality philosophy similar to yours, and if not, you have to keep influencing them and your boss. If you can't do it, there's no point in landing.
Every time the failure frequency is relatively high, the meaning conveyed by the high-level is to attach importance to the user experience and improve the quality of the code. When it comes to development, it may be safer coding, but it is not necessarily reasonable. Before long, the code will definitely deteriorate.

Frankly speaking, I don't have a very complete, quantifiable, and replicable solution, and the team I'm currently working on doesn't meet this standard,
but I have experienced such a team in alibaba, a team that I will never forget (and that foreign companies). This makes me more convinced that
the ideas above should be implemented, and I am also working hard to influence the team I am currently in. Even if it is not as good as I expected
, I believe that there will be improvements.
Alibaba has always been considered a For a business-driven company, maybe one day the code specification of the entire group is unified and strictly enforced, and it is estimated that it will not be far from becoming a technology-driven company (O(∩_∩)O~~).