首页 > > > Debug It! Find Repair and Prevent Bugsin Your C…

Debug It! Find Repair and Prevent Bugsin Your Code Paul Butcher.pdf

Debug It! Find Repair and Preve…

上传者: macware 2014-02-14 评分1 评论0 下载1 收藏10 阅读量680 暂无简介 简介 举报

简介:本文档为《Debug It! Find Repair and Prevent Bugsin Your Code Paul Butcherpdf》,可适用于软件工程领域,主题内容包含WhatReadersAreSayingAboutDebugIt!Pauldoesanexcellentjobofexplainingthetech符等。

What Readers Are Saying About Debug It! Paul does an excellent job of explaining the technical, intellectual, and psychological aspects of all phases of debugging: preventing bugs in the first place, diagnosing and fixing bugs, and making sure that the same bugs don’t happen again. Applying any or all of the ideas from this book will improve the overall quality of your software projects. Sure, the technical issues are well covered but how Paul also explains the psychological angles is what makes this book exceptional. Frederic Daoud Author, Stripes...and Java Web Development Is Fun Again I wholeheartedly recommend this book to software engineers generally but more specifically to team leads who need to know how to set up their teams for best practice. Allan McLeod Founder and CTO, Isaacc Software Debug It! does a great job of setting the scene for debugging and get- ting you into the right mind-set while also talking about the complica- tions that can arise once the bug is found and squashed. It’s worth a look for the anecdotes alone, to see the lengths that people go to when trying to understand truly bizarre defects. Jon Dickinson Author, Grails 1.1 Web Application Development Debugging has been a folk art for so long that it’s great to have some- one put all the tried-and-true techniques together. Debug It! is the perfect book to pull out when you’re disillusioned with the brain- breaking process of creating good software. With this tool chest of assertions, logging, refactoring, and other good stuff, you’ll feel like you’re Sherlock Holmes and solving the case is inevitable. Craig Riecke Author, Mastering Dojo: JavaScript and Ajax Tools for Great Web Experiences Prepared exclusively for Robert Walsh Download at WoweBook.Com This book is like a companion volume to The Pragmatic Programmer, applying the same focus on craftsmanship to the debugging process. Ian Dees Author, Scripted GUI Testing with Ruby Paul Butcher has brought long overdue attention to the methods of debugging, a fundamental activity for every software developer yet one that remains an exercise of intuition and guesswork for most in the profession. Paul’s gentle writing style belies the discipline in his tech- nique. Before you know it, you’ll be an engineer instead of a hacker. Bill Karwin Software Engineer, Karwin Software Solutions, LLC Prepared exclusively for Robert Walsh Download at WoweBook.Com Prepared exclusively for Robert Walsh Download at WoweBook.Com Debug It! Find, Repair, and Prevent Bugs in Your Code Paul Butcher The Pragmatic Bookshelf Raleigh, North Carolina Dallas, Texas Prepared exclusively for Robert Walsh Download at WoweBook.Com Many of the designations used by manufacturers and sellers to distinguish their prod- ucts are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers, LLC. Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein. Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://www.pragprog.com Copyright 2009 Paul Butcher. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmit- ted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America. ISBN-10: 1-934356-28-X ISBN-13: 978-1-934356-28-9 Printed on acid-free paper. P1.0 printing, November 2009 Version: 2009-11-4 Prepared exclusively for Robert Walsh Download at WoweBook.Com Contents Preface 10 About This Book . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . 11 I The Heart of the Problem 13 1 A Method in the Madness 14 1.1 Debugging Is More Than “Making the Bug Go Away” . 14 1.2 The Empirical Approach . . . . . . . . . . . . . . . . . . 16 1.3 The Core Debugging Process . . . . . . . . . . . . . . . 17 1.4 First Things First . . . . . . . . . . . . . . . . . . . . . . 18 1.5 Put It in Action . . . . . . . . . . . . . . . . . . . . . . . 22 2 Reproduce 23 2.1 Reproduce First, Ask Questions Later . . . . . . . . . . 23 2.2 Controlling the Software . . . . . . . . . . . . . . . . . . 25 2.3 Controlling the Environment . . . . . . . . . . . . . . . 26 2.4 Controlling Inputs . . . . . . . . . . . . . . . . . . . . . 28 2.5 Refining Your Reproduction . . . . . . . . . . . . . . . . 36 2.6 What If You Really Can’t Reproduce It? . . . . . . . . . 45 2.7 Put It in Action . . . . . . . . . . . . . . . . . . . . . . . 48 3 Diagnose 49 3.1 Stand Back—I’m Going to Try Science . . . . . . . . . . 49 3.2 Stratagems . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.3 Debuggers . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.4 Pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.5 Mind Games . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.6 Validate Your Diagnosis . . . . . . . . . . . . . . . . . . 72 3.7 Put It in Action . . . . . . . . . . . . . . . . . . . . . . . 73 Prepared exclusively for Robert Walsh Download at WoweBook.Com CONTENTS 8 4 Fix 74 4.1 Clearing the Decks . . . . . . . . . . . . . . . . . . . . . 75 4.2 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.3 Fix the Cause, Not the Symptoms . . . . . . . . . . . . 78 4.4 Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.5 Checking In . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.6 Get Your Code Reviewed . . . . . . . . . . . . . . . . . . 83 4.7 Put It in Action . . . . . . . . . . . . . . . . . . . . . . . 84 5 Reflect 85 5.1 How Did It Ever Work? . . . . . . . . . . . . . . . . . . . 85 5.2 What Went Wrong? . . . . . . . . . . . . . . . . . . . . . 86 5.3 It’ll Never Happen Again . . . . . . . . . . . . . . . . . . 89 5.4 Close the Loop . . . . . . . . . . . . . . . . . . . . . . . . 92 5.5 Put It in Action . . . . . . . . . . . . . . . . . . . . . . . 93 II The Bigger Picture 94 6 Discovering That You Have a Problem 95 6.1 Tracking Bugs . . . . . . . . . . . . . . . . . . . . . . . . 95 6.2 Working with Users . . . . . . . . . . . . . . . . . . . . . 100 6.3 Working with Support Staff . . . . . . . . . . . . . . . . 105 6.4 Put It in Action . . . . . . . . . . . . . . . . . . . . . . . 107 7 Pragmatic Zero Tolerance 108 7.1 Bugs Take Priority . . . . . . . . . . . . . . . . . . . . . 108 7.2 The Debugging Mind-Set . . . . . . . . . . . . . . . . . . 111 7.3 Digging Yourself Out of a Quality Hole . . . . . . . . . . 113 7.4 Put It in Action . . . . . . . . . . . . . . . . . . . . . . . 118 III Debug-Fu 119 8 Special Cases 120 8.1 Patching Existing Releases . . . . . . . . . . . . . . . . 120 8.2 Backward Compatibility . . . . . . . . . . . . . . . . . . 121 8.3 Concurrency . . . . . . . . . . . . . . . . . . . . . . . . . 126 8.4 Heisenbugs . . . . . . . . . . . . . . . . . . . . . . . . . 128 8.5 Performance Bugs . . . . . . . . . . . . . . . . . . . . . 130 8.6 Embedded Software . . . . . . . . . . . . . . . . . . . . . 132 8.7 Bugs in Third-Party Software . . . . . . . . . . . . . . . 135 8.8 Put It in Action . . . . . . . . . . . . . . . . . . . . . . . 140 Report erratum this copy is (P1.0 printing, November 2009) Prepared exclusively for Robert Walsh Download at WoweBook.Com CONTENTS 9 9 The Ideal Debugging Environment 141 9.1 Automated Testing . . . . . . . . . . . . . . . . . . . . . 141 9.2 Source Control . . . . . . . . . . . . . . . . . . . . . . . 144 9.3 Automatic Builds . . . . . . . . . . . . . . . . . . . . . . 149 9.4 Put It in Action . . . . . . . . . . . . . . . . . . . . . . . 157 10 Teach Your Software to Debug Itself 158 10.1 Assumptions and Assertions . . . . . . . . . . . . . . . 158 10.2 Debugging Builds . . . . . . . . . . . . . . . . . . . . . . 168 10.3 Resource Leaks and Exception Handling . . . . . . . . 173 10.4 Put It in Action . . . . . . . . . . . . . . . . . . . . . . . 180 11 Anti-patterns 181 11.1 Priority Inflation . . . . . . . . . . . . . . . . . . . . . . . 181 11.2 Prima Donna . . . . . . . . . . . . . . . . . . . . . . . . . 182 11.3 Maintenance Team . . . . . . . . . . . . . . . . . . . . . 184 11.4 Firefighting . . . . . . . . . . . . . . . . . . . . . . . . . . 186 11.5 Rewrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 11.6 No Code Ownership . . . . . . . . . . . . . . . . . . . . . 189 11.7 Black Magic . . . . . . . . . . . . . . . . . . . . . . . . . 189 11.8 Put It in Action . . . . . . . . . . . . . . . . . . . . . . . 190 A Resources 192 A.1 Source Control and Issue-Tracking Systems . . . . . . 192 A.2 Build and Continuous Integration Tools . . . . . . . . . 195 A.3 Useful Libraries . . . . . . . . . . . . . . . . . . . . . . . 197 A.4 Other Tools . . . . . . . . . . . . . . . . . . . . . . . . . 199 B Bibliography 203 Index 205 Report erratum this copy is (P1.0 printing, November 2009) Prepared exclusively for Robert Walsh Download at WoweBook.Com Preface I’ve always been mystified why so few books are available on debugging. You can buy any number on every other aspect of software engineering such as design, code construction, requirements capture, methodolo- gies...the list is endless. And yet, for some reason, debugging has been almost (not quite but very nearly) ignored by authors and publishers. I hope that this book can help remedy the situation. If you write code, it’s a certainty that at some point (possibly very soon afterward) you’re going to have to debug it. Debugging is, more than anything else, an intellectual process—it doesn’t take place within a debugger or your code but inside your mind. Reaching an understand- ing of the root cause of the problem is the cornerstone upon which everything else depends. Over the years, I’ve been fortunate to work with a number of incredi- bly talented teams on a wide range of software. I’ve worked at all levels of abstraction from microcode on bit-slice processors through device drivers, embedded code, mainstream desktop software, and web appli- cations. I hope that I can pass along some of the lessons I’ve learned from my colleagues along the way. About This Book This book is divided into three parts, each of which considers a partic- ular aspect of debugging: “The Heart of the Problem”: This part introduces the empirical approach, which leverages our software’s unique ability to show us what’s going on, and the core debugging method (reproduce, diagnose, fix, reflect) that relies upon it. Prepared exclusively for Robert Walsh Download at WoweBook.Com ACKNOWLEDGMENTS 11 “The Bigger Picture”: How do we find out that there’s a problem that needs fixing in the first place? And how does debugging integrate into the wider software development process? “Debug-Fu”: In the third and final part, we’ll turn our attention to a number of advanced topics: • Although the approaches discussed earlier in the book apply to all bugs, certain types of bugs benefit from special treat- ment. • Debugging starts long before the irate telephone call from the user affected by it. What tools and processes can we put in place ahead of time to help when the phone rings? • Finally, we’ll consider a number of common pitfalls to avoid. Acknowledgments It’s not until I embarked upon the task of writing a book of my own that I realized the true importance of the acknowledgments section. My name might be on the front cover, but it wouldn’t have come to fruition without the help of many and the forbearance of many more. Thanks to everyone who joined the book’s email discussion list and provided inspiration, criticism, and encouragement—Andrew Eacott, Daniel Winterstein, Freeland Abbott, Gary Swanson, Jorge Hernandez, Manuel Castro, Mike Smith, Paul McKibbin and Sam Halliday. Partic- ular thanks to Dave Strauss, Dominic Binks, Frederick Cheung, Mar- cus Gröber, Sean Ellis, Vandy Massey, Matthew Jacobs, Bill Karwin, and Jeremy Sydik who have kindly allowed me to share their anec- dotes and insights with you. Thanks also to Allan McLeod, Ben Coppin, Miguel Oliveira, Neil Eccles, Nick Heudecker, Ron Green, Craig Riecke, Fred Daoud, Ian Dees, Evan Dickinson, Lyle Johnson, Bill Karwin, and Jeremy Sydik for taking the time to participate in technical review. To my editor, Jackie Carter, thank you for being so patient with a first- time author learning the ropes, and thanks to Dave and Andy for taking the chance. Report erratum this copy is (P1.0 printing, November 2009) Prepared exclusively for Robert Walsh Download at WoweBook.Com ACKNOWLEDGMENTS 12 Apologies to my colleagues at Texperts who have had to endure me talking about nothing but the book for too long (don’t worry—I’ll get a new race car soon, and then you’ll have to endure me talking about that instead). And to my family, sorry for the long evenings and weekends during which I’ve been incommunicado, and thanks for the support. Finally, thank you to everyone I’ve had the privilege of working with over the years. The best aspect of a career in software development is the caliber of the people, and I’ve been particularly lucky to work with a truly great selection. Paul Butcher August 2009 paul@paulbutcher.com Report erratum this copy is (P1.0 printing, November 2009) Prepared exclusively for Robert Walsh Download at WoweBook.Com Part I The Heart of the Problem Prepared exclusively for Robert Walsh Download at WoweBook.Com Chapter 1 A Method in the Madness So, your software doesn’t work. Now what? Some developers seem to have a knack of unerringly zeroing in on the root cause of a bug, whereas others thrash around apparently aimlessly and without concrete results. What separates the first group from the second? In this chapter, we will examine a debugging method that has been repeatedly proven in the trenches of professional software development. It’s not a silver bullet—you’re still going to have to rely on your intellect, intuition, detective skills, and, yes, even a little luck. But it will allow you to target your efforts most effectively, avoid chasing phantoms, and get to the heart of the problem as quickly as possible. Specifically, we’ll cover the following: • The difference between debugging and “making the bug go away” • The empirical approach—using the software itself to show you what’s going on • The core debugging process (reproduce, diagnose, fix, reflect) • First things first—things to think about before diving in 1.1 Debugging Is More Than “Making the Bug Go Away” Ask an inexperienced programmer to define debugging, and they might answer that it is “finding a fix.” In fact, that is only one of several goals, and not even the most important of them. Prepared exclusively for Robert Walsh Download at WoweBook.Com DEBUGGING IS MORE THAN “MAKING THE BUG GO AWAY” 15 Effective debugging requires that we take these steps: 1. Work out why the software is behaving unexpectedly. 2. Fix the problem. 3. Avoid breaking anything else. 4. Maintain or improve the overall quality (readability, architecture, test coverage, performance, and so on) of the code. 5. Ensure that the same problem does not occur elsewhere and can- not occur again. Of these, by far the most important is the first—identifying the root cause of the problem is the cornerstone upon which everything else depends. Understanding Is Everything Inexperienced developers (and sometimes, unfortunately, those of us who should know better) often skip diagnosis altogether. Instead, they immediately implement what they think might be a fix. If they’re lucky, it won’t work, and all they will have done is waste their time. The real danger comes if it works, or seems to work, because now they’ve made a change to the source that they don’t really understand. It might fix the bug, but there is a real chance that in reality it is only masking the true underlying cause. Worse, there is a good chance that this kind of change will introduce regressions—breaking something that used to work correctly beforehand. Wasted Time and Effort Some years ago, I found myself working in a team containing a number of very experienced and talented developers. Most of their experience was with UNIX, but when I joined the team, they were in the late stages of porting the software to Windows. One of the bugs found during the port was a performance issue when running many threads simultaneously. Some threads were being starved, while others were running just fine. Given that everything worked just fine under UNIX, the problem was clearly broken threading in Windows, so the decision was made to implement a custom thread scheduling system and avoid using that provided by the operating system. This would be a lot of work, obviously, but quite within the capabilities of a team of this caliber. Report erratum this copy is (P1.0 printing, November 2009) Prepared exclusively for Robert Walsh Download at WoweBook.Com THE EMPIRICAL APPROACH 16 I joined the team when they were some way into the implementation, and sure enough, threads were no longer suffering from starvation. But thread scheduling is subtle, and they were still working through a number of issues that had been caused by the change (not least of which was that the changes had slowed the whole system down somewhat). I was intrigued by this bug, because I’d previously experienced no problems with Windows’ threading. A little investigation demonstrated that the performance issue was caused by the fact that Windows implements a dynamic thread priority boost. The bug could be fixed by disabling this with a single line of code (a call to SetThreadPriorityBoost( )). The moral? The team had decided that Windows’ threads were broken without really investigating the behavior they were seeing. In part, this might have been a cultural issue—Windows doesn’t have a good reputation among UNIX hackers. Nevertheless, if they had taken the time to identify the root cause, they would have saved themselves a great deal of work and avoided introducing complications that made the system both less efficient and more error-prone. Without first understanding the true root cause of the bug, we are out- side the realms of software engineering and delving instead into voodoo programming1 or programming by coincidence.2 1.2 The Empirical Approach There are many different approaches you can adopt to gain the under- standing you seek. And as long as the approach you choose gets you closer to your goal, it has served its purpose. Having said that, it turns out that in most instances one particular approach, the empirical approach, tends to be by far the most produc- tive. Construct experiments, and observe the results. Empiricism relies upon observation or expe- rience, rather than theory or pure logic. In the context of debugging, this means directly observing the behavior of the software. Yes, you could read the entire source code and use pure reason to work out what’s going on (and on occasion you may have no other choice), 1. “The use by gues

该用户的其他资料

  • 名称/格式
  • 评分
  • 下载次数
  • 资料大小
  • 上传时间

用户评论

0/200
    暂无评论
上传我的资料

相关资料

资料评价:

/ 218
所需积分:2 立即下载
返回
顶部
举报
资料
关闭

温馨提示

感谢您对爱问共享资料的支持,精彩活动将尽快为您呈现,敬请期待!