Believe in the power of habits

In addition to the gap in core abilities of writing code and debugging, the other big difference between rookies and experts is their habits. An expert has developed a series of good habits through hard work, but a rookie has not yet developed good habits and has a lot of bad habits. Therefore, as a rookie, you must be aware of norms and habits, develop good habits, and get rid of bad habits so that you can become more and more accustomed to writing high-quality code.

Everyone has his or her own habits.

A function only does one thing

If one day you took over another colleague's code and found that he had a function with three thousand lines of code, what would you do? Feelings?

This is my personal experience. When I saw the code, my first reaction was to pull this person out and beat him up. Code is different from other text information. The more crowded it is, the less readable it is. High-quality code is very similar to high-quality articles, with clear structure, clear layers, and accurate expression. A function containing thousands of lines of code is obviously an old lady's foot wrap? It's smelly and long.

Everyone has a different understanding of how much code should be written in a function. In fact, we don't need to be rigid, just follow a simple principle? A function only does one thing. To give a simple example, suppose we want to read a batch of data from upstream, and then draw the result of a certain function. Let's briefly analyze it. On the surface, it is just a matter of drawing a picture, but this matter actually contains several steps, such as obtaining data from the upstream, obtaining the results of the function, and finally drawing the picture. Then we can completely split it into three functions, one function to obtain data, one function to obtain results, and one function to draw pictures.

In this way, others and yourself in the future will be very clear when they look at this code, and it will be clear at a glance what each function does. If one day the boss accidentally looks through everyone's code, and someone else's code contains thousands of lines in one function, and your code is clearly layered, and what each function does is clear at a glance, what do you think the boss will think?

Choose longer variable names

A big problem for novices is that they always like to give short variable names, such as a, b, c, d. Or something like bd, aa, etc., which looks very ugly and has poor readability. Several classmates asked me to help them read the code before, and they all gave me this kind of code. It looked like my eyes were being pricked by needles?

Complaints are complaints. To be honest, when I was doing acm before I also like short variable names. Although it is not so exaggerated, generally a variable name is not very long. Of course, this was due to the needs of the competition at that time. Everyone was racing against time. Others had a variable named btn, and yours called it binary_tree_node. Obviously, you will lose if you work hard on the code.

But the problem is that I kept this style after graduation, and as expected, I was severely beaten by my boss and colleagues. Everyone said they didn't like my coding style, but I persisted at that time, thinking it was a reflection of my coding ability. Later, I read some great code and tried to change the style, and found that it was really good. Although it is a little troublesome to write (actually it is not bad, now there are various code completion functions), but it is really comfortable to read and the ideas are much clearer. So if your current code is not in this style, please try to change it, it will be good for yourself and others.

Another point is that when we name it, we can use non-standard English. Even if it is not accurate, it is okay, but we must not use pinyin.

Reading Pinyin is more difficult than half-understanding English, and using Pinyin as a variable or function name is a very, very low-level thing, which will definitely make the other party doubt your ability. There are also some plug-ins on the market that help with naming. Students who have needs in this regard must check it out.

Abide by code standards

The word code standards may not be in the consciousness of novices, but this is indeed the only way to advance from a novice.

Different languages ??have different specifications. For example, camel case naming is popular in Java and Go, and all variables are in camel case. In Python, only class names may be camelCase, and ordinary variable and package names tend to be all lowercase and separated by underscores. Of course, code standards are not just naming standards, there are many, many more standards. For example, middleware usage specifications, multi-threaded development specifications, database usage specifications, etc.

Why should we comply with these regulations? Because our development work is not done just after realizing the function, it will also need to be expanded and maintained in the future. Complying with the specifications will not only prevent yourself and others from being exposed in the future, but more importantly, it will make your code quality higher and more professional. And there are often hidden truths in some specifications. Why do sockets, threads and database connections need to maintain a "pool"? There must be a way to do this, otherwise why wouldn't everyone do it simply? When we comply with these specifications, it will also help us better understand the principles and details of each scenario, which is also part of our technical strength.

Of course we may not be able to do a good job at the beginning, but code standards are not very difficult. Once we realize that it does not take a lot of time to comply with the standards, but the benefits will be huge. It's very generous. In my previous company, I heard about people being given poor performance by their bosses because of poor coding style. I felt that it was quite unjust. It might have been a moment of negligence that left a bad impression on the boss. If I had paid attention when I was writing the code, One thing, completely avoidable, the code is a bit too big.

