Detective, how to dramatically speed up debugging.
TL;DR: I built a tool that lets you inspect app-state in real-time and allows you to do even more in the future. Visit www.detective.dev for instructions on how to use it.
On debugging
Debugging can be fun at times, but most of the time, it just sucks. The feature is done, the workday is over but and you are ready to do anything but sit in front of the computer for the rest of the day. But just as you close your IDE you notice something, something that is bound to keep you awake at night: a bug.
You were ready to move on onto your next coding adventure (others call them “feature”) but you can’t.
I hope I’m not the only one feeling like this from time to time.
I did a Twitter poll and it turns out, debugging is a rather big part of developing an app, and scenarios like this aren’t the exception.
Debugging mostly consists of guessing where the problem might be and then setting up assumptions and checking those.
It’s like looking through a magnifying glass
Sometimes you just don’t see the wood for the trees. When debugging, you only see a very small portion of your application. It may be the variables you printed out for debugging purposes or the current frame where the debugger hit a breakpoint. So you keep looking for the issue with a very small slice of the whole world and this works surprisingly well. People find bugs and subsequently fix them — but now imagine what happens when you have the power to see more? To levitate above the forest instead of standing in the middle of it.
Detective to the rescue
Detective allows you to inspect all the interesting application states at once. For information on how to install, head over to www.detective.dev.
How to use it
First, you have to select a class you are interested in. This typically is some sort of class holding some mutable (changeable) state.
Next, select the specific instance to use. Most often, the class you are interested in only exists once, if that’s the case just select it. Sometimes you may not find an instance at all, there are a couple of reasons for that but one to watch out for is that Providers are lazy by default, meaning the instance will not be created until its first use.
And you are ready to go! Start by looking at the state of this specific instance of your class. Notice how changes, that you do by using the app, happen in real-time — no need for any reloading.
Seeing the big picture is great — but can we do even more?
Good question! And the answer is a definite yes. State inspection is just the very beginning of all the possibilities with an app that is able to access meta information in combination with runtime information of a process. Here are my top three features on the roadmap:
Debug function invocation
Sometimes, while debugging, you just want to invoke a function, emit an event or change the state in a specific way. Usually, this happens through some sort of UI, but there can potentially be a couple of problems with that.
The UI is not built yet
Starting with logic first and then building the UI is generally a widespread approach. But testing said logic becomes hard without an interface, so usually, some kind of placeholder is implemented — this again takes time and can be avoided.
UI cumbersome to use
Some features just require lots of setup to move into the desired state. This could be tapping through long forms, changing system settings, or any other setup.
Faster due to the use of presets & shortcuts
A lot of programmers prefer command lines and other text-based inputs due to having mastered the keyboard quite well. So why go the slow route of using a point and click UI?
Visualizing class-dependency graphs
Everybody knows the term ‘spaghetti’ code. What that means is code that is very interconnected. Everything is referencing a lot of classes, maintaining such code becomes increasingly difficult as it is very hard to reason about a specific section without having the whole picture in one's mind.
Therefore is important to separate code into chunks that are very isolated, and thus making it easy to read and modify. A reference is when one class [‘Foo’ uses another class ‘Bar’], meaning [‘Foo’ depends on ‘Bar’] or [‘Foo’ references ‘Bar’]. If you look at all classes in your project and you notice a lot of cycles ([‘Foo’ uses ‘Bar’] and [‘Bar’ uses ‘Foo’]), it probably is a good indicator to refactor.
Getting a sense of the project structure can be hard at times because you can only look at one class at once. Visualizing this into a graph structure lets you reason more efficiently about the architecture you chose.
State time travel
This one is potentially the coolest.
When debugging applications, a very interesting fact to learn about is state changes, and what causes them. Right now, when the state is changed, there is no going back. This means if you want to find out what leads to said state change, you are forced to redo the actions that led to right before the interesting state change.
Make this process of redoing time-consuming, and requiring multiple tries and you successfully spent more time than you wanted on solving the issue instead of creating something new.
Detective has the potential to record interesting states as you interact with the app and replay it to you without having to do anything in the app anymore.
Think of this as time-travel in Redux web but for Flutter. I think it is pretty self-evident how this can potentially save a lot of time.
Embedding it into IntelliJ and VSCode
This one is pretty self-explanatory. Using the power of Flutter web, Detective can be built right into IntelliJ and VSCode, using a plugin, resulting in fewer windows on your desktop and even more productivity.
Closing remarks
If this sounds as execting to you as it does to me, be sure to give it a try at www.detective.dev. It only takes 3 commands to install.
If you want to stay up to date with the newest development information be sure to join the newsletter at the bottom of the site.
Last but not least, let me know what you think!
