In almost every case this will guide you directly to the broken part of your code. Use your editor support or break point tools to stop at a certain point and check out the context, while being able to move forward, line by line. A beautiful break point tool for Python, for example, is ipdb which gives you more context and options than pdb , by the way.
To browse, understand and inspect frontend code you can unminify files. Just open the file in the sources panel and hit the brackets icon. Chrome offers beautiful ways to inspect and modify your code on-the-fly.
Right-click the element you want to inspect or open the developer tools and see your source code, files, loading schedule and what not.
You should spend some time on reading the docs or checking out everything offered. Running a responsive website creates unlimited layouts. You are already able to play around with styles using the tools above. The JS console is your friend. To simply output something use console.
To add a break point use debugger. As soon as the code is executed Chrome will stop right there. You can then proceed line by line, use the console and much more.
For a trace use console. You will see a stacked output of the executed code. You should see that bar was executed before foo. Watch functions using monitor. It will let you know every time the monitored function is executed. Debug functions using debug. The opposite is true as well. This symbiotic relationship is also the key to improving our debugging skills. If we want to get better at debugging, we have to get better at learning new things.
Of course, we all want to get better at learning things. One of the keys to getting better at learning is to use effective learning strategies. Like with teaching, your goal when using effective learning strategies is to make sure you learn something properly.
In one situation, you need to learn it well so you can teach it back. On the other, you need to learn something well so that you can find the problem with your code. In both cases, you need to go beyond copying and pasting code without understanding it.
This brings us to an important side point. Yes, there are steps that we can do to get better at learning and debugging. But some of it is just experience that you have to acquire yourself. These are some of the most frustrating and time-consuming debugging experiences.
But these experiences also tend to sear the knowledge in our brain. This is even if you have a growth mindset. Nor are they an efficient use of your time. So it comes down to making sure that you get the most out of them when they happen. They might even help you cut down the time it takes you to learn something. So what are things that you can do to improve how you learn something? That said, there are things that you can do regardless of the learning strategy that you use.
Instead, you should always try to solve it yourself first. The idea is to leverage something called active recall to help you memorize information. If you ever used flash cards to study in school, that is a way to learn using active recall. This contrasts with passive review. This gives you the illusion that you know something well because you can see it at a glance.
If you just google the solution to your bug, you might solve it faster now. A bug might span multiple modules, requiring understanding of the whole state and control flow of those modules. In unfortunate cases, however, there is nothing wrong with your codebase. The cause for the bug might even be external to your codebase. When binary search doesn't work, you need more creative approaches. Consider brainstorming to enumerate even the wildest possibilities: for instance, maybe the bug is in some external resource like a library or a remote service; maybe there is version mismatch of libraries; maybe your tool e.
IDE has a problem; maybe it is bit flipping in the hard disk ; maybe the date and time library is sensitive to your computer's settings, etc. When validating your assumptions, your problem could also be in your validation method: you might think you have validated that there are no typos, but there actually might still be a typo. Consider validating your assumption twice with different methods. If you are in a team, do pair programming so at least two people have validated the same assumption, in different ways.
Programmers often make the bug "the enemy", and it's not rare to swear at the computer. Programming, however, is a lot about understanding correctly, not about typing and building.
Most of our programming time is spent understanding how all parts should be connected, and only a small fraction of our time is spent with actual keyboard typing. Prefer to antagonize your lack of understanding more than the bug itself. This might sound obvious, but in the middle of debugging, you are likely to antagonize the bug. Make a conscious decision to avoid that.
Once you understand everything, fixing the bug is normally a simple task. Some programmers are geniuses and understand everything in little time. If you are like me, you do not understand a lot by just glancing at the code. You might need to run the program a couple of times and experiment with it to discover some properties of its functionality. Debuggers are an obvious tool for understanding your program. But you can also rely on ad-hoc tools for aiding your understanding.
Reading logs or using the poorer variant of printing debugging strings to the console are great tools that complement debuggers. While debuggers give you insight into deep and specific parts of your codebase, logs and console prints can help you build a bird's-eye perspective of your program.
This might be useful for validating assumptions that span multiple modules. Be creative and think outside the box to build more exotic tools than the common ones.
RxVision is one example for reactive programming. Build them yourself or search the web for others. Do not make any syntactic or other errors while implementing the code. Then, it continues in successive stages as code is combined with other units of programming to form a software product. A debugger helps to allow to stop your code when it gets to the place where you suspect a problem of logic or implementation, and to investigate whether it is really doing what you thought it would.
You could do the same thing by adding printouts to your code, but it's a lot less convenient and flexible. Identify the Error : Bad detection of an error can lead to wasted development time. It is common that production errors reported by users are difficult to interpret and sometimes the information we receive is misleading.
This is an import to identify the actual error. Find the Error Location : If you need to go through the code to correctly identify the error, then find the exact point where the error is located.
0コメント