Every programmer should go through the process of transformation from vegetable chicken to cow. At the beginning, everyone started from the same point, after years of work, some people still stay in the vegetable chicken, some people have become a big ox, all things, are little by little habit. Let’s see how a programmer writes code. It’s possible to find your shadow back then, or even your shadow now.
First, the naming is not standard
Named casual writing code was particularly High, what name have some strange: xiaonaigou, XXXX, j1, jl, LLST. Completely unaware of the value and significance of the full name specification.
Second, the log is not standard
The log? What the hell is that? Is it edible?
I once had a friend from Pactera who was working as an engineer three years later, but didn’t know how to solve the problem. We have to restart. Ask me to help him. What’s wrong? I don’t know. The log? No.
Dizzy, that how solve a problem, immortals also can’t do.
As it turns out, they solve the problem by changing the code locally and then deploying it, revisiting it to see if the error disappears, and then continuing to change the source code locally.
Reject write interfaces and fake data
** A dish chicken is not terrible, terrible is the dish chicken met dish chicken. ** once had a project in which there were two cooking chickens, one front end and one back end. They happily adjusted the interface and did not write documents at all. Both of them were extremely efficient. Until one day, I found that the project might not be finished, and I needed the help of two other front-end dishes. We don’t know the Url of the interface. We don’t know Get or Post. We don’t know the parameters sent and return values. Write it like that! I had no idea I could write code like this, and the two chickens were very happy! Clap hands: It’s working, it’s working, it’s working!
What do I say you understand? They said the interface finally worked! It turns out that the page between their two references, just keep trying again and again, so guess the interface! Is that the fun of programming? And not writing fake data. Once there was a ma xiao Ge, zhao Xiao ge said: 3 days, give me 3 days, I give you the real data. So zhao surnamed little brother believed it. And so it went, three days after three days, three days after three days, three days after three days, three days after three days. For a whole month and a half, Zhao did not get all the data!
Don’t write unit tests
Specifically, it’s not TDD development. With ides as powerful as they are today, the habit of writing unit tests first isn’t just about code rigor, it’s also about efficiency. But a lot of people don’t understand the value of unit testing. That’s ok. When the code is refactoring and requirements are changing, they can’t cry. With good unit tests, your logic will be clear. This is often the case when I first start my unit tests
Five, first integrate, then test, then abandon.
Most of the time, when introducing third-party libraries, frameworks, interfaces, or services, the preferred thing is to integrate them directly with their own code. What are the results? All of a sudden it doesn’t work, it doesn’t run, you don’t know what the problem is, you don’t know if it’s a third party problem or your own problem.
What’s a good way to do that? First run through the official Demo, and then try to add their own business bit by bit.
Six, not clear logic, do while guessing
There are a lot of problems with the front end here. When we do payment, we are not clear about the payment process and the definition. We always think that the front end is the interface to deal with the data and display the data. A lot of dish chicken will have this habit, this is not good, the first logical processing, figure out the process, and then go to work.
Seven, do not make a plan
What does it mean not to plan? It’s just walking by instinct.
It’s like closing your eyes and hitting the brothel. A good code habit is to go through all the requirements details in your head first, and get the implementation details out. Last month, there was an anonymous comment feature with the surname Xiao CAI Ji zhang. Basically no experience, brain is not good, what is the way to give it can you guess? The user refreshes each time to insert a piece of data into the user table, password default nickname random. I don’t need to say more tears. I’ve seen too many schemes that make people stare at their eyes. How can you help them tune the wrong code? There are so many benefits to planning.
8. Not focusing on performance
Not focusing on performance is also a common mistake for newcomers. What is performance. TPS and response time for the back end, response time for the front end. The habit of many new programmers is to build things and then optimize them. In the end, the product is made and the optimization is left to others. A focus on performance is also one of the most critical skill points for a mid-level programmer. At the time of writing the code, experienced engineers already know the performance of the method, the function, the function point, and where the bottlenecks are.
Fear of refactoring
“A programmer’s greatest courage is to look at code he wrote three months ago.”
Refactoring should not be done after a few months, but in real time. In a day of coding, 70% of the time is spent refactoring. As for the new guy, knock, knock, kick, Kick, kick, kick, kick, kick, kick, kick, kick, kick, kick, kick, kick He’ll fight you like hell. Why don’t you ask him to do a line of code himself? Not refactoring also means to some extent that your code implementation cannot be refactored. When you see code that you haven’t touched in a few months, it looks like this:
Make it, don’t consider elegant scheme
** There is a word called best practices, but coding specifications and best practices are an important reflection of programming skills. Elegant solutions can be thought of as an updated version of best practices that complement the constant refactoring mentioned above. What’s the bad solution? It’s hard coded, it’s not extensible, it’s done in an ugly way. For example, if the wheels are square, it is ok for the car to drive:
Last time, they made a plan about audition classes. The normal logic is to add a field in the user’s table to indicate how many classes a person can audition. The requirement is how many people are invited and how many classes they can audition, so they can directly check in the inviter’s list to determine how many classes they can audition. I didn’t think about what happens if I change the conditions of the audition? In fact, this should be broken down into two parts, one is the generation conditions of the audition, which is an independent module, plus one is the confirmation of the audition. There are too many examples like this, which is also related to not making plans and not considering expansibility. That’s what I’m going to say.
11. Not considering future changes in demand
The level of an engineer can actually be divided into the following stages:
1. Function oriented programming 2. Performance oriented programming 3
The first thing engineers do when they get a requirement should focus on the following questions:
First, which requirements have I completed before? Second, which requirements are likely to change? Third, there are several plans and what kind of demand changes are supported
When a new renewal comes, it is often pushed back to the beginning:
But almost programmers don’t consider so much, one is for business not familiar with, judge not to come out which requirements may produce change, is a master of optional scheme is not much, there is no room for optional, there is no this kind of thinking habit, points not clear what to do now, which is likely to support future or changes.
Don’t try and mistake when you have a problem
This is also a common problem for beginners. A lot of times new people will encounter problems, can not solve, go to an experienced engineer, the experienced engineer, probably has not encountered this situation, but he has a clear idea to solve the problem. You try this, you delete that code, and you’re through. Problem solving is a very basic technical point, and there are many methodologies, I summarized some before, briefly listed here:
1. Find the correct code 2. Figure out the correct execution order 3. Minimize error scenarios 5. Modify code to a known error type, etc.
Problem solving is a process of analysis and reasoning, and here, the foundation behind is that you know a lot of small axioms which are sure to be wrong, and then to locate the link that may cause error one by one, decomposition process is the most basic work. Advanced development debugging problems, often as follows:
13. Can’t write pseudocode
What is the pseudocode? It’s natural language. In fact, there are only three logic control blocks in programming: sequence, loop, and judgment. So if you just use natural language to describe what to do first, what to do next, when to loop, when to judge, it’s not a problem to write code. This is a process of writing the pseudo-code first and writing the details later. You don’t come up and start tiling code.
Tiling code is the worst way to do it. Good code is structured and has different levels of abstraction.
Step one, what. Step two, what. Step three, what. So just to make this clear, this is the first level of pseudocode. And then it becomes a comment, which is level two. Delete the comment and change it to the function name. That’s level three.
So the best programmers write code that doesn’t require comments, not to delete them, but to go through the three-step process of sublimation. ** write good code, naming norms, you see really is a poem, is a programming language, is in the language to describe the completion of a function, this kind of programming art industrial sense is very refreshing, you see those unhappy code, it is. One pit at a time:
14. Do not estimate the amount of data
It is often a good habit for back-end engineers to ignore the size of data in the early stages. Writing code is all about functionality, without a concept of data volume. This is actually consistent with performance, in terms of performance, there is not much difference between the front end and the back end. Recommended practice is that the programmer is very sensitive to the data, the back-end to know what might be the size of each table, the current system can support the size of the database table is how old, while the front and back side need to know the each operation, which are divided into several steps, each step how much is the amount of time, what about the memory. It’s easy to do this, but it’s hard to get into the habit of seeing functionality and code as a junior engineer and data and time as a junior engineer. There’s no estimate, and then there’s a fire, and it goes something like this:
