Debugging is one of the most dreadful and challenging aspects of development, and every developer must go through it at some point while working on a project. You begin working on a project with great zeal. You wrote thousands of lines of clean code in your development environment, and everything works perfectly there. Still, when you try to put the entire project into production, it does not work or behaves incorrectly.
Many developers have encountered this problem at some point in their careers, and it becomes even more unpleasant when they must clean up after others. Debugging is all about discovering the source of an issue, testing your idea, and trying every conceivable remedy to eliminate the reason for its unexpected behavior.
Every developer spends significant time debugging code, sometimes more than a week or more than producing code, draining developers' passion.
So, what is the solution to reducing the time spent debugging code? How can we reduce the prevalence of bugs? Let us go over it in depth and see the debugging tips and tricks for programmers which must be known.
How Debugging Began
Admiral Grace Hopper is widely credited with coining the terms "bug" and "debugging" in software. She created the first compiler, making her a true legend.
In the 1940s, while working at Harvard University on a computer for the US Navy, her colleagues discovered a moth (a genuine insect) lodged in a relay, causing the machine to crash.
She mentioned that they were "debugging" the system when resolving this issue.
If you're into etymology, you might be interested to know that the phrase "debugging" appears to have originated in aeronautics before making its way into the world of computers.
And there's evidence that even Thomas Edison used it in the meaning of "technical error" back in 1878.
But that isn't the aim of this piece. The argument is that debugging is an essential component of software development. It has always been and will most likely always be.
Thankfully, occasions, when we need to remove actual insects from computers are becoming increasingly rare. Now let's look at some of the debugging tips and tricks.
Top Debugging Tips and Tricks
Attempt to identify a consistent process to reproduce the bug: This is a critical stage in squashing any bug. Once we've determined the steps to reproduce an issue, we should keep the number of degrees as low as possible to limit the scope of the problem. After that, we may analyze the code base corresponding to those phases. Furthermore, once a fix for the fault is determined, you have concrete scenarios to guarantee the bug is solved.
Unit test to replicate a bug: If the code does not work as intended in a particular case, we can construct a unit test to confirm the failure and proceed with troubleshooting. We find a good beginning place for work by reducing a problem to a failing test case. Unit tests can also prevent future regressions for the same test scenario.
Rubber Duck method: "A well-understood problem is half done" - This is my favorite debugging or problem-solving method in general. Thinking aloud about the bug and expressing it to a coworker or yourself in simple words can help you find some erroneous assumptions / blind spots.
Adding logs: This is a simple and frequently used debugging tactic, and I've seen some senior Engineers utilize it. Add a slew of log statements that include program-state information to assist you in validating code execution. Furthermore, significantly changing the code to add early returns, conditional returns, and so on could be used to debug edge cases.
Using Debugger: Invest in good debugging/developer tools to improve your debugging experience. Breakpoints, dynamic expression evaluation, heap dump analysis, chrome debugger, API verification tools like Postman, and so on are a few examples.
Refer to Documentation: While some may deem this outdated, it is a beneficial recommendation. Return to the API documentation to confirm your assumptions.
Git Assistance: Identifying commits made since the last time the code appropriately operated can help us narrow down the problem space. We can detect changes that may have caused the bug by looking through the git diff. Git tools like git bisect, git blame, and git log can help you look for regressions and probable pull requests that could be the source of the bug.
Determine whether or not the correct app version has been deployed: This is yet another common source of bugs. Always cross-check the understanding of the program against which you are testing your bug to confirm that everything is as it should be. Always cross-check that the modifications have been appropriately built through all pipelines in the service world.
Multi-threading and concurrency concerns: Do not dismiss potential multi-threading / concurrency difficulties as possible bug causes. They are not immediately apparent and are challenging to root cause or debug. Also, debuggers and logs, among other things, are your best allies when resolving such situations.
Breaking Dependency Changes: We frequently stumble upon bugs in features that have been untouched for an extended period. Don't worry, and double-check for any downstream/dependency modifications that could be the root cause of the bug.
Take Suggestions and Review it: You might hear, "If someone else had a problem, what would I suggest?" This is a fantastic prompt to use when we are being too severe on ourselves while troubleshooting an issue. When debugging a problem (in Tech or life in general), I frequently have excellent suggestions for my friends or peers; however, I could be more brilliant when it comes to myself. This method is also used when I raise pull requests: before pushing the publish button on a PR, I review it through the eyes of a code reviewer and spot a few adjustments.
Old comments/documentation: Documentation and code comments are prone to become old if not kept up to date. Take care while writing or debugging to ensure that the comments in the code base/docs are still valid.
Consult with someone familiar with the code: This method is straightforward and effective. It's different than talking to the author or someone knowledgeable about the code base to grasp the code and its intent fully. A few minutes of bouncing ideas around and discussing potential core causes would provide enormous clarity and good leads for the problem.
Difficulty debugging code implies that it may need to be refactored: One thing to remember while debugging is that difficult-to-read and understand code usually indicates that it needs to be refactored. Something to keep in mind when adding to the ticket backlog.
Google/Stack Overflow: This is a straightforward troubleshooting step that we all do: copy and paste the error log and search for answers. Did you realize there are effective methods for flexing your Google-foo?
Maintain an audit trail of your debugging process: As you work your way down the debugging rabbit hole, record steps or activities you have already tried. This will assist in providing context when you explain the situation to someone else and offering some conceptual clarity for yourself. Furthermore, once you've resolved the issue, you can document it in the ticket for future reference by yourself and the team.
When you're stuck, bring it up with your team: If you've been stuck on a topic for a long time and have yet to discover a solution, consider bringing it up in the scrum with a short paragraph. This way, anyone familiar with the bug can contact you after the scrum and assist you.
Intentionally fail the code: I sometimes reverse the question "Why is this code not working right?" to "How could this code fail?" This approach compels me to consider unhandled edge cases.
Buddy builds and automation: Some issues are difficult to reproduce by hand. In this instance, automated testing is the finest instrument. Insert a slew of debug logs and metrics into your code and run it through a battery of automation tests. Automation will catch it if it's a timing issue or a bug that occurs once in n time. After that, you can review the test run logs or metrics for further information.
Please remember not to violate your production code: When debugging systems that may have a real production impact, we must exercise extreme caution. Examples include working with databases, making production configuration changes, and so on.
Platform-specific issues: When identifying strange mobile phone/browser application flaws, check if the bug reproduces across platforms or is isolated to a specific forum. There are two examples of defects in Android applications that only replicate on Samsung smartphones or those that only reproduce on the Android 8 version.
Feature flags: When new features are released, they are accompanied by a feature flag. Double-check that the feature flags are set correctly if a feature isn't operating as expected.
Consult with Quality Assurance Engineers: Most teams include individuals who specialize in testing the product to ensure its quality. Often, they will have valuable tools to model difficult circumstances and know edge cases that you may be unaware of. Please try to spend time with them and lead them through the bug.
Take a break and come back: This can work wonders. I frequently break this rule and work on a problem for hours, straining my eyes and thoughts. Taking a break and returning to the problem with a refreshed head is always beneficial.
Utilise Binary Search: It is challenging to locate a complex issue in a faulty file, mainly when it contains hundreds of lines of code. In those circumstances, you'll need to check more and more areas, and the best way to avoid this is to use binary search. You must divide the code into two portions throughout this operation. Comment out one section and run another. Repeat the process with whatever component is responsible for the mistake. Keep performing it until you locate the exact lines of code that create an error.
Increase the frequency of running your code: This is the most critical piece of advice, particularly for newcomers. Many beginners make this error and run their code for the first time after writing a large amount of code in a file. Please avoid this error, or you will become even more perplexed by inspecting your code and wasting time finding minor errors. When you execute and test your code every time, you get feedback and can see if you're on the right track.
Technical Debugging Software
Numerous techniques are available to help us reduce the likelihood of problems being introduced into our code or fight existing bugs more effectively.
In this regard, we'll look at TypeScript, the famous (and very handy) console.log, and the debuggers included with VS Code and Chrome.
Although these tools and examples focus on JavaScript, the ideas apply to any programming language.
You should also be aware that most code editors and web browsers now include built-in debuggers, but we'll focus on VS code and Chrome because they're the most common.
Finally, you should be aware that you may use specific debugging tools to debug distinct sorts of apps, such as React and Redux dev tools, which are popular browser extensions you can install to help debug your code more efficiently.
How TypeScript Aids in the Writing of Clean Code?
The first tool is TypeScript, closely related to the preceding section on producing clean code.
TypeScript is more than just a powerful typing system for JavaScript. It also has a compiler that assists you in identifying errors and misconceptions in your code before running it. It has excellent autocompletion and can be used as an automatic documentation tool.
How to Debug Code Using Console.log?
You can also try; logging your code in the console is the most fundamental method of debugging and the first one we learn as developers.
The aim is to print the values of variables, functions, inputs, and outputs to compare our logic to what happens in our code. It also allows us to understand what incorrect assumptions we are making.
Even though it is a simple tool, we can perform some exciting things with it.
How to Make Use of the Visual Studio Debugger?
As our apps expand and get more complicated, console.logging becomes an inefficient practice.
Debuggers were created to assist us in our battle against bugs. They are just programs that can read other programs and run through them line by line, checking any information we want (for example, the value of variables).
An example is the Visual Studio debugger.
We don't need to install anything extra to debug a Node.js app (provided we have VS Code and Node installed on our machine) because the Node debugger is built-in to VS code.
If you're debugging in a different language, such as Python or Java, you may need to install a particular VS extension before using the debugger. First, we choose the file to be debugged and tap the problem icon.
What is Chrome Debug Tool?
To begin debugging in Chrome, we launch our app in the browser. You can generate a simple HTML file that links to my JS file (the same file as in the previous example).
Then we go to the "sources" tab in the developer tools (ctrl+shit+i or right-click -> inspect).
Why Should You Study Debugging?
Because software development is a mental and abstract endeavor, bugs and errors are common.
We work with information as developers. We organize, move, update, amend, send it to different locations, and then receive it again.
We constantly work with information rather than directly with it. The information does not "actually" exist within the computer, at least not in the way that users imagine it.
Electric pulses within the computer are abstracted to 1s and 0s, then summarized again into whatever information we're working with.
Programming languages are used to interface with and use computers. And they give levels of abstraction from the actual operations performed by the computer and representations of the data we're managing.
Programming may be a pretty abstract activity, and it's straightforward to lose sight of the computer's actual role or what information we're operating on in a specific line of code. From there, it's easy to give the computer the wrong instructions and miss the target we're looking for.
One of the most renowned jokes in the software development world is that developers typically spend 5 minutes writing code and 5 hours attempting to figure out why things don't work correctly.
We will spend countless hours debugging our code as developers, no matter how skilled we are. Thus, we should endeavor to get better and faster at it.
Comments