Five simple debug rules for novice programmers
From the translator: George Alan Heimel in his article shares his own experience and talks about how the developer should be guided in the debugging process.
Modern developer tools are very extensive, so there are plenty to choose from - debugging tools. Many of them are automated, but, unfortunately, debugging will not work out of course - there is still a lot of manual work. Sometimes it seems that the problem simply should not be, it is impossible, everything should work. But does not work. In order not to waste extra nerve cells and time, I derived simple debugging rules for myself, which I use. I think someone might find them controversial. However, they help me.
Skillbox recommends: “Mobile PRO Developer” .
We remind: for all readers of "Habr" - a discount of 10,000 rubles when writing to any Skillbox course on the promotional code "Habr".
Rule 1. There is always a reason.
Despite statements like "It is impossible," "It should not work like this," "There is no reason for this code to not work."
There is always a reason, be it an incorrectly working code or errors during compilation. Is always. Even if the checker says that everything is fine. Sometimes we dive too deep into the code, losing the big picture. Most web or web applications are complex. They all include many elements. Sometimes too much, so we can make a mistake in one of them and forget or not notice it.
Step back, take a deep breath. Then look at the code again. Do not rely on tools. Use the brain and logic. Consider how the current item you are working on affects everything else. In most cases, the error belongs to the class of PMSIS (the problem is between the chair and the table).
And for the sake of all that is holy, when you correct something, do not correct ten potential mistakes at once. Otherwise, you will get confused, it will be extremely difficult to find a real error. Sometimes debugging requires a little patience: make small changes step by step. Be methodical and precise like a scalpel, not like a shotgun.
Rule 2. RTFM & WTFV
Most developers are smart people. Sometimes even too smart, to the detriment of themselves. We all think that we do not need basic tutorials, because you can immediately start learning advanced things.
Yes, of course, in some cases there is no problem, in addition, we learn as we implement various projects. But a situation may arise where you will be engaged in a large and complex project for several weeks, and then it turns out that everything is based on an incorrect premise — an error that makes further work impossible. This may refer to the framework, language, tool. You just lose time.
Therefore, learn the rule that sounds like the English text in English (hence the abbreviation in the subtitle).
Sometimes you just miss a critical moment, a trifle, necessary for work. You need at least a glimpse of basic information about the product you are using. In my practice, there have been many instances when developers failed to meet deadlines due to gaps in knowledge of a language or tools. And these were not bad experts, - they just jumped right to the end of the book, missing the important words of the author at the beginning.
New frameworks appear almost every day, languages or their new versions also come out with enviable regularity. To effectively use such tools, we need to understand how they work.
Rule 3. Please use rules 1 and 2.
So, you read the article and started working. After a couple of hours, you meet the manual, which is important for our work, and ... miss it. No, this will not work, use the rules above. Nobody said it was easy.
Rule 4. Study changes
Fortunately, not only you, but many other developers use the same tools. Information about problems and developments they are divided into relevant resources such as Experts Exchange and StackOpen or on specialized forums.
Look for information about your problem or changes in the tool until you find it. If there is nothing, re-read rule number 1.
Rule 5. Rest and start from the beginning.
In some cases, we really do not see the forest for the trees. Diving into the code for long hours exhausts us both mentally and physically. If you have already gone through your code three times and have not yet found the cause of the error, then it’s time to let your brain rest.
In some cases, a simple walk in the fresh air suggests a new idea and helps to immediately find the problem. Sometimes not, but hassle, aggression or despair are not the best helpers in our business.
Just do not look at the screen. Talk to a colleague, sit in silence, because the noise acts negatively. Have a snack in the end. If time allows, just sleep, forget the deep and deep sleep. Sometimes I managed to find an answer to the question that tormented me after sleep.
Clean your head from all the tinsel and debris of previous attempts to find a mistake and look at the problem from an unexpected side.
Well then ... yes, you guessed right. We return to rule number 1.