Let’s talk about program bugs and debugging. Everybody has own methods and growing intuition, but let me suggest generally – methods are similar. When it’s a hiding bug in the code, everybody sets a breakpoint or a set of breakpoints, then debug step by step – line by line, dive in and out. Boring.
Another way is to use NSLog to see probably key parameters’ value as a log output. Then run hundreds of time and try to repeat bugs and see what values are returned. Could take a lot of time also.
And the third and the most easy way of debugging is Visual Debugging as I call it. It’s not commonly applied but can save hours sometime.
Assume we have a mistake in UIImage coordinates calculation or UIView layer sequence. According to the standard methods it’s possible to set 10 breakpoints, then filter and leave just a few of them, and finally find a bug. Or we can set NSLogs after every Init or setFrame: and then try to make a million calculations in the mind to understand where has screwed up. It usually takes more than a few minutes.
But there is a special way to solve such kind of problems – Visual Debuging.
This weekend we updated a GPS Speed – some UI enhancements, better retina support, one new indicator and InApp store support. Since we recreated graphics and moved controls, a few of them lost their right positions and sizes. Last time I’ve spent two hours to check all math because of similar problem and no desire to repeat.
The best way to find want’s wrong is to simplify UI and colorize problematic parts. Just look how obvious it’s. Took minutes to understand the problem and its solutions.
The speed and the max speed arrows had wrong center and size because some not obvious changes in design. It’s even hard to find this visual bug because visual part of the indicators are rotated and smaller than its original size.