![]() With any project running on Node it’s good practice to wipe out the Node modules directory and clear your cache from time to time. If it is working on your machine but not another one it may also be environment-related.If it was working locally but it doesn’t after you deploy, it’s probably an environment variable.Then feel free to shake your tiny fists at the heavens or in the general direction of whoever wrote that code. It might be a known bug or quirk that isn’t even your code. If all else fails, search for the exact error message in Google.Not only are you solving the problem you have now but you’re developing a problem solving arsenal. Check these code snippets into your Github repo so you can refer back to them. Break a problem into it’s smallest components to understand how each part works.Eventually you will find the layer where things are not working as you expect. Strip away all the layers that alter expected output from input. Hardcode variables, use fixture data, or any of the other things you would use for a unit test. Try the dumbest thing first, so you can test your assumptions.You may encounter a lot of misleading and plain wrong advice that the official docs will not have. If you go there first, without fundamentally understanding things, you will do future you a disservice. Only after looking at docs and finding nothing should you go to Stack Overflow. Go to documentation for answers first.Redux also has amazing dev tools that will help demystify what is happening. This instant feedback allows for a fast iteration process when it comes to finding exactly where, or more importantly when bugs are happening. Ember and Angular have similar dev tools, and I’m guessing Vue does too. React’s dev tools can allow you to dial in and verify state variables as things change on the screen. If you are a front end dev then the majority of debugging is probably going to be related to state.Console.logs: no one should leave those in shipped code.If you have confidence it will be easier to use them when everything seems broken. Choose your weapons well and get really comfortable with them. There are endless tools for this: breakpoints, printing out log statements, etc. Where exactly is it broken? You can’t fix something until you know exactly where it’s broken.Sometimes new code doesn’t introduce bugs, it just uncovers them! Beware the pointy finger of blame as it may point right back at you. You can compare files & use the diff to see what changed. Ask yourself what is different since it was last working? Use git log to see the change history, then roll back to a commit where was working.Often you are stuck in tunnel vision so a short break may give you fresh eyes. There is a temptation to give up when problems get hard, and this is by no means what I’m suggesting. Talking to a duck or anyone, really, forces you to use a different part of your brain. If not, feel free to talk to another human being. Part of the way through you may already have a eureka moment. If you have a rubber ducky handy, tell him what is wrong and I promise he will listen without interrupting. First off try to describe the bug out loud.It’s important to develop a well-honed use of the tools of the trade before wandering into dangerous situations. While developing my debugging skills, I’ve discovered a few good tricks along the way. A sleuth will find answers, no matter the cost. The prospect of losing one’s badge, personal relationship, or even life do not deter the detective one bit! She has a curiosity itch that must be scratched. The detective has a hunch but can’t quite put it all together. But let me tell you, Gentle Reader, it’s still far more entertaining than scrubbing toilets, waiting tables, or making lattes for a living.ĭebugging is kind of like a classic mystery storyline. You could look on this exercise as a dull task that must be executed and find no joy in it. Often the lion’s share of your time is spent solving the bugs you’ve written (if you’re lucky) or those you didn’t (if you’re most of us) or reading through code others have written helping them avoid bugs. Plus, I get to pretend I’m a detective!Īs a software developer, only part of your day is always devoted to writing code. After a lot of menial labor type work I was bored and wanted to use my brain. It’s why I became a developer in the first place. Insanity! It’s much more fun to write buggy code than to unravel it! But problem-solving is fun. One of my favorite things about writing code is debugging.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |