| Effective Debugging |
|
Author: Diomidis Spinellis Programming is 90% debugging so even a little improvement in effectiveness is worth it. The joke has it that the other 10% is creating the bugs in the first place. This is a book you will enjoy reading, but it might not do very much for your debugging abilities in the real world. It is the sort of book that is motivating. It makes you think hard about things you have been doing and, while it might not get to grips with the details of debugging, it makes you feel that you are better equipped. As with other titles in the Addison-Wesley Effective series, the format of this book is a set of tips (Items) arranged into chapters. In this case there are "66 specific ways to debug software and systems" arranged into eight chapters. Chapter 1 is about high level strategies and this is sad because these are some of the weakest items in the book - still good enough to read though. For example most of us don't need the advice to use an issue tracking system. We probably do need help selecting one but the this is not what the essay is about. The remaining items in the chapter are about strategy - work from the top down or bottom up, compare a working system with a broken one, focus on the most important problems. All well written, worth reading and enjoyable but unless you are particulary inept or a very complete beginner you probably won't inprove your debugging performance.
Chapter 2 is on general purpose practices and methods. This is about how to generally equip yourself for debugging success. Overall it's a bit of a mess of topics put together. Chapter 3 focuses on tools mostly Unix tools you don't get a tutorial on using any particular software in this book. Chapter 4 is more practical and outlines the use of a debugger to step though code and set breakpoints of various kinds. Even here there is not much sign of a hands on experience. For example, Item 34 is "know how to attach a debugger to a running process" not "how to attach a debugger to a running process". Chapter 5 is about programming techniques and includes just obvious advice as "use assertions", "go over code with a colleague", "use tests" and so on. Chapter 6 explains compile time techniques giving the advice "use a static program analyser". Obviously after compile time we have Chapter 7 on run time, but for me this has already been dealt with in earlier items on using a debugger, which is of course the main run time debugging mode. Chapter 8 brings the book to a close with a look at debugging multi-threaded code which is perhaps the most difficult thing to do. Again there are no solutions provided that are going to get you out of difficulty with a real problem. You might find my emphasis on there being little hands-on practical debugging in this book off-putting. I need to say that I really enjoyed reading this book and I'm sure you will too, but debugging isn't really something that you can learn to do better by reading something as general as this. It is a lot like reading about playing a sport - it is motivational and you might pick up minor hints, but at the end of the day you have to do it and do it and do it again to actually get better at it. So it is with debugging and, while you do learn the to look out for the common bugs in a given language or an applications area, the fact of the matter is that when you are confronted with a slightly difficult, out of the ordinary, bug, how you solve it is a unique as the bug itself. In programming we have many more ways of getting things wrong than doing it right. One thing that surprises me is that nowhere in the book is there a statement of the general principle of debugging, which is roughly speaking that you will find the bug at the first location in the program where your expectations for what the program is doing and what the program is actually doing diverge. In this respect debugging is a a lot like doing science - you put up a hypothesis, i.e. what you expect, and you do an experiment to disprove the hypothesis. As soon as you succeed in finding the discrepancy you have the bug. See: Debugging and the Experimental Method. As long as you take the book in the right spirit, and don't expect solutions from it, I can recommend it as a good read. You won't necessarily be a better debugger after reading it, but you will try harder.
To keep up with our coverage of books for programmers, follow @bookwatchiprog on Twitter or subscribe to I Programmer's Books RSS feed for each day's new addition to Book Watch and for new reviews. 
|
|||
| Last Updated ( Friday, 25 November 2016 ) |