Everyone makes mistakes, and developers are no different. As a developer, you spend a significant portion of your time debugging the code you write. It is an inextricable aspect of software development. Some bugs are easy to find, while others can make you scratch your head.
A proficient developer needs to know how to debug the problems they face along the way efficiently. Becoming familiar with Xcode's debugging tools and workflows is an aspect developers often overlook because you already know how to use Xcode. Right?
Xcode ships with various debugging tools that can make your life easier and less frustrating. Believe me when I say that debugging can be frustrating. Knowing where to start and which tools to use can make a world of difference.
In this course, we explore the debugging tools Xcode ships with. You learn to read stack traces, use breakpoints, and interact with the LLDB debugger that powers the Xcode debugger under the hood.
Where to Start
Xcode's debugging tools can be overwhelming if you are new to them. You can use breakpoints, inspect the output in the console, or debug your application's view hierarchy. But not every debugging tool is a good fit for every scenario. For example, the view debugger isn't helpful if you are tracking down a memory leak.
That brings us to debugging workflows. It is important to emphasize that there isn't one workflow that works for every problem you face. That can be frustrating to hear if you are new to software development. When starting out, you prefer to use a proven recipe that works. Right? Welcome to software development.
I would like to start by outlining the workflow I use whenever I encounter an issue or receive a bug report from a user. If you are new to Swift development, then this workflow is a good starting point. If you have several years of experience, then it may give you some ideas to improve or tweak your workflow.
Define the Problem
The framework I use time and time again is simple and straightforward. Whenever I run into a bug, or a report hits my inbox, I start by defining the problem. That should always be the first step.
You need to collect as much information as possible, such as device information, operating system, application build, and, most importantly, steps to reproduce. If you cannot reproduce the issue, then everything that follows becomes more difficult.
As a developer, you want to fix your mistake quickly. While that is understandable, it is important to take your time. Don't move too fast. You need to understand how the problem is triggered. The patch you implement should squash the bug, not one of its manifestations.
That is why you must understand the problem and its root cause. The goal is to squash or eliminate the bug, not patch it with a band-aid.
Pinpoint the Problem
As you collect information, it becomes clear what type of issue you are dealing with. Is the problem related to the user interface, or is the user missing data due to a problem with the backend? These are very different issues that require different solutions.
Pinpointing the problem should be your priority at this point. You need to make sure the issue is caused by a bug in the project. Some problems are caused by usability issues.
One of my apps uses gestures to make several actions easier and faster. Those gestures were enabled by default in earlier versions of the app. Several users reported what seemed like a bug. The root cause was a usability issue I needed to fix. These users triggered one of the gestures by accident and were confused by what seemed unexpected behavior.
For apps that communicate with a remote server, it isn't uncommon that backend problems manifest themselves on the client, that is, in your app. Make sure you are not spending hours or days debugging an issue that isn't yours to fix.
Before you write a single line of code that could fix the bug, you need to know the root cause of the problem. That isn't always possible, but that should be your goal. If your car breaks down, replacing the engine isn't your first option. Is it? The solution might be trivial, and it very often is, if you can pinpoint the problem's underlying cause.
Choose Your Tools
The more information you have about the problem, the easier it is to choose the right tools for the job. If I can reproduce the issue, I usually start with a few print statements to better understand the problem. Once I know what type of issue I am dealing with, I can bring in more specialized tools that help me investigate the root cause.
Implement a Solution
Once you have a clear picture of the issue, it is time to come up with a solution. That can mean fixing a typo, but it might also mean hours or days of work.
You don't always have the time to implement a proper solution. That is fine as long as you implement a more robust solution in a future release. Create an issue to make sure the problem stays on your radar. A proper bug or issue tracker is indispensable in software development.
Test the Solution
Most developers test the solution they implemented. What is often ignored or overlooked is adding one or more automated tests that prevent the problem from reappearing in the future. This idea isn't revolutionary, though. A bug that makes its way into the project reveals a weakness of the project's test suite.
By writing one or more tests that reproduce the problem, you feel more confident that the solution you implemented is solid, and you don't have to worry about it again. If the problem does pop up again, your test suite automatically warns you about it.
I would like to take it one step further and suggest writing a test case before implementing the solution. If you can reproduce the issue, you should have the information you need to write a failing test case. This idea isn't revolutionary either. This strategy is at the heart of TDD or test-driven development.
Reproducibility Is Key
Fixing a bug without the ability to reproduce the issue is like finding a needle in a haystack. Every developer has fixed, or tried to fix, bugs that weren't reproducible. It is a frustrating and expensive process for everyone involved, the project manager, the client, and you.
Experienced developers often argue that you should only implement a solution after you have been able to reproduce the bug, and that makes a lot of sense. Whenever you are fixing an issue, you want the patch to be small and lightweight. That is only possible if you know exactly what the problem is you are trying to fix.
Implementing a solution to fix a random bug results in obscure commits and unnecessary code changes. Avoid it whenever possible.
Don't Feel Discouraged
Debugging can be very, very frustrating. As a developer, you sometimes spend hours or days finding the root cause of a nasty bug. It is important to go easy on yourself. If you cannot find the root cause of the bug, then that doesn't mean you aren't a good developer. Cut yourself some slack.
If you are lucky and surrounded by a team of developers, then don't hesitate to ask for help. A fresh pair of eyes can often make a difference.
What's Next?
Xcode's debugging tools are powerful, but it takes time to master them. I discover new tips and tricks regularly. It is important that you focus on the fundamentals first and step up your game as you need more power and gain experience. In the next video, we look at the debugging tools Xcode ships with.
