Shulou(Shulou.com)06/03 Report--

Most developers just want to write new features, and they don't want to use maintenance and bug fixes. This is also the fun and benefit that most developers miss is discovering and fixing bug.

Every mistake can teach you something.

Feedback is a key and one of the main principles of agile development. Unit testing and iterative hair techniques provide feedback more quickly. Get feedback on whether your code works with the unit test, and you can listen to what customers think of as new features for each delivery. Error reporting is another form of feedback on your code. There can be many different reasons for a mistake. Some possibilities are: a simple coding error (such as a nested if statement where you end up in the wrong branch), or an erroneous assumption that you (maybe the incoming message doesn't always have some fields, so you have a null pointer exception), or a missing request (you should answer the message in a different way if a given parameter exists). Or the customer uses the software in an unexpected (but correct), resulting in an error.

In these cases, you can learn how to code, it is about the role of your product or system. For example, when I was developing a product at Tilgin VoIP, there was a situation where we received an error message that caused our software to cycle. The element contained in the message uses the tag-length-value encoded (solenoid) parameter, the length value of the total length of the element. This allows you to skip the number of bytes of unused or unknown elements that jump "length" forward. In this case, the length value is zero, so skip that we point to the same element and point out that it causes an infinite loop before the jump. Before this bug, double-check that my code length value is too large will result in reading past message buffers. Before that, however, it never occurred to me that a zero length could be just as bad.

Your own code becomes easier to debug.

When you take the time to break down problems and fix bug, it won't take long until you want to make your code as easy to debug as possible. It is frustrating that not all the information is available. A very common problem is exceptions that do not include dynamic information. For example, suppose you have code with expected values in the range of 0-20. How many times have you seen an anomaly and just said "illegal value"? I won't tell you if you want to find a bug. If you receive it on the 21st, for example, you should say "illegal value: 21 is not in the range of 0-20". It helps to include the allowable range and certainly helps to include the current value. The current value may be 21 or-128 or 65535. All of this may give you a clue as to what caused it, and you are not from an ordinary "illegal value". Even Steve McConnell breaks this rule in some places where the excellent work of code is done. For example, in Chapter 15, there is an example of an unexpected discovery of a type of character, but the error message does not include the character. Every time you find and fix a bug, you need to ask yourself: what should I do differently in my code to eliminate errors and avoid making mistakes again in the future? Is there anything I should do to make this mistake easier to avoid in the future?

You and the client will be happy.

As I mentioned, one of the joys of coding and programming is to do things that are useful to others. You get the same kick to fix a defect, but on a different time scale. It usually takes a while to provide new functionality, but an bug fix can be done in less than an hour. Every fixed mistake makes you feel like you're accomplishing something, which is a great feeling. Paradoxically, fixing a defect will satisfy the customer. If there is no mistake, first of all, there will be no need to fix it, then why should they be happy? However, my experience is that they are happy to accept a bug fix, especially if it is resolved quickly. Everyone knows that there are always flaws. The important thing is that someone is ready to fix them when they are soon discovered.

It is interesting to solve the problem.

Many programmers like to solve problems, such as math puzzles, programming challenges, Sudoku or crossword puzzles. Even murder mystery feed interpretation: you look at the clue, try to find out what happened and laugh. Debugging and repairing bug are the same. Every mistake is a new puzzle to find out. Often when you see a new error report, your first reaction is: is this impossible? How could that be? This is when you start looking for clues. What does the journal say? From the system error report? What happens in the system at this time? Any recent changes-new software, configuration changes, traffic disturbances? Let's find out and start! These are four reasons why I like to debug and fix too many bugs. What is your experience?

Postscript: Yue Xiaosheng believes that the correct strategy is to test more every time you write a short piece of code and eliminate bug before integration. The more you detect bug in the early stage, the easier it is to find bug. Moreover, if you call a module without bug later, the team will be much more efficient. But there will always be bug and there will always be bread.

Http://java-er.com/blog/4-bug-good/

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.