How do rookie programmers write code?

This article is reproduced from the programmer programming community

Every programmer has to go through this stage of "caiji", then, in the caiji stage, how do programmers write code? In the following 12 moments, can you find your original shadow?

image

01 Irregular naming

Many programmers may have this experience. When writing code, they have a glimpse. In order to ensure that more code is typed before the inspiration fades, the code type is fast, and of course the naming seems very random.

There are all kinds of weird names: xiaonaigou, ergouzi, xxxx, j1, llst, etc. You may not even know what the hell are these names afterwards.

02 Irregular logs

Some students may ask: log? What is it, can it be eaten?

Many students will ignore the importance of logs. When reporting an error, they choose to modify the code locally and then deploy directly, but when a problem arises and don't know how to solve it, they will be confused when they come to it.

03 Don't write unit tests

To be precise, it is not developed in the way of TDD.

In the current situation of such a powerful IDE, the habit of writing unit tests first can not only make the code more rigorous, but also greatly improve efficiency.

However, many rookies can't understand the value of unit testing. They will not cry until the code is refactored and the requirements change!

04 Integrate first, then test, then give up

In many cases, when Caiji introduces third-party libraries, frameworks, interfaces or services, what it likes most is to integrate directly with its original code. As a result, he couldn't run anymore, and the biggest breakdown was that he didn't know where the problem was.

Experienced programmers will first run through the official Demo, and then think of ways to add their own business bit by bit.

05 Didn't clarify the logic, just guess while doing it

Front-end Caiji has a lot of problems here. When doing payment, I don't know the payment process and the definition is not clear. I always think that the front-end is to deal with excuses and data display.

Handle the logic first, figure out the process, and then do it.

06 Don’t make a plan, just do it

Not making a plan means doing things based on feelings, and the best habit when writing code is to first go through all the requirements details in your head and take out the implementation details.

07 Don't care about performance

This is a very easy mistake for newbies, what is performance? For the back end, it is TPS and response time, and for the front end, it is response time.

The habit of many newbies is to make things and then optimize them. But often things are made, optimization is left to others.

The focus on performance is also the most critical skill point for the promotion of intermediate programmers. When writing code, experienced engineers will know the performance of this method, this function, and the bottleneck.

08 Fear of refactoring

"A programmer's greatest courage is to look at the code he wrote three months ago." This sentence is not false. In fact, refactoring should not be done after a few months. The best way is to refactor in real time.

09 Just do it, not best practice

Many Caiji projects are mostly hard-coded and have no scalability, and they complete their functions in a very ugly way.

10 Do not consider future changes in demand

The level of engineers can actually be divided into the following stages:

Function-oriented programming

Performance-oriented programming

Programming for the future

The first thing an engineer needs to get it should focus on the following questions:

First, which requirements I have completed before;

Second, what needs are likely to change;

Third, there are several solutions to support what kind of demand changes.

However, Caiji will never consider so much. First, because they are not familiar with the business, they can’t judge which needs may change; second, they don’t know much about the options, and there is no room for options at all. ; The third is that there is no such habit of thinking, and it is not clear what is to be completed now, and which may be supported or changed in the future.

11 No trial and error when encountering problems

This is also a common problem for novices. Many times newcomers will encounter problems and can’t solve them, so they go to an experienced engineer. Although this experienced engineer has never encountered such a situation, he still has ideas to solve the problem, and it will pass through trial and error quickly. Up.

In fact, problem solving is a process of analysis and reasoning. The solution to the problem should be:

1. Find the correct code;

2. Clear the correct order of execution;

3. Reproduce the error;

4. Minimize scenarios where errors occur;

5. Modify the code to a known error type and so on.

12 Do not estimate the amount of data

Back-end engineers often ignore the amount of data in the early stage and fail to form a good habit. Writing code only pays attention to the function, there is no concept about the amount of data.

It is better for programmers to be very sensitive to data. The backend needs to know how large each table might be, and the size of the database table that the current system can support. The front and back ends need to know every operation. , Which steps are divided into, how much time each step takes, and roughly what kind of memory it takes up.

It is not difficult to do this. The difficult thing is to develop this habit. The junior engineer sees the function and code, and the intermediate engineer sees the data and time.

How many of the above have you ever scored?

Guess you like

Origin blog.csdn.net/m0_46163918/article/details/115239483
Recommended