I believe that debugging is one of the most important technical skills a developer can have. In the average week, I probably spend anywhere from 20 – 30 percent of my time debugging. This is because my code isn’t perfect, sometimes it does legitimately only work on my machine or device.
I’ve blogged quite a bit about debugging in the past, my post about being a more efficient debugger gets a considerable amount of traffic every month.
In the case of Salesforce, I might be hitting a ton of governor limits in production compared to my developer sandbox. Tracking down where a potential bug or problem in the code can be really difficult especially if you didn’t write the code or aren’t familiar with the project.
The techniques that you can use for debugging really depend on the programming language and the environment in which the system will run.
Analyze logs
For nontrivial bugs, it usually makes a lot of sense to spend 1/2 an hour attempting to analyze a stack trace or the giant file logs because it can potentially save hours of debugging. And in the end, if logs aren’t collected then maybe you just found yourself some more work. 🙂
When you read through the logs, you should be looking for unexpected things that are happening. You shouldn’t read more than a couple of hundred lines before you start using tools my search or grep.
Create Tests
Creating tests when a bug occurs is a great way of making sure a regression won’t happen. It’s also a great way of potentially determining where the problem is.
I am a huge fan of doing test driven development as the tests are probably the best documentation that will exist for a system. They also have to be maintained if the company is doing CI/CD.
Use the Debugger / Breakpoint Debugging
Most of the time I like to use breakpoints and evaluate the values of variables as the code executes. The really cool and added benefit of this is that you’re able to actually see how the code works, this works pretty well for Android, anything .NET related, most Java Projects and
I like having the ability to query different objects, test values, and what’s accessible already. In a lot of the environments I’ve used, it’s possible to do anything that’s being done in code which makes it pretty powerful.
For languages like Apex on Salesforce this isn’t really possible, so you usually end up with logging and intentionally breaking.
Log Everything
One of the easiest ways to debug little bugs is to log statements across the code base as the code executes. In a language like JavaScript or Node.js you would likely use console.log.
In PHP you probably are using echo statements or var_dumps. I like to call this var_dump and die debugging with my team. This really starts to fall apart if the issue isn’t simple and isn’t localized to a few potential classes or files.
I find that I usually miss logging something really important and end up having to test and run quite a few times to finally understand what’s going on.
Git Bisect
Git is a really powerful source control management system; it keeps a complete application revision history and allows us to pull from any time in history. I’m not a huge fan of this approach for really simple bugs but it can be a great way of getting context into why a change was made.
Git bisect is pretty easy to use if you know the commands, the basic concept is that you go through the history in git and keep iterating until the error doesn’t happen and then choose the commit right before and set it be git bisect bad and then the one where it was good you would set to git bisect good.
The documentation for git bisect is pretty good, I recommend giving it a read.
