11 words for programmers to understand

1. Technology is just a problem-solving choice, not the root of the problem

We can be thrilled to have mastered the latest JavaScript frameworks ahem, angular's IOC container technology, or some programming languages and even operating systems, but these things are not the root of what we use as programmers to solve problems- They are just simple tools to help us solve problems.

We have to be very careful not to be obsessed with a particular technology that is just like or just right. Otherwise, we will enter such a circle of thinking: The mastery of the technology is a hammer, when thinking about problems, will naturally think of all the problems are the hammer can solve the nail.

2. Smart is an enemy of clear code

When writing code, we should strive to make the code clear and easy to understand.

Although this sentence is not always correct, but in general, Smart is indeed the code clear enemy.

It turns out that when we write a piece of code that we think is very great, the code may be confused in the eyes of others.

So it is necessary to keep this principle in mind when you are writing a piece of smart and efficient code.

If you are interested in how to write clean and clear code, I highly recommend you to see Robert · C Martin's book, the clean coder:a Code of conduct for Professional programmers.

3. Write as little code as possible

There seems to be some contradiction in the sentence. Isn't the programmer's job to write code?

Well, yes, but it's not.

Our work requires us to write code, but we should try to write less code when trying to solve the problem.

This does not mean that we need to try to make the code more compact or to use a single letter for all variables. What it means is that we should try to use a more streamlined algorithm to implement the functionality we need to implement.

In general, the various cool features we add to our code are very tempting, which also makes our code look more "robust" and "flexible" and able to handle a variety of different types of situations. However, in more cases, it is wrong to try more features that may be useful or to prevent problems that may exist in the future. These extra code may not have any value, but it can cause more damage. Because the more code, the more chances of an unknown error, the more troublesome the maintenance of the code.

Excellent software engineers write as little code as possible.

Great software engineer to remove as much code as possible.

4. Comments are the last choice of code formulation

Bob Martin once said: "When you write a comment for a piece of code, you should reflect on your poor expressive power." ”

This does not mean that we should not write comments in the future. But in most cases this situation can be avoided, and you can choose to replace it with a better naming method.

A comment is the final choice only if the use of a name cannot articulate the purpose of a method or variable. In fact, the expression of what is not easily expressed in code is the true function of annotations.

For example, annotations can tell you that the strange operation commands in the code are not an error, but intentional, because there is a bug in the underlying operating system.

Although in general, many annotations are very useful, there is a risk of misleading.

After other code updates, comments related to some pre-update code will often not get the same updates, resulting in some comments becoming very dangerous, and they are likely to lead you to the wrong direction.

Have you checked every comment that is closely related to your code? Are you sure the code is doing what the note says? If you have done this, then what is the meaning of the annotation? If you hadn't done that, how would you know that the comments were true?
Therefore, the role of annotations is not as good as it preaches, and it must not be abused.

5. Before you write your code, you should know what your code will do.

This seems to be taken for granted, but the reality is not.

How many times in a real job do you start programming without fully understanding what your code is going to do? It was countless for me anyway, so I used this record to remind me at any time.

The practice of test-driven development (TDD) is here to help you because you need to understand where the code will be used before writing the code, although it still doesn't prevent you from creating the wrong thing, but it's still very important. So when you're fully aware of the requirements and features that need to be built, try programming again.

6. Test yourself before submitting the completion code

Don't throw the code to QA after you've finished programming, and then wait for the message. This wastes the time of every person involved in dealing with unnecessary bugs and problems. You should take a few minutes to run the test scenario for self-testing before reporting the programming effort. Of course, you may not find every bug before you submit the code to QA, but at least you can eliminate some of the stupid, low-level mistakes that every one of us can make.

Many software developers think the test code is just the work of a QA staff. That's not right. It is the responsibility of each of us to keep quality.

7. Learn some new things every day

There is a famous saying, "Knives do not wear to rust, people do not learn to lag behind." "This is a very reasonable sentence, because whether or not to acquire new knowledge, you will forget some of the previous things every day."

It doesn't take you a lot of time to learn something new every day. Try to spend 15 minutes a day reading, and then you will find that every day you will have a little bit of progress, at some point in the future, you will find that this progress is huge. So, in order to get a great return in the future, you have to invest from now on. In addition, today's technology development is changing rapidly, if you do not improve your skills, learning new things, you will soon be flung off.

8. Writing code should be a pleasure

This is very true. Perhaps you have entered the industry simply because it has a decent salary. There's nothing wrong with choosing a lucrative job, but there are better options, like a doctor or a lawyer. In fact, a lot of people choose to do software development Another reason is that they like to write code. When you are tired of working under pressure, don't forget the original intention of choosing this job.

Writing code can be a lot of fun. For years, many people may have forgotten this, so from now on, back to the previous passion, from the side of the project, the idea of your ideas and consciousness into the past you began to learn the programming moment.

9. You don't need to know everything.

When you learn a lot of knowledge, you still have a lot of things do not know.

It's important to be aware of this because it can drive you to learn more and more things.

It doesn't matter if you don't know all the answers to your questions, and you don't understand what you're saying and asking for help. In many cases, you can choose to learn now-believe me, that's how I came along.
My point is, do not attempt to learn all the knowledge, because it is an impossible task to complete. What you need to focus on and master is the skills that will help you learn quickly.

10. Best practice depends on the environment

The best way to test-drive development is to write test code first?

Should we keep the habit of pairing programming?

Will the IOC container be inferior if not used?

The answer to all these questions is "look at the situation." "It depends on the actual environment in which it is located.

People try to transfer the best practices through the throat and so on to you, and they will tell you that they are usually used in this way. So you should do the same-that's not true.

In writing the code, I also borrowed a lot of other people's success experience. However, these references are conditional.

Knowledge is dead, man is alive. The best practice needs to depend on the environment.

11. Strive to simplify and simplify

All of the problems can be decomposed. And the most elegant solutions are usually very simple. But it's not easy to be simple, it takes a lot of work.

For example, the purpose of this article is to extract experience from complex software development work and daily life, and to present it to everyone in a more concise way through induction, which is not an easy task.

In solving the problem, you can first find a more complex stupid method. On this basis, efforts are made to refine and refine it so that it becomes simple on the right foundation. It takes a lot of time and effort, and it's not just the process that makes people smarter?

11 words for programmers to understand