Getting up to speed with an existing codebase
Catching up when rebuilding is not an option.
Tackling new projects is exciting, but sometimes it’s difficult to understand what is going on. Specially if the codebase has existed for a while, and seen many interactions from fellow developers. When I find myself in this situation I often resort to these debugging options.
Using the Debug View Hierarchy for more than UI
The Debug View Hierarchy was a fantastic new addition to Xcode, but most of us only use it to debug a particular problem about how a view is displayed. But, what if we have no idea about the code base, and we want to know what files are responsible for particular screens?
Now, simply by tapping the UI while in debug mode, we can learn what file is responsible for the selected view. When you don’t know where to start, this is fantastic.
Breakpoints on property names
Application state is the most common way to introduce bugs in your apps. What can we do in situations when we know which variable is changing, but we just can’t seem to know who is making these changes?. Let’s say we know that «placeholderLabel» changes often in the app.
Simply by adding a breakpoint right where we declare this property, Xcode will stop every time somewhere in your code is using this property, now it’s just a matter of seeing in the Debug Navigator the whole stack trace of these calls. This is pretty magical 🎩✨.
Stepping into the rabbit hole
Every good developer knows that their lines of code matters. Not because they are expensive to write, but because they are really expensive to read. Digging into files with several hundreds or even thousands of lines of codes should be illegal.
Ironically, this can lead into a problem where there are dozens of methods calling each other, making it really difficult for us to properly «step over» lines of codes while debugging.
Step over is very common, but «step in» and «step out» (the two arrows before the Debug View Hierarchy button) are excellent for this scenario, they allow us to venture in and out of the rabbit hole effortlessly.
Xcode has tons of more debugging features, and there must be tons of “tricks” out there that developers use to familiarize themselves with existing codebases. I would love to hear about anything that I missed or don’t know about.
