I summed up 10 good habits of programmers and shared them with you today.
1. When introducing a new technology stack, focus on official documents
In the project, whether using a new jar package or using a new middleware, be sure to read the official documentation.
Nowadays, the technical articles on the Internet are mixed, and the domestic search engine is not very good, so searching for reliable technical articles on the Internet is equivalent to fishing for gold in the shit pit.
For example, if you want to unit test code written in SpringBoot2, you may already have JUnit version 5. But the online articles you find will most likely tell you that test cases need annotations:
@RunWith(SpringRunner.class)
But the official documentation says, in fact, if you use JUnit5, you don't need to add this annotation, and adding it may cause unnecessary conflicts.
Therefore, the introduction of new technologies in official documents is the only reference gold standard.
2. Be sure to quietly test the code and then deliver it
In the workplace, what kind of people can grow rapidly and be reused quickly? The answer is reliable people.
As a programmer, what kind of person is a reliable person? The answer is to deliver reliable technology products.
The first evaluation criterion for a reliable product is that it has few bugs. This bug is rarely assessed by others, rather than by myself.
No matter how our own code is implemented, even if the code is not perfect, as long as we pass the self-test and solve the problem as much as possible before submitting, so that others will find less of your mistakes, especially low-level bugs, then You are a reliable programmer.
Therefore, before delivering the task, you must test the code in an all-round way to ensure that you have an excellent reputation.
3. When logging, try to print out the input, output and time-consuming as much as possible
What is the purpose of our logging? is to locate the problem.
What are the problems? In fact, there are basically two types, logical problems and performance problems.
Logical problem, if we print the input and output, then according to the business rules, such a comparison can easily locate the problem.
For performance problems, whether we use shell commands such as grep and sort to filter and sort logs directly, or use tools such as log collection and log search, we can easily find problems. It can even be combined with the monitoring system for direct early warning.
Therefore, when logging, we must remember to print out the input and output as well as the time.
4. Learn Git well
Git is so important. The current team development uses Git to manage various code versions and code branches. If you do not use Git well, it is easy to generate many unnecessary bugs due to merging code, upgrading versions, etc.
A team that doesn't use Git well may bring several inexplicable problems every time it goes online.
I would like to share with you a very good Git open source manual.
This manual is highly rated on Douban. It has a high score of 9.3 before and now has a high score of 9.1. Its author is an employee of GitHub. The content mainly focuses on the idioms and underlying principles in various occasions. The manual also aims at different According to the usage scenarios, several suitable version management strategies are designed.
In short, this manual is perfect for both beginners and developers who want to learn more about how Git works.
Douban 9.1 points of Git open source manual!
5. Prioritize the implementation of functions, performance issues may not be so urgent
When I was leading the team, I often found that some colleagues who were just starting out would struggle with the performance of the code they wrote while writing code. Actually it really doesn't have to be. Older programmers like us know that premature optimization can sometimes be a waste of time.
For example, if we write a batch scheduled task, this task only needs to be run in the early morning, and the task can be completed before everyone goes to work. So, is there any difference between this task running from two to six in the morning and from four to four?
The optimization code must be moderate. After writing the function, see how the function will be used, and optimize the areas that really need to be optimized according to the actual requirements.
6. Implement the most certain requirements first, and put the uncertain or vague requirements first
The order in which the requirements are implemented must be based on the reliability of the requirements.
There are generally two categories of requirements assigned to us:
- Some requirements are very clear requirements for both us and the product manager;
- There are also some vague requirements: everyone thinks that there is no problem during the meeting, but when the code is implemented, it is found that there are still many problems.
At this time, the skill we should deal with is to first build a unified shelf for these requirements, and develop the already very clear requirements first.
Since the shelf has been built, discuss those vague requirements with the product manager at this time, and it is easy to let the product understand the difficult areas, so that the difficulty of communication can be minimized.
7. Actively find problems in the project and give solutions
what is the problem? A problem is what needs to be solved in practice.
Find out and solve these problems one by one, and the solutions generated from solving these problems will form the driving force for the project to move forward. Then you yourself, who generate these impulses, will surely benefit a lot from them.
8. Evaluate the development cycle and allow for redundancy
The purpose of setting aside redundant time is very clear. When we developed, we encountered too many unexpected situations:
- Demand has changed again
- Team members have changed
- The estimated time was optimistic
- This function requires moving old code
- Requires cross-team development
- The leader said "add a small function", the leader believes that this small function does not affect the development cycle (two hundred words are omitted here)
- ……
Therefore, redundant time is to be set aside.
The redundant time set aside is not equal to the time to catch fish. The development is still done according to the normal rhythm, and the early completion and early delivery.
9. Don’t just read books to learn technology, realize the technology you are interested in through code
The most important thing for us programmers is practice, and we can turn the knowledge we have learned into practice and use it in our work.
Just reading books to learn technology is likely to only give us the illusion that we have already learned. Only by practicing the technology we are interested in through code can we really understand what the technology actually looks like and what needs to be paid attention to.
I won’t say much about the importance of hands-on practice. I have written some articles before on how to practice, such as this one to learn high concurrency by simulating the environment: inserting
10. English is still very important
You have to admit that in the IT industry, almost all innovations are born in the English-speaking world.
For example, k8s, as far as I know, the domestic technical staff with good English is gradually promoted in the country from the English community, and these pioneers who promoted k8s also naturally have the right to speak of k8s. You can look at the popularity of k8s in the market, and you can also look at the approximate salary of a k8s expert.
Moreover, as I said before, everyone must read the official documents when introducing new technologies. Eighty percent of the official documents are in English, so English is really important.
If English is not good, is there no chance? Not so absolute.
Let me tell you, I have not passed CET 4, but I can still read English materials and translate the first domestic Hibernate technical book with others.
At first, I used Hibernate as an early group of programmers in China, and I often went to the forum to answer questions, so later someone asked me to translate books together. I resisted at first, thinking that my English was too bad and I couldn't translate it well. Then I thought, since I can learn Hibernate by looking at the English documentation, why don't I try it. So just did it.
As a past person, what I want to say is that technical documents do not have particularly complicated grammar or uncommon words, and now there are translation software and plug-ins that can help us read them. Even if the basic English is average, it's not a big deal.
-over-
Hello, I'm Shimonai.
The technical director of a listed company, managing a technical team of more than 100 people.
I went from a non-computer graduate to a programmer, working hard and growing all the way.
I will write my own growth story into articles, boring technical articles into stories.
Welcome to pay attention to my official account. After following, you can receive high concurrency and algorithm learning materials.
