Nowadays, it is difficult for us to imagine that we could create any major project without access to a specialized IDE. Increasingly, we also reach for advanced debugging tools. In this article, we’ll try to introduce you to several .NET technologies that can support your team in effective code debugging. But, what should you pay attention to while choosing a debugging tool? Check this comparison to find out!
Track the value stream effectively.
What is the most important factor of effectively localizing error cause? Understanding how the code works in details and how it’s executed. Every single tool supports the developer in this task in a different way. Some of them allow you to go back in the executions history, to understand why a particular state has appeared. While choosing your own debugging tool look around at those, which give you the ability to not only inspect particular events but also to take a look at the whole structure. For example – a timeline with a history of execution of your code:
What happened in the application:
What you could do in Visual Studio:
Debug on production
As we all know there are two types of bugs. Those detected at the development stage, and those which appear on production. While choosing a debugger you should check what kind of support does it give you in debugging on production. Does it have the ability to gather data about what is actually happening on production, to detect bugs? Reverse debugging tools are equipped with such possibilities.
Will it help my DevOps team?
Another question, which you might ask yourself while choosing the debugger is how will the implementation of it affect DevOps. Will it support the whole process or disturb it? How does it influence the individual DevOps elements:
Debugger for development
Debuggers are often considered as tools created to support development. A good debugger should support the developer in each of the following debugging phases:
- noticing the error
- finding it’s cause
- fixing the error
Does the debugger give you the ability to inspect how did your changes affect the whole application system?
Debugger for QA
You probably wonder if a debugger can be a tool that helps testers? To answer this question we need to think about what tasks testers are responsible for. Those are not only preparation of tests, but also creating detailed bug reports. There is an analogy in that – a debugger, not unlike the testers, is also responsible for providing the bug environment data. Therefore, why not use such a tool during the tests, to save time?
There is another factor which should be taken into consideration when choosing a debugger in terms of supporting testers. Code coverage is an important measure of tests effectiveness, so if debugger contains tools that allow you to look into this – that’s a big plus.
Debugger for Operations
Monitoring an application and its health on production is one of the most important tasks imposed on members of the DevOps team. Can this important task be supported by the well-chosen debugging system? The answer is yes. Keeping the terms of the SLA is much easier thanks to constant monitoring of applications on production.
Would debugger support all kinds of .NET applications?
These days there is an unimaginable amount of technologies derived from .NET. SP.NET, ASP.NET MVC, ASP.NET Core, Xamarin, Entity Framework… we could go on like this all day. To be honest to ourselves – once we will learn some tool, we would like to use it as many times as possible. The good debugger is able to support your application no matter what technologies you have chosen.
Debugging lambda functions
Only a few debuggers available online giving you the ability to debug lambda functions. But why is it so difficult? While debugging them you actually can’t set any breakpoints! That sounds like the worst nightmare, isn’t it? While choosing a debugger to consider if it’s allowing you to debug under such special circumstances.
Modern applications are extremely complex systems. Many of them are multilevel, multithreaded and multi-process. The search for a root cause of an error, in many cases, resembles looking for a needle in a haystack. Especially those multithreaded require from developer great knowledge about the functioning of the entire system. Fortunately, there are tools that allow him to look at individual threads. How does it work? Check this recording from Visual Studio to find out:
Why not make a search engine for bugs?
There are search engines for bugs. What do I mean, by these words? As I’ve mentioned before, some of the debugging tools give you the ability to inspect the values of variables in the application. But there is even more – they also give you the ability to search through those values. Below is an example:
Historical travel within a current loop
There are two ways to inspect values which are delivered from the production. We could take a look “from the distance” to better understand a whole application architecture. Or inspect them in details. So-called scope stack gives you the ability to dive into value changes within particular scopes – loops, methods etc.
Sharing the problems – debugging is a team game
Two heads are better than one, especially in the software development world. Developers have always known this, creating specialized forums where they could share their debugging problems. We may notice, that the perfect debugger should have the ability to save and share debugging sessions. Those mechanisms are the key if you want to engage the whole team into solving of a problem.
As every developer has his own style of coding, they also have their own styles of debugging. That’s why the debuggers should enable filtering for the most important information. Whitelisting, blacklisting, and exclusion rules – those tools making debugging much faster, with them, you won’t get drown in the flood of information.
Does the debugger give you the ability to check crashes on production?
Last but not least. The faster you detect the error and fix them, the less damage it will cause. That’s why a debugger connected with an application on production should not only detect the bug but also give you information about how many users are affected by it, and how many times it occurs, to help you decide what should you fix first.
Those are eleven decisive factors which you should consider while choosing a debugger! Hope that this article will help you to choose wisely from all available options. As you may notice in this article we’ve embedded graphics from RevDeBug, which contains all those features. You may test it for free: