One of the brain methods---debug and search algorithm

The year before the time of the egg ache, saw the Tianjin satellite TV program "Not You Mo", come a bunch of interviewers, above a few trenches, choose people. Remember that there is a period for programmers to do, and one of the programmers (like the yuan) silly to say, gee, every time I debug to find the program bug, the most happy. Then a boss, OK, hello cute ah, like to write programs Ah, come to me.

I think it's nice to find a bug, it's not stupid. But the truth is that I find that many people find bugs, or that the problem of solving bugs in a program is very inadequate.

Why do programmers find it so hard to solve such simple things? And it's a pleasure? And what is the nature of the fix, or debug?

Debug: Is to find the bug, and then put it de, that is, Debug.

The first and most important step in debug is to find a bug. and "Find" is not "find", and "find" is not "search", "searches" is not "searching"? so debug is essentially a search, and the target of the search is the bug in your program. The strength of your debug capability, the speed, efficiency, and accuracy of your debug, depends entirely on whether you have a clear search algorithm running in your brain and how well your current search algorithm is .

When you're clear, and believe that the debug process is just running a debug algorithm in your brain, things are going to be very simple, just follow your algorithm.

Here are some common examples of debug:

1. Before and people write code, solve the bug in the program, found a lot of people like when debugging, this file to see, the document look, the east, a little bit. This is an algorithm that does not have a definitive search bug in the brain. This situation, for a long time, may finally be able to solve, but can only be said to be "stupid".

2. And the first example, on the contrary, there is another way, I just stay there to contend, suppress, suppress, suppress, can't hold, ah, do not know where there is a problem. This is also wrong.

2. In the legacy system, some files, some classes of code thousands of lines, this time, there is a bug, to solve the problem. Someone is looking at a line, plus a breakpoint on one line. Finally, after a long time, finally solved. Of course it's good, but what's the process? What you do is essentially a search algorithm with an O (N) complexity. This method is better than "stupid", belonging to the "Stay" stage. Because, as we all know, as long as the use of two points to find, the algorithm complexity can go to O (Logn), so, assuming your code is 1000 lines, you add a breakpoint in line No. 500, see if there is a problem in line No. 500, if there is, then the 0~500 line between the search, if not, in 500~ 1000 to find, etc. In this way, 1000 lines of code, theoretically you can increase the efficiency of 100 times times (of course, not so exaggerated). In a previous legacy project, there was a bug, a pair of pair looking for two or three days did not shine out, I spent more than 1-2 hours, the exact location of the problem (build time is longer). This is the increase in efficiency, in essence, just using a better search algorithm. Nothing New.

3. It is complained that the debug speed is slow because there is no understanding of some basic things. For example, for a new third-party library unfamiliar and so on, if familiar with, you can quickly solve the problem, complete the debug. So, what this scenario illustrates is that when you use heuristic algorithms for searching, the heuristic function of your heuristics is actually how familiar you are with the basics of the past. The more familiar you are, the faster you will be inspired, the quicker you'll find the problem, the less familiar you will be, and the slower you'll be. Ideally, you know everything at your fingertips, and you can find the problem in O (1) time. However, even if the knowledge is unfamiliar, can not completely prevent you to find the problem, because you can at least O (logn).

The example above can illustrate the relationship between debug and search algorithms. So, to summarize, I think the correct way to debug is to clear your bug search algorithm, estimate its efficiency, and execute it.

Well, do we always use O (logn) to debug? Can we do a better job?

I myself was very disgusted, as well as despised, and disgusted, as well as disdain, and the way of the disgusting breakpoint debug, the way in which breakpoints are debug most of the time is a good way to make programmers more stupid, although in some cases, also have to manually debug.

So, how to play?

It's simple, automated testing, writing unit tests, integration testing, and when we're having problems, these tests can help us narrow down the scope of our search. Of course, return ah, the mess of things I will not say.

DEBUG, is to search for bugs, let it de after it.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

One of the brain methods---debug and search algorithm