Software-after the project goes live

It took about three months from development to release. In fact, most of the functions were implemented in the first month. In the next two months, the bug was confirmed and modified as required, do other things interspersed during this period. In general, it was quite smooth. Without getting stuck, there was no "sudden rise in brain CPU usage", but there were too many flaws. Let's make a simple record here.

A brief introduction to our combat methods. The page is cut by a dedicated person, and only part of the page is made. You can solve the style problem by yourself. One Product Manager and twoProgramPersonnel, all the requirements are asked to the product manager, basically in addition to page cutting, the other is done by our program. This is a company's internal project management software (website) Revision and upgrade. For me, it is basically a new system, because the previous implementation method is not good, I changed the implementation method and rewritten the 91.1%Code.

 

Insufficient understanding of requirements. The requirement comes from two aspects: Product Manager and existing code. The product manager first gave me a rough introduction and then looked at the existing code. The two combined to get their own ideas, so they started development and asked the product manager any time when there was a problem. Too many of your own ideas were added at the beginning, leading to some deviations in understanding requirements, resulting in some unnecessary modifications in the future. Modifications are the destruction of the original code, the code that was originally well-written has been modified a little bit, because we don't always care about small changes, and the code gradually becomes hard to understand. In the future, we will feel unfamiliar with some code, how can I write such code. Although the requirements have been confirmed multiple times during development, some of them are ignored. It takes too little time to understand the need for digestion, resulting in a series of deteriorating responses in the future. The code is hard to understand. Before the change, it is the denial and self-denial of you by others. because you understand the wrong requirements, the current implementation method is the result of your understanding of the requirements, it is painful to destroy your own code, especially the code that you think is well written, and it is a waste of time. In a word: the most dangerous bug is introduced during demand research.

 

It will be paid back sooner or later.. Do not be lucky to think that this will not happen. Users cannot do this, but you must know that some testers are "abnormal" and users are also very lazy, some abnormal operations of the tester will be deeply embedded into your mind, so you will also make exceptions during the test because your program crashes. Okay, you finally realized that this was a problem, so you started your code modification journey again, maybe it was a happy journey, it is more likely to be painful, boring, and meaningless self-criticism. Maybe you still ignore the abnormal nature of the tester. If you are lucky, this problem will not occur until you encounter a user with the same abnormal nature. The gate of hell suddenly opens to you and you begin to admit that you are wrong, you should admit the mistake. In development, most of the places that I think may be wrong have been discovered by the testers. If they are not found, I have changed them silently, because I believe that mixing will change sooner or later.

 

Success or failure. Programmers have made their own software and are the ones who know the best about their work. If we destroy our software like testers, we may find problems that testers cannot find, similarly, the fewer bugs found by testers, and the more clean your bug list. In this development process, the fewer bugs are tested by yourself, and at least 150 bugs are modified before and after. I also understand that others are boring when they discover so many mistakes. The more problems you discover, the less time it takes to talk to others. Efficiency has always been my pursuit, it is also because of the many bugs that have been pursuing development efficiency.

 

A bit of Jobs' spirit is required to pursue perfection.. Because we are programmers, we are people with ideas and opinions. We can't let others do what we do. It's so boring that we have to fight back after being denied for a long time. The demand may not be very reasonable. How can we give a more reasonable and perfect implementation? If the tone of the page is not properly matched, we should boldly question and give our own solutions, do you think it is nice to deny others' solutions to give your own better solutions? software is the work of our programmers. It should have our ideas and our design philosophy, software should not only be executed and implemented for us. We must fight a pretty counterattack, counterattack design, counterattack testing, and counterattack product manager. Only by improving yourself can we make better software. Software makes our children have to have our DNA. We should make them smarter than their children after birth, until one day you calmly tell others: this is my excellent breed.

 

How far is the heart, how far is the mind, and the software is still thinking ......

Software-write niub's code

Software (I)

 

Author:Chen taihan

Blog:Http://www.cnblogs.com/hlxs/