Three years of bug free, tips for improving code quality

The biggest impact on the quality of my code is in a foreign-funded enterprise , In this company, I think I have done very well in the following aspects .

• The team coding style is unified
  • To what extent ? Don't look at the code author , It's hard to tell who wrote the code ( At present, some teams in the company can also meet this standard ).

Personal view :

1. What are the benefits of doing so ？ It's easy for everyone on the team to read the code , Reduce a lot of communication , Maintenance cost ( Code is read much more often than it is changed ), And the mood is very happy . Some people must think that pleasure is a bit exaggerated , Take a chestnut : There are some codes , If it is not related to the work content , Do you have the feeling that you are reluctant to touch it all your life . But there is also some code , Read it down at one go , Feel better , It makes you feel the urge to continue reading ( And you also have the idea that you don't want to destroy this unity ).
2. The more unified the basic level , The more efficient ( It doesn't just mean the uniform coding specification , And the basic principles of doing things ). Take a chestnut : Our team stipulates that the personal weekly report must be sent out before work every Friday , Otherwise, a fine will be imposed 10 element . The phenomenon of late issuance of weekly team reports was quite prominent , Once the rules come out , A marked improvement ( The absence from meetings has also been significantly improved good ). Is the penalty unreasonable ？ How many notes are reasonable ？ Instead of spending a lot of energy discussing these trivial issues , It's better to standardize in time ( Generally, the specifications are not bad ), Strictly carry out . Follow up on Even if the problem is adjusted . The key is unity and strict implementation .

• The code is concise
  • can 1 Don't write if you can solve the problem 2 That's ok ( Without affecting readability )
  • Extra code ( For example, comment code or No practical significance ) Must delete

Personal view : Everybody knows that , There's nothing to say

• codereview
  • Team PLA( Team backbone ) Conduct codereview, Team PLA Code quality awareness between / And the code specification is very uniform . There won't be a team , Multiple criteria
  • The weekly meeting every Friday will review the code of this week review Review the problems that have arisen , Come to the conclusion . Put the example in wiki On , To provide a reference for similar problems in the future . New students can also learn from this content , Avoid similar problems . This is how a lot of content in the specification is accumulated .

Personal view :

1. I worked in a team in Ali ,PLA Yes 3,4 position , Take charge of their own business .PLA Between codereview Very few , There doesn't seem to be much conscious communication about code quality . But the common development students of the team are in these PLA Take turns between codereview, The standards of code quality are quite different . This may lead to 2 Species phenomenon : Development tendency review Relaxed classmates , Because loose review Find the problem ( not only bug) Less , The variable cost is small , There is no risk of failure due to changes , It will not affect the project progress ( However, the subsequent maintenance and communication costs will increase significantly Add ); Another phenomenon , Develop to different PLA Raise doubts ,PLA Unified code quality standards , Reach consensus and document within the team , As a follow-up reference .
2. The code quality of a team mainly depends on several members of the team PLA, It is suggested that the team should unify at an early stage PLA Code quality awareness and specification . for example : First of all 1-2 position PLA Do... For the development of the whole team review, This review The workload will be heavy at the beginning , And the team work efficiency is not high , But later review The workload should be significantly reduced , The code quality will also be significantly improved , The work efficiency of the team will also be significantly improved . The month when I first joined the foreign company was the most painful one for me , By codereview I feel very uncomfortable To adapt to : It is quite different from the previous coding habits ,review Too strict ( Variable name , Blank line , Note that grammatical errors in words can also be corrected ), Feeling limits coding freedom …. 1 After more than months, I realized the obvious benefits : code bug Less ; Less communication , Code and comments have solved most of the questions ; Reading code is efficient ; I feel that the code written by others is just like that written by myself , Very kind . A little over a month later , revew My code PLA Obviously relaxed for me review The content of , Because he has not review have a problem , And let me in every review Key points to be informed before review The content of .

• Execution and pressure
  • codereview Once the problem comes to a conclusion , It will be carried out immediately . If in doubt , We can continue to discuss , Until we come to a conclusion . The contents of the specification can be improved , But once the norms are formed, they must be strictly implemented .
  • Once a non-conforming code is submitted , The team will be reminded by email PLA And the boss , Remind me more times or continue to make similar problems , They would even dissuade .

Personal view :

1. The specifications of several departments I have experienced in Alibaba are very good , But some of them are relatively loose in implementation . Because the project schedule is tight , Code quality is easy to compromise , A common phenomenon “ I will change it in the next version ”, “ This should be OK for the time being ”, “ This code does not follow the specification , But the risk of change is too great , What to do if there is a breakdown ”. Now , If you compromise here , After the basic code specification is difficult to maintain . Because once ugly Code online , This code is likely to spread throughout the project ( Similar to the broken window effect ).
2. Many people are concerned about code quality / There is a strong sense of norms , But a few people may not feel so obvious or have not realized what these bring benefit , Or it may be different from your own habits and lead to rejection , At this time, we have to use external pressure to stimulate . For example, every Friday mentioned above review The question of the week – No one wants their code to be used as a negative example . Forcing him to move forward , Just be right about what you do and who you are . New people may feel more pressure , Stress will make you more cautious , It may also make you timid , Pay more attention to newcomers at this time .

Code quality understanding

• Code readability comes first , The code tries to don’t make me think( Here is a suggestion for the development of group middleware , I hope you continue to improve the readability of your code , Because your code has been read countless times , You can improve the readability , It will save a lot of people's time , Your code is likely to be imitated by many students )
• No, bug Your code is not necessarily high quality code , Writing code can not be satisfied with function
• Your code specification does not have to meet the open source specification standard ( Can achieve the best ), But don't be low ( pine ) The code specification of the team .
• Write code in awe . Imagine if you were to develop a program for a manned rocket , Dare you write at will ? Websites also need attention .
• Team code quality is more important than individual code quality . If only to meet the personal code quality improvement , Instead of helping the team improve code quality , You are likely to step into the hole left by others , You are likely to encounter various inconveniences in your work ( Of course, you should also avoid leaving holes for others ).
• Good code practices don't necessarily prevent you from bug. But it can help you / Others find bug The speed of , And improve work efficiency
• Read excellent source code ( Books ), Pay attention to some details , It is very helpful to improve code quality .
• codereview Not just for review Out bug. This is also a process of knowledge sharing , The more experienced students in the team will make suggestions on your code ;review People can get business from it / Technical information ; By review People because someone will review Your code , And shall not be Don't improve your code quality , And familiarity with the code .
• Code specifications do not affect development efficiency , Your development efficiency should be improved in other ways . contrary , He will save you a lot of costs ( read , communicate )
• In fact, the number of faults does not have much to do with your technical ability , And their own work habits are very big ( I have seen many failure cases , The vast majority of students who are not developers have no corresponding technical ability )
• What are you good at , Have a clear understanding of what you are not good at . The reason for some failures is that they are too confident in their own abilities . Consult other experienced students where you are not good at , It doesn't seem like you're weak , Instead, you give the impression that you value your work , Work carefully .
• The code has bug It's normal , The key is to find effective ways to prevent and avoid the recurrence of similar problems

Work habits

• When you get the demand , Analyze the importance of your requirements function points ( Needs of different importance , Attention and energy are also different ).
• Spend more time thinking when designing , Coding is usually faster
• Unit tests must be written , This is the bottom line. ( Unless the cost is very high )
• findbugs,pmd I used these tools a lot in previous years , But in recent years, it has been used very little , The reason is that there are few problems found , The probability of miscarriage of justice is still high , Now it is only used in a few cases . But newcomers suggest using it more .
• Look for students in the team who are more demanding than your code quality review Own code , Discuss the problem together , This can help you improve quickly . Where there is doubt, we must reach a consensus , Execute immediately , And inform the team , And form norms .
• Try not to be depressed , Doing a lot of thinking work when you are out of strength ( Personally, I prefer sports , There are many cases of physical exhaustion . ha-ha ).
• Writing code will inevitably lead to bug/ Failure occurs . Another way to avoid failure is to know the abnormal situation as soon as possible ( Such as monitoring ), Solve the problem as soon as possible before the user complains , Or prepare a plan in advance ( It is usually a more important requirement ).
• Don't ignore the mistake because it is small , That will become your habit .
• Try to minimize releases on Thursday , You may not have enough time to observe / verification , Special attention should be paid to when publishing .
• Reading the source code is one of my favorite things to do . On the one hand, I can be familiar with some technical principles / Business , More confident when developing ,bug Of course, the less likely it is , Of course, you may spend more time ( You have to measure ). This is also a last resort : Some department documents / There are problems with code comments , Communication may be inconvenient , Reading the source code solves the problem faster .
• When someone gives you advice , Be open-minded , You will get more help from others / Suggest

To continue

this This article has been paid more attention than I thought , I didn't intend to describe too many phenomena that affect code quality in this article , But the problems mentioned in the comments ( For example, how to land ) How much is involved in these . The article mainly looks at the generation from the perspective of common development Code quality , About how to land , I know it's not easy to land , There must be a lot of pressure from inside and outside the team .
Here are some chestnuts :

• Can your boss accept that short-term productivity is generally low ( If I use the codereview programme )?
• Do team members have a similar code quality philosophy to yours , without , You have to keep influencing them , You have to influence your boss . If you can't , There is no way to talk about landing .
• Every time the fault frequency is high , High level communication means valuing the user experience , Improve code quality . To develop here , Maybe it's safer coding , But it's not necessarily reasonable . It won't be long before , Code is bound to deteriorate .

To be honest , I don't have a complete , quantifiable , Replicable scheme , My current team has not reached this standard ,
But I was alibaba Experienced such a team , A team that I will never forget ( And the foreign company ). This makes me believe
My above ideas should be able to be implemented , I'm also trying to influence the team I'm in , Even if it doesn't meet my expectations
That way. , But I believe there will be improvement .
Alibaba It has been regarded as a business driven company , Maybe one day the code specifications of the whole group are unified and strictly implemented , It is estimated that becoming a technology driven company is not far away (O(∩_∩)O~~).