This book provides a structured approach that will help programmers to identify and remove bugs in code. It is based on a four steps process: Reproduce, Diagnose, Fix, Reflect. For each activity, the author provides practical material on how perform it. The second part gives a higher vision of the debugging process and deal with topics like communicating with users or prioritizing bugs treatment. Finally, the book discusses special situations and the relationship between bugs and other areas of software development (source control, build, etc.).
The book is easy to read and the material is presented in a very structured way with different “viewpoints” that help to understand the content. Besides the main text where important concepts are put in evidence, real life cases shows how things happen in the real world. There are also some “Joe asks…” sections where the author answer pertinent questions on the current topic.
With my many years of experience in supporting and debugging large existing enterprise systems, I have to say that Paul Butcher summarize and structure all the knowledge (and more) that I have, sometimes painfully, accumulated during this activity. This is therefore an excellent book that I will recommend to everybody that is involved in software development in general and maintenance activities specifically.
Reference: “Debug It!”, Paul Butcher, Pragmatic Bookshelf, 214 pages, ISBN 978-1934356289
Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk
“Bug fixing often uncovers opportunities for refactoring. The very fact that you’re working with code that contains a bug indicates that there is a chance that it could be clearer or better structured.”
“As a rule of thumb, for every user who tells you about a problem, there will be between 10 and 100 other users who experienced the same problem and didn’t think to get in touch.”
“Once you start to get on top of your quality issues, you’re going to want to start refactoring the old, crufty, untested code. And you should – the point of exercise is to clean up problems, and refactoring is a key element of that process. Remember, however, that refactoring crucially depends upon the support of an extensive suite of automated tests. Without tests, you’re not refactoring. You’re hacking. So, how do you refactor untested code? You don’t. The first thing you do is to write the tests.”