I have nothing to do on the weekend, just chat with everyone. The topic I wanted to write was how to become a good programmer, but after thinking about it, I may not be able to count myself. So, being modest, I changed the title.
I will not write about the methodology or feelings this time, which may not be available to everyone, and may not be liked. Write something practical this time , as long as you do it, you will basically not be considered a rookie, and you will not step on thunder in the workplace.
Believe in the power of small habits
The difference between a rookie and a Daniel is in addition to the core ability to write code and debug, another big difference is in habits . Daniel has developed a series of good habits through trial and error, while the rookie has not yet developed good habits, and has a bunch of bad habits. Therefore, when you are a rookie, you must have a sense of norms and habits, develop good habits, and get rid of bad habits to make yourself more and more accustomed to writing high-quality code.
Regarding habits, benevolent sees benevolence, and everyone has their own habits. I'll just mention a few and give you some ideas.
A function does only one thing
How would you feel if one day you took over another colleague's code and found that he had a function with 3,000 lines of code in it?
This is my personal experience. When I saw the code, my first reaction was to pull this person out and beat him up. Unlike other textual information, the more crowded the code, the less readable it is . High-quality code is very similar to high-quality articles, with clear structure, distinct layers, and accurate expression. A function with thousands of lines of code in it is obviously old lady's foot wraps - 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 hard-pressed, just follow a simple principle - a function only does one thing . As a simple example, suppose we want to read a batch of data from the upstream, and then draw the result of a certain function. Let's briefly analyze it. On the surface, it is a matter of drawing, but this matter actually includes several steps, such as obtaining data from upstream, obtaining the result of function action, and finally drawing. Then we can completely split it into three functions, one to get the data, one to get the result, and one to draw the graph.
In this way, others and future self will see this code very clearly, and what each function does at a glance. If one day the boss accidentally flips through everyone's code, and someone else's code contains thousands of lines in a function, your code is clearly structured, and what each function does is clear at a glance, what do you think the boss will think?
longer variable names
A big problem for beginners is that they always like to have very short variable names , such as a,b,c,d. Or what bd, aa or something, looks very ugly and poorly readable. A few classmates asked me to help them look at the code before, and they were all given this kind of code, and it seemed that their eyes were pricked by needles...
Tucao returns to Tucao. To be honest, I also liked short variable names when I played acm before. 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 the time. Everyone was racing against time. Others have a variable called btn, and yours is binary_tree_node. Obviously, you will lose the speed of typing the code.
But the problem is that after graduating, I have always retained this style, and I have been beaten by my boss and colleagues without any accident. Everyone said they didn't like my coding style, but I still insisted at the time, thinking it was a reflection of my coding ability. Later, I read some Daniel's code, and after trying to change a style, I found that it was really fragrant. Although it is a little troublesome to write (in fact, it is not bad, there are various code completion functions), but it is really comfortable to read, and the thinking is much clearer . So if your current code is not in this style, please try to change it, it is 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, but we must not use pinyin.
It is more difficult to read Pinyin than half-speaking English, and using Pinyin as a variable or function name is a very, very low 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, please be sure to check them out.
Follow code guidelines
There may not be the word code specification in the novice's consciousness, but this is indeed the only way to go from novice to advanced.
The specifications of different languages are different. For example, the camel case is popular in Java and go, and all variables are in camel case. In Python, only class names may be camelCase, and common variable and package names tend to be all lowercase and separated by underscores. Of course, code specifications are not just naming conventions, there are many, many specifications. Such as middleware usage specification, multi-threaded development specification, database usage specification and so on.
Why should we follow these norms? Because our development work is not the end of the realization of the function, and it needs to be expanded and maintained in the future. Complying with the specification can not only prevent the future self and others, but more importantly, it can make your code higher quality and more professional. And there are often reasons hidden in some specifications. Why do sockets, threads and database connections need to maintain a "pool"? There must be a way here, otherwise why is it not easy for everyone to come here? When we comply with these specifications, it is also easier for us to better understand the principles and details of each scene, which is also part of our technical strength.
Of course, we may not be able to do it well at the beginning, but code specification is not very difficult. From this realization, it does not take a lot of time to comply with the specification, but the benefits are very rich. In the previous company, I heard about the bad performance of the boss because of the poor coding style. I think it is quite unfair. It may be a temporary negligence that left a bad image for the boss. If you can pay attention when writing code at that time One point, completely avoidable, the code is a bit too big.
Can use does not mean understand
If you are a fresh graduate, then when you graduate and enter the workplace, you will inevitably face an adjustment problem. We don't mention anything else, just talk about the technical aspects. We are bound to quickly learn some technologies that we have not seen or understood before to cope with the tasks and challenges in our work.
This is very normal, I think most programmers have experienced it when they just graduated, and myself is no exception. The first few months after graduation are the hardest, we need to bear a lot of pressure, and we are not fully adapted to the life after the change. But when a few months have passed, and we have adjusted to life and learned some basic skills to cope with or be competent at the current job, a potential pitfall arrives.
There are some people who stop studying unknowingly because he has enough for the job. At work, he will have the illusion that the skills I currently have in this field are enough. Some people even feel that other colleagues with more seniority are just the same. It seems that they have not much more knowledge than themselves. I was like this at the beginning, because I found that the things I use in my work are very slippery and easy to use. At one point I was a little bloated and felt like I was already a seasoned programmer. It was not until an interview later 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 fur, not even fur.
Of course, we only need to know how to use many technologies in our work. It is enough for you to know how to use them. There is no problem. I don't think that every technology we use needs to get to the bottom of it, but we need to have a clear understanding of our strength. Which ones are barely usable? Which ones are really understood and mastered? Which ones need to be mastered but only barely able to use?
Being able to think through these issues allows us to keep a clear head and have a clear understanding of our current situation and long-term development goals.
Accumulate knowledge, not just experience
One of the characteristics of novices or novices is that they tend to rely more on experience than knowledge , for example. For example, one of the problems often encountered by the novice backend is that the maven package fails. Many people's solution to the conflict is mvn clean & mvn install. That is, clearing and rebuilding, because this command can solve the problem in most cases. So many newbies remember this command, and they do it once every time they encounter maven failures.
What if this command doesn't solve it? These people may try another command. What if I have tried all the commonly used commands to solve the problem and it still doesn't work? These people may froze, thinking that this problem cannot be solved, and they have to invite a big cow to see it.
The core problem here is that newbies accumulate experience rather than knowledge. They just simply and mechanically map the problems and solutions, not to understand the reasons for the emergence of problems and solutions from the principle and core level . Then the result is that what is accumulated is only experience, and the next time you can solve the problem is not because you have learned the solution to the problem, nor because you understand the technical content, but simply memorize it. This is obviously a false growth.
In fact, I have encountered such a problem before, although I am conscious of the problem and record the solution every time, so that I don't need to ask others next time. However, although I have recorded more and more problems, every time I encounter a new problem, I still can't solve it, and I need to consult others. It was not until one day that the Daniel who was asked by me showed an impatient look, which made me make up my mind to learn to solve the problem by myself.
So I no longer solve the problem with a headache, but instead learn the principle and mechanism behind the problem, analyze the cause of the error from the error log, think about the solution, and finally learn to solve the problem thoroughly. method for a class of problems. After that, not only can I solve problems on my own, but I can also help others. I looked back on it later and thought I could have done better if I had tried to learn the mechanics myself the first time I encountered a problem, rather than just memorizing the solution.
Less bullshit, more code
Linus, the famous father of Linux, has a famous saying: talk is cheap show me the code . The translation is to say less nonsense and bring the code. I think this sentence is very in line with the essence of this line of work. We do not rely on lip service to eat, but rely on real output, and this output will eventually be implemented in the code. As a newcomer, we may have such questions and such confusion. However, it is useless to think about these many problems and confusions, and we can only solve them with hard power.
The famous C language author Tan Haoqiang also has a famous saying: the most important thing for beginners to learn programming is to write 10,000 lines of code that can be run, and then you will naturally get started. The truth is actually the same, less nonsense, more practical . The more you do and the more practice, the stronger your strength will naturally be. You can't become a big cow by fantasizing about it. 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, and start writing the code first. Do it, and you will naturally understand what to do next.
The above are some of the thoughts and ideas I have accumulated. If you are a novice, I hope it can help you pass the novice stage smoothly and move towards the goal of Daniel.
I wish you all the best of luck every day. If you still like today's content (like, follow, forward)