Tips for solving bugs

I was in the answer to a reply: http://www.zhihu.com/question/27044029

I may not say debug, mainly in the production environment when the problem of error-checking.

first of all, the development of the time to be prepared.
including but not limited to:
keep a good record of the logs. Be sure to record the method's entry, parameter, and exception information.
prepare the tools for log download and analysis. If necessary, log splitting, parsing scripts to be able to write out.

the first two days on the line, no stop receiving error messages. And the errmsg sent in the mail is actually null.
at that time, the key to debug three steps, the first is the log download. Production environment has a relatively perfect log mechanism, I put the one hours before the error was stripped down. The second is the log analysis, compared to the log stream, found that the first line of the log after printing, line x+n is not printed. So it is clear that the problem is within the N line. Finally, we look at the parameters of the X-row record-the entry is a JavaBean, and all of the non-null data is recorded in the log. So it is clear to see "feeexp= none".
download from the log to find "None", no more than 10 minutes before and after.
then I let the system administrator modified the corresponding configuration data, did not verify the results to accompany the daughter-in-law to see the film.
No, then, until now, only one error message has been sent. Said back.

The production environment to check the wrong, good log is really the key. Once a copy of the 10g+ log, full article is "XX method start Execution" "XX Method execution Complete", what data are not, really have a knife cut people's heart.

small tip, when logging the Exception Log with log4j, be sure to use the overloaded method Logger.error ("error message in string", exception). This method will print out the exception's abnormal information stack. Although not very friendly, but Monkey brothers should know its convenience.

on this basis, if the system business, code flow familiar, can go a very big shortcut. Thanks to those who have designed the code structure well. In this way, when there is a problem, sometimes it is easy to lock the question into three or four lines of code, even without logging or reading the log.
I received another error message this morning. This time there is errmsg, is "Integer can not cast into Double."
because it is my own code, I am very familiar with the process, and I know that only one place may produce an integer strong double--although embarrassed to admit, but it is the development and testing is not considered completely caused. Then again to the administrator confirmed a configuration data, let her put a "5" changed to "5.00". And then, I'm going to write another code.

If the above steps are not able to detect and solve the problem, then you have to be able to reproduce the error.
at this time, the importance of a UAT environment is highlighted. In the home work, because it is to take over the other half of the system, many times there is no log can be checked (check will only have a knife to cut people's impulse). Therefore, most of the time when users report bugs, our first step is to try to reproduce them in the UAT environment. Uat on the log4j debug log (on the production of hard disk space and performance reasons, up to info, some even only error), useful information is always more than the production. and =. = Occasionally uat can not reproduce the problem, we will use this as an excuse to tell users can not change ...
UAT, INT, and finally to your own development environment to reproduce, and then modify.

If you're lucky, you'll see the exception stack information printed out when the error occurs during the replay. Due to the lack of a production environment so large system pressure, this time can be carefully and slowly to the Mei ... Chew on this information.
I used to think that the abnormal stack is so simple that I have to look for a chance to apologize to a colleague for a quick wink. = The ability to just try to clean up the stack (tech tree?) ), found that can easily read the stack information of the monkey, is definitely not a simple machine gun or large g. The first to understand English, or can use all kinds of dictionaries to understand the English, and then to understand the abnormal mechanism, from the pile of at ... and cause by ... Find the point that you need to pay attention to, or that you have the ability to pay attention to, and often have to understand some compile AH ClassLoader ah JVM AH server ah related things; good memory or bad writing is an advantage, because a lot of problems will recur In addition, if you can have a down-to-earth imagination to get extra bonus, because some of the abnormal information is really incredible.
The last time I went online, I met this incredible problem. Need to be on-line code in the INT environment ran very shunliu, on-line when reported a noclassdeffounderror. Well ... English is very understood, the class of no found is also very clear behind the error, but ... int really very shunliu ah ...

at this time, if the system business, code flow familiar, and can go a very big shortcut. Many times with colleagues to check the wrong, they have not read the log I guess the problem lies, basically because I took this shortcut.

In general, I check for bugs, basically relying on the information that the program leaves in the run. Most of the time I set the "Punch Machine", the program runs here to have to play a card. Some are system-provided help. Of course the performance of some space and time will be sacrificed. But for the time being, most are worth it. Moreover, these data can be used to do some performance analysis, even big data analysis.
with this information, coupled with their own system, code, most bugs can be quickly located, and finally resolved.

The first day of learning computer The teacher taught me, "software = data + process". I am now a little bit of a personal experience. The log records the dynamic data, and the code records the static flow. The two hands, the bug worry-free.

Debug This tool, I rarely use when tracing bugs in the production environment. Really, in most cases, the log + code is sufficient.
I only have to debug some complex algorithms during development, or when debugging large quantities of data. The complex algorithm is because my brain has low performance and I can't analyze the code flow. Large data volumes are not able to analyze the various data states. Luckily--or not--I haven't had much of a debug situation. Seriously debug the matter, should not do more than 10 times.

think, multithreading concurrency may be a bad thing to use the log + code to analyze. But...... I write multi-threaded ... Haven't checked the fault yet ...


haha a thick sense of superiority is not ... But seriously, the code is less out of production bug+ out bugs can be quickly solved and resolved, as a monkey I really have a sense of accomplishment

This article is from the "Programming Capricorn Man" blog, make sure to keep this source http://winters1224.blog.51cto.com/3021203/1589495

Tips for solving bugs