Programmer's belief

My wife often praises me for my thoughts. Thanks to the encouragement of my wife, I plan to write down what I think and summarize. People need to constantly summarize and make progress only when there is a summary. The so-called conclusion is not necessarily a profound truth, but also a complicated inference. Sometimes, a sentence or an instant can help you understand a lot.

First of all, strictly speaking, I am not a programmer. I am engaged in testing and development, but I have been engaged in various types of developers.

Some people take code as fun, as long as they make it easier to write code.

Some people simply regard code as a task to support their families.

Some people treat the code as a pet and take care of it without any flaws.

Some people regard the code as a tool, as long as they can use it, to manage its scalability and maintainability.

Some people will say that I did a unit test and did not find any problems. If you find a bug, you must sue me.

Some people will say that this code is okay. It has been running for two years and there is no need to test it.

......

Recently, I have been reading "the main path on Earth is vicissitudes of life" every day. I am very impressed with the saying "there are two types of dreams in this world. First, I have realized my dream. Second, the dream is realized because of me, even if my own life is lost ." Therefore, I thought of the word "faith", and then suddenly thought, should programmers also have their own beliefs? Every day, various programmers are tapping on various types of code. Is there any belief that all programmers can be pulled together.

First, ask yourself if you really like to write code. If not, I suggest you change your job.

If you like writing code very much, I will ask again:

Where do you think is the pleasure of writing code?

To be honest, I was asked this question. First of all, this is actually a very good question for programmers to analyze themselves. At the same time, this question is very difficult to answer. It's like asking why you love someone. In October, there is no reason for someone to answer this question. Indeed, love is love, not love is not love, if you have to say that you like to write code for reasons, I think it should be like the beautiful code melody in the hand, the key is like flying feeling, with limited keyboard keys, you can break out endless beautiful music.

Sometimes thinking, extreme thinking is not necessarily a bad thing. People who believe in Agile development are somewhat excited. For example, some people in the blog park just discussed the question that a standing meeting in the morning must be standing. No function can have more than 10 rows. In one test case, only one assertion check can be performed. Under the extreme of reason, it is often able to stimulate people's potential. Under reasonable circumstances, I think it is necessary to form some almost extreme programmer beliefs.

Here, I am opening up and listing several Proverbs. I hope you can add them together. See how many items can be listed.

1. unit testing is required for your code

Both product code and test code must write unit test cases. It is unnecessary to perform unit tests on product code. Unit Tests on test code are also very important! There are problems with the test code itself. Where can we start with the test results of the tested code.

2. Do not leave dog food to others

Do not leave a lot of code that is complicated, confusing, hard to understand, and cannot be maintained to others. You need to think about how to give your code to others for some praise.

3. Avoid over-design, simplicity, and scalability

The code is not written to machines, nor to show off your complicated design. It is very important to keep it simple, easy to understand, and maintain its scalability.

4. Carefully name every file, function, and variable in the code

To get the respect of others, you must carefully consider the naming of each variable, use a unified naming convention, and use a naming method that is easy to understand without ambiguity. Some people are too casual to open Kingsoft, regardless of sanqi 21, and use Chinese words as soon as they are translated. Some people are named again in pinyin and English, and are case-insensitive. The abbreviations and full names are different.

5. Don't be so easy to persuade, and argue for it.

In particular, do not be confused when facing superiors. First, you must fully understand others' ideas, and then express your opinions clearly. Some people can especially say that they are good at serving people. Never get dizzy and point it to the top.

6. Handle your program dependencies

It is difficult to maintain and expand a system with chaotic dependencies or circular dependencies. So when you are designing a series of public libraries, think about the dependencies between them. This is a basic principle and cannot be violated.

7. Do not use ugly implementation because of troubles.

 

Author: coderzh (coderzh's technology blog-Blog)
Source: http://coderzh.cnblogs.com/
The copyright of this article is owned by me. You are welcome to repost it. However, you must keep this statement without the author's consent and provide a clear link to the original article on the article page. Otherwise, you will be entitled to pursue legal liability.