Being able to use it does not mean understanding it

If you are a fresh graduate, you will inevitably face an adaptation problem when you graduate and enter the workplace. We won’t mention anything else, just the technical aspects. We are bound to need to quickly learn some technologies that we have not seen before or do not understand in order to cope with the tasks and challenges at work.

This is very normal. I think most programmers have experienced it when they first graduated, and I am no exception. The first few months after graduation are the hardest. We have to bear a lot of pressure and are not fully adapted to the life after the change. But when a few months have passed and we have adapted to life and learned some basic skills to cope with or be competent for our current work, a potential trap has arrived.

Some people will stop learning unknowingly because they have enough to cope with work. At work, he will have the illusion that the skills he currently knows in this field are enough. Some people may even think that other colleagues with more senior qualifications are just that, and they don’t seem to know much more than themselves.

I was like this at the beginning, because I found that the things I used in my work were very smooth and easy to use. I was a little bloated for a while and felt that I was already an experienced programmer. It wasn't until later in an interview that I was asked about the technical details of a commonly used tool. I was speechless and couldn't say a word. I realized that what I knew was only superficial, not even superficial.

Of course, the requirement for many technologies in our work is just to be able to use them. It is enough that you can use them. There is no problem. I don’t think every technology we use needs to be thoroughly investigated, but we need to have a clear understanding of our strengths. Which ones can we barely use? Which ones do you really know and master? What do you need to master but can only barely use?

Being able to think through these issues can keep us clear-headed and have a clear understanding of our current situation and long-term development goals.

Accumulate knowledge rather than just experience

One characteristic of novices or novices is that they tend to rely more on experience than knowledge. Let’s give an example. For example, one of the problems that novice backend users often encounter is the failure of maven package. Many people solve the conflict by mvn clean & mvn install. That is, clear and re-establish it, because in most cases this command can solve the problem. So many novices remember this command and do it every time they encounter maven failure.

What if this command cannot solve it? These people might try another command. What if you have tried all the commonly used commands to solve the problem and it still doesn’t work? These people may have froze, thinking that this problem cannot be solved and that they need to ask an expert to take a look.

The core problem here is that novices accumulate experience rather than knowledge. They just mechanically map the problems and solutions instead of understanding the problems and solutions from the principle and core level. Reason for taking effect. The result is that what is accumulated is only experience. The next time you can solve the problem is not because you have learned the solution to the problem, nor because you understand this piece of technical content, but simply remember it. This is obviously also a kind of pseudo-growth.

Actually, I have encountered such a problem before, although I consciously record the solution every time I encounter a problem, so that I don’t have to ask others for advice next time. However, although I recorded more and more problems, I still couldn't solve them every time I encountered a new problem and needed to ask others for help. It wasn't until one day that the boss I asked looked impatient, that I made up my mind to learn to solve the problem myself.

So I no longer solved the problem head-on, but instead studied the principles and mechanisms behind the problem, analyzed the causes of the errors from the error logs, and thought about solutions. , and finally thoroughly learned how to solve this type of problem. After that, not only can I solve problems independently, but I can also help others. I later looked back and thought that I could have done better if I had tried to learn the mechanics the first time I encountered a problem, instead of just memorizing the solution.

Talk less nonsense, more code

Linus, the famous father of Linux, has a famous saying: talk is cheap show me the code. The translation means stop talking nonsense and bring the code. I think this sentence is very consistent with the essence of this industry. We do not rely on words, but on real output, which must ultimately be implemented in the code. As a newcomer, we may have such questions and confusions. However, it is useless for us to just think about these many problems and confusions. We can only use hard power to solve them.

The famous C language author Tan Haoqiang also has a famous saying: The most important thing for a novice to learn programming is to write 10,000 lines of executable code, and then you will naturally get started. The truth is actually the same, talk less nonsense and do more practical things. The more you practice, the stronger your strength will be. You can't become a great person by just wishing and boasting. So if you are hesitant to learn a new field but don’t know where to start, you might as well think about this sentence, don’t worry about it, get started and write code first. After doing it, you will naturally understand what to do next.

The above are some thoughts and ideas I have accumulated. If you are a novice, I hope it can help you successfully pass the novice stage and move towards the goal of becoming a master.