How to become an excellent programmer?
1) Learning should start from the basis, do not try the highest and deep technologies at first.
2) Every time I see a book, don't say this chapter I have learned before, and I have a very good, so I can skip this chapter to see more important.
3) For homework, try not to ask others immediately. If you can't solve the problem, you can complete you first, then take some special difficulties, ask your master.
3) Don't expect books and hipsters to help you solve all problems, because you don't have all questions to teach you.
4) Ask others, you should understand the problem. For error prompt information, it should be supplied, do not provide information on your understanding. Because since you can't do it yourself, you understand that you understand problems.
5) Ask questions, it is best to bring code.
6) Don't say "Compilation, but run ...", because compiling errors and run errors may have no relationships. In general, compilation is grammar issues, while running is a logic problem.
7) The book is not as good as the program, and should try to write the program as much as possible.
8) Do a thousand programs that are worse than doing the program. Should try to perfect the procedures you do now, not to open a new plan, and each plan is tiger head snake.
9) To think of you are not a man writing, but write a program with everyone.
10) Although a deep skill showed a deep skill, it is often harmful to cooperation, it should try to write a simple and easy-to-read code.
11) The program should try as much as possible, that is, the code itself understands, as if you have the same logic.
12) Complex code If you don't do your own comment, you should give an appropriate amount of annotations.
13) Note Should be modified accordingly when modifying the code, and cannot mislead others with old comments.
14) The code should try to be reused. The same function should be done by the same function, and the important function should give debug information to debug the problem early.
15) You should try to write a small function, and each function should not exceed 40 rows or less. This allows you to read a full function without scrolling the screen.
16) For Switch statements, try not to have too much branch, if the branch is too much, you can consider using a jump table.
17) Try to use some controversial statements, such as goto and three-mean operators, since it has a dispute, it must have some shortcomings.
18) For GOTO, many engineers can be used reasonably, not to cause problems. But your program does not necessarily give you the same level, you can't guarantee reasonable read and modify these related code.
19) When the code is written, there should be a certain format, and the basic requirement is to help understand the code.
20) If the data is common, a package should be provided to manage it and provide a suitable interface to each module. In this way, if the data content has major modifications, only the interface is not changed, it can guarantee that the program should not be complicated.
21) The concurrency control of the data should be taken into account.
22) The concurrent control of the data should be encapsulated instead of exposure to other modules, which can reduce the procedure of the program caused by concurrent causes.
23) The structure of the data cannot be too complicated. It should be divided into two groups of data as much as possible.
24) The database should be considered for the case where the amount of data is relatively large.
25) The database interface should use a standard ODBC or ADO interface, try not to process according to the interface provided by the actual database DBMS because you may replace DBMS in actual use.
26) Small data can consider files, file paths should have to be designed to be relative paths. 27) In a function, you should try it immediately after using the file immediately after use, so other programs may use the file.
28) Don't try to read all the files all over the memory, you should handle the big file.
29) Write programs should provide relevant test procedures to provide test methods.
30) Should consider the code, the usage of functions, do not exceed the range of functions that can be used.
-------------------------------------------------- ------------------------------
1. Sound foundation. Data structure, discrete mathematics, compilation principle, these are the foundation of all computer science, if you don't master them, it is difficult to write high levels. According to my observation, people who learn computer majors can more written high quality software than others. The program will write, but when you find that it is difficult to write a certain degree, it should think about whether it is to go back to learn these most basic theories. Don't go to learn OOP at the beginning, even if you are fine, you may have no hand when you encounter some basic algorithms.
2. Rich imagination. Don't stick to a fixed thinking method. When you encounter problems, you should think about several solutions to solve the problem, try the way others have never thought about. Rich imagination is based on rich knowledge, except for computers, more about other disciplines, such as astronomy, physics, mathematics, etc. In addition, it is also a good way to see more sci-fi movies.
3. The simplest is the best. This may be a criterion following all sciences. Such complex quality interchange principles are just a simple formula that is simple in Einstein: E = MC2. A simple approach is easier to be understood, more easily implemented, and more easily maintained. When you encounter problems, you should give priority to the easiest solution, and only the simple solution cannot meet the requirements.
4. Do not drill the horn. When you encounter obstacles, you may wish to stay away from the computer, look at the scenery outside the window, listen to light music, chat with friends. When I encounter a problem, I will play games, and it is the kind of violent fighting game. When the part of the brain cells responsible for the game, the part of the brain cells responsible for programming have been fully resting. When I started working, I will find that the problem is now able to solve it.
5. The desire for the answer. The history of human nature science is a process of eager to get the answer, even if you can only know a small part of the answer, we pay for us. As long as you firmly believe, you must find the answer to the question, you will pay energy to explore, even if you don't get answers, you will learn a lot during the process.
6. More than others. Three people must have my teacher, maybe in a conversation with others, you can explore the inspirational spark. Many up-to-go, see what others' views on the same issue will give you a lot of inspiration.
7. Good programming style. Pay attention to develop a good habit, the indential arrangement of the code, the naming rules of the variable should always be consistent. Everyone knows how to exclude the error in the code, but often ignore the missed troubleshooting. Note is an important part of the program, which makes your code easier to understand, and if the code has clearly expressed your thoughts, you don't have to add any comments. If the comments and code are inconsistent, it is even worse.
8. Toughness and perseverance. This may be the "master" and general programmers the biggest difference. A Good Programmingis 99 Weat and 1 ffee. Masters are not genius, they are hone in countless daysday night. Success can bring us extremely joy, but the process is incomparably boring. You may wish to do a test, find a number of items within 10,000, copy them all, then check three times, if you can complete this work, you can meet this. * Amaze of knowledge, and you can add your own knowledge and improve your knowledge structure.
* Patience, especially in debugging and learning, there is no smart person in the world. Doing development, in fact, learning and improving the two things, the development process in the middle of these two things is actually relatively simple
* Always remember: The code is given to people instead of running the machine, the computer is not afraid of being tired when executing the program, and people are very tired when they look at the code.
* Good coding habits, at least guarantees yourself to read the code you wrote before you can read more time
* Try to make your code can be easily understood by others, think about it when you write the code, you will not be embarrassed by others after two months.
* Do not tolerate your own repetitive errors and write duplicate code
* Know how to do more important than getting code
* Try not to do something that has already been done
* Learn to respect the achievements of others, unless you have to decide to fully replace the previous system
* Cherish your time and work results, try to make others share your development results
* Avoid assumptions, think more about the possibility of extreme conditions and cause errors, and strive to reduce low-level errors
* Don't believe that at least don't believe in the test results you do for yourself.
* Know your own development ideas and know how to understand and absorb others' thoughts
* Learn to be consistent with others, but you can't give up your development characteristics
* Know the people around you, whether it is developing skills or development experience
* Understand the importance of software structure, analyze the structure of code before analyzing the code
* Summary, regularly summarize the knowledge you have learned, see the time for the past due to various reasons
* Society plan, try not to think of the task by extending their work hours
* Learn to properly estimate your ability and working hours
Here, this is what I think some is suitable for my own, not necessarily for everyone:
* Take more magazines, you can see the reference book you have seen before, you are likely to have some details you haven't noticed before.
* Don't be too early to do something unrelated to the development, because the golden period of learning is very short
* Learn to analyze the system of others, see the advanced side of the system developed by others. Here, this includes the development of others, the structure used in realization
* I often feel that I will be eliminated, I often complain myself.
* Know what you lack
* Forced things you don't like to do, such as writing documents
* Can have courage to rewrite the system you develop, but when you react, you should take and learn the next way and method, otherwise it will not be necessary.
* Simplify the problem rather than complication
* Some issues that will be generated during maintenance is transferred to development or when designing
* Sometimes you may wish to ask yourself: What do I do when I don't do it?
* Adhere to your weekly development plan, don't easily transfer your attention before things
* As much as possible to teach you to others, because you may no longer be responsible for this system one day.
* Doing things must have end, unless there is no reason to leave, do not leave before work
* Don't take your own things to the company, you should take away the development experience and the understanding of development rather than code and products.
* Take a break at all, give yourself a false, after all, people are not machine
