How to become a professional programmer-three years of programmer's career

I have been working for three years without knowing it. I have reviewed my three-year career as a programmer and summarized some things, hoping to help xdjm who want to work as a programmer.
From programmers to professional programmers:

1. Simplicity is beautiful
Good code must be the simplest. It should be a constant rumor for every professional programmer. There are more than a dozen implementations of a simple "Hello World", but professional programmers will never be unconventional. They will choose the simplest and most commonly used one.
Why do we need to write simple programs? 1. Simple programs are easy to expand; 2. Simple programs are easy to maintain; 3. Simple programs are easy to discover problems ...... There are too many reasons to write simple programs. If you can use 10 rows, do not write 100 rows. If you can use arrays, do not use AVL trees .....
In short, the simpler the program, the better it can be.

Ii. strictly abide by programming specifications
Programmers will get a company's programming specification when they get started. Although each company's programming specifications are different, they basically talk about typographical formats, annotations, naming conventions, testability, and syntax specifications. Programming norms are lessons learned by our predecessors. Every professional programmer should strictly abide by them. At the project level, the programming specification is the agreement that project members should abide by, so that the project code can have a uniform style and try their best to constrain the individual style, avoid 11 styles for 10 projects.
Strictly abide by programming specifications and avoid some low-level errors. For example, if one of the programming specifications is used, the constant should be placed on the left side of the double equal sign and the variable should be placed on the right side. Compliance with this specification can avoid the so-called "One difference", that is, to write an equal sign as an equal sign. In this case, the compiler reports an error.
The code written by professional programmers should be of the same style. Such code is easy to maintain, so it is easy for other programmers to read and avoid some low-level errors. Therefore, strict compliance with programming specifications is an important embodiment of the professionalism of programmers.

Iii. Code Quality Attributes
There are three main attributes of code quality: functionality, scalability, and performance. Function: it is the most basic requirement for a program. The program must first correctly implement the expected functions to discuss other quality attributes. Scalability: for a software that requires long-term maintenance in a large scale, the program will not stop adding new features. If the program has poor scalability, it will lead to frequent restructuring of the system and waste a lot of manpower and material resources. Scalability should be taken into account in the design phase of the program. Of course, no one can take into account all the scalability at the beginning of the design, but we must consider it as much as possible. This involves the design method and theory. We will not discuss it here. Performance: good programs should consider performance. However, this is due to application scenarios. For example, for a simple calculator program, we do not need to spend too much energy to improve its performance. However, for a large platform system (such as telecommunications software, operating systems, and database systems), we have to focus on performance issues.
The priority of the three quality attributes should be: Correct functions> good scalability> high performance.
Generally, some quality attributes are in conflict. Sometimes, when performance is taken into consideration, the scalability of the program will deteriorate. If the scalability is good, the performance will be affected. Generally, the quality attribute is balanced based on the above priority.

4. Review your code frequently
Programmers are very proud. They often have confidence in the code they write, so that they are no longer willing to take a look after writing it. However, it is both a good guy and cannot guarantee zero defects in the code. A professional programmer should regularly review his own code and constantly discover bugs in his own code.

5. professional programmers must be excellent testers
I have seen several changes in the relationship between developers and testers in my company over the past few years. When I first joined the company, the number of detected problems was the only criterion for testing staff performance evaluation. Some departments even issued a daily number of indicators for testing staff, which directly affected the year-end award. Testers and developers are overwhelmed by the need to compete for a ticket. A year later, the situation has changed, and the tester is no longer the only problem. Now, the company has strongly promoted the integration of development and testing. Developers and testers conduct joint performance appraisal based on version stability and legacy defect density. The Office Area of developers and testers has been fully integrated. Testers often train developers to test methods and take the initiative to test and discover problems.
I am talking about my own experiences. I just want to explain the fact that there is no insurmountable difference between development and testing.
Many developers despise testing and think it is not technically competent. In fact, testers consider the problem from the customer's perspective. They can often consider scenarios that many developers cannot consider. There is a set of well-developed theories for testing. If the R & D personnel can understand some testing methods and theories, it will be of great help to the software design.
Professional programmers must be excellent testers.

Vi. design height Encoding
It is a bit abstract to stand on the design height code, but it is indeed the most profound thing I have ever felt over the years. Software development is generally divided into three stages: design, coding, and testing. Many people think that design is the work of designers and architects, testing is the work of testers, and the work of programmers is coding. Therefore, many students devoted to becoming professional programmers put all their energy into learning programming languages. Programming Language is just a tool. Learning well only means that you have learned to use a tool. For example, it is not very appropriate for a painter to use a paint brush in optics, and there must be artistic inspiration. Learning to code only means that you will use a paint brush, but it is far from the painter.
There is a very famous paper called "source code is a design" (http://www.feifanbbs.com/frame.php? Frameon = Yes & Referer = http % 3A // www.feifanbbs.com. Architects will output design documents in the design phase, but for the software, the source code is the most direct engineering document. A good source code is better than a thousand engineering documents-this is also the idea of agile development. A good source code must have been designed. The architect designs it from the perspective of architecture, but it is difficult for him to consider code-level issues. Finally, the implementation of Code depends on programmers. From a process to a function, these are designed by actual programmers. Programmers should also learn to design and understand some design patterns and theories.
Be a designer, not a code worker.

The above are my opinions and I hope to share them with you.

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/j00105840/archive/2010/08/22/5829843.aspx