For a software engineer, work may mean many things-a stable income, doing projects that interest you, a springboard to find a better job, or you just like to work with other programmers. But when it comes to "efficiency", the emphasis is on the ability to complete the project with quality within a certain period of time. Based on his own experience, Phil Chu proposed seven habits that highly effective programmers should develop.
1. Understand your requirements
to become an efficient programmer must first know how to properly spend their time. The biggest waste of time is to do projects that are useless or will never go online. The root cause of this result is often a deviation in the understanding of requirements.
To avoid this situation to the greatest extent, the best way is to model quickly and let the demonstration system come out as early as possible. For customers, only when the tangible products are in front of them, will they be interested in trial and observation, and will find the deviation of the demand understanding between the supplier and the demander in the actual operation. Otherwise, even if you write hundreds of pages of requirements analysis documents, it can only be your own words, and the customer may not have the patience to check whether these documents are accurate.
On the other hand, you should enable the development results of each stage to be submitted to the customer as soon as possible. Let them discover the inherent thinking limitations of programmers programming with fool-level operations that completely ignore the rationality of operation and business logic. In particular, QA must be involved in project development as soon as possible. If you can submit a test version to QA every day, it is naturally the most ideal, but most project development can not achieve this granularity, then strive to submit a testable version every week. The important thing is to keep QA and development in a staggered parallel state. Only in this way can QA find bugs as early as possible, reduce the cost of fixing each bug, and reduce the span of independent testing cycles.
Programmers are often unwilling to deliver semi-finished code to testers. On the contrary, they prefer to let others test after all the code is completed and reach their satisfaction. Because the code before this often has many process missing and bugs that programmers know that they need to be modified (or deliberately left for follow-up completion), testers do not know which are real bugs and which are only temporary operating errors. They will give feedback to the programmer as a bug. This often annoys programmers. At the same time, testers sometimes don't like to test such intermediate versions that many branches do not work.
But whether you like it or not, it is the tester's job to test and discover problems; programmers should realize that the earlier bug feedback is, the better. The relationship between QA and development is often very hostile, but in fact the goals of both parties are the same. There is an old saying about "faithfulness against ears", and for programmers, they should "change it if they have it, and encourage them if they don't." It's better than discovering a bunch of problems after the project is completed. If you want to make changes at that time, you will basically affect your whole body. The pain is the programmer himself.
2. Keep authenticity
as possible to make your system run the following configuration closest to the real environment, the use of meaningful data and the real compiler version, and perform regular module integration. If the data used in your test environment is random additions, the big iceberg of real data that will be very different from the test data will sooner or later crash your program. On the other hand, if you only compile and run the test in the development environment, you will find various inexplicable problems after the official release. In the end, it turns out that the environment configuration and the development environment are somewhat inconspicuous. The integration of all modules for compilation and joint debugging seems to be the last additional work, but in fact this is a work that needs to be done frequently during the development process. Only in this way can QA have the most complete things to test, get more bug feedback, and reduce the difficulty of module integration.
3. Understand your code
writing specifications of the code, and keep clean code. Coding is an art. Just like writing, the same words can be shining in the writings of writers, and they are pleasing to the eyes; in ordinary people's writings, it is probably only the effect of words to express the meaning; in some people's writings, it may take a long time to guess. It's probably coming. Of course it is impossible for everyone to become an artist, but at least you can learn to appreciate art and learn art. Writing beautiful code is a respect for your own work, as well as respect for other programmers. If your code is full of outdated comments and poorly readable variables/functions, how do you ask others or yourself to understand them in the future?
4. optimal programming
to spend your time on the functionality of the code, rather than the existing code was changed (especially for those who copy / paste the code over) for their appetite; to find the bottleneck of the system is optimized, and It is not to do useless work on those areas that are not conducive to improving the overall system.
5. Manage yourself
Some people may say that planning and schedule control are PM's matters, but a good programmer should know the progress of his current work better than PM. Regardless of whether the schedule given above is reasonable or not, you should have your own principles and concepts, and know exactly what to do every day.
6. Continuing education
Only by constantly learning, practicing, and making mistakes can you truly improve. In my opinion, the best teacher for programmers is not in school, but in books, networks, and communities. Learn to learn by yourself to keep up with the times.
7. RESPECT
mutual respect is the foundation of everything.
This article is from the CSDN blog, please indicate the source for reprinting: http://blog.csdn.net/armos/archive/2007/10/30/1856154.aspx