调试艺术：从重现到修复的全面指南

需积分: 0 169 浏览量更新于2024-07-22 收藏 2.05MB PDF 举报

"DebugIt.pdf" 是一本关于调试软件错误的深入指南，涵盖了从问题核心、重现错误、诊断、修复到反思的整个调试过程。作者强调了调试不仅仅是消除错误，而是一种系统性的、科学的方法。在第一部分"问题的核心"中，作者指出调试不仅仅是让错误消失，它更是一个通过实证方法来理解并解决复杂问题的过程。调试的核心流程包括明确优先级、实际操作等步骤。书中鼓励读者将这些理论付诸实践，以提高工作效率。第二部分"复现问题"探讨了如何在可控的条件下重现软件故障，包括控制软件行为、环境因素以及输入数据。这一章强调了即使在无法完全复现的情况下，也要努力细化复现过程，并提供了应对策略。第三部分"诊断"中，作者提倡使用科学方法来分析问题，提出了各种策略，如使用调试器，并警告了可能遇到的陷阱。此外，还讨论了如何验证诊断结果，确保找到问题的根本原因。第四部分"修复"讨论了如何清理工作环境，测试修复方案，以及如何正确处理症状与原因的区别。书中有提到重构代码的重要性，以及提交代码前进行代码审查的必要性。第五部分"反思"鼓励开发者思考为何问题会发生，出错的原因是什么，并采取措施防止未来再次发生。这包括关闭反馈循环，以确保团队可以从错误中学习和成长。第二部分"更大的图景"探讨了如何发现存在的问题，如何与用户和技术支持合作，以及实施务实的零容忍政策，将错误视为优先处理事项，培养调试思维，并从中恢复软件质量。第三部分"Debug-Fu"则关注特殊案例，如修补已发布的版本、兼容性问题、并发问题、Heisenbugs（难以稳定复现的错误）、性能问题、嵌入式软件的调试，以及第三方软件中的错误。每一章都提供了实际行动建议。最后，第九部分介绍了理想的调试环境，包括自动化测试、源代码控制、自动构建等，这些都是提高软件质量和调试效率的关键要素。第十部分讨论了如何让软件自我调试，利用断言和调试构建来提前预防和解决问题。 "DebugIt!"是一本全面而深入的调试手册，适合所有级别的软件工程师，特别是团队领导，帮助他们建立最佳实践，提升软件项目的整体质量。书中丰富的案例和实用技巧将使读者对调试有更全面的认识。

THE EMPIRICAL APPROACH 16

I joined the team when they were some way into the implementation, and

sure enough, threads were no longer su ffering from starvation. But

thread scheduling is subtle, and they were still working thr ough 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 pr eviously 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 ﬁxed 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 introduc ing complications that made the system both

less efﬁcient and more error-prone.

Without ﬁrst understanding the true root cause of the bug, we are out-

side the realms of software engineering and delving instead in to voodoo

programming

or programming by coincidence.

1.2 The Empirical Approach

There ar e many dif ferent approaches you can adopt to gain the under-

standing you seek. And as long as the appr oach you choose gets you

closer to your goal, it has ser ved its purpose.

Having said that, it turns out that in most instances one part i cular

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 softw are. 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 guess or cookbook of an obscure or hairy system, feature, or algorithm

that one does not truly understand. The implication is that the technique may not work,

and if it doesn’t, one will never know why.” Taken from The Jargon File [ray].

. See The Pragmatic Programmer [HT00].

Report erratum

this copy is (P1.0 printing, November 2009)

Prepared exclusively for Robert Walsh

Download at WoweBook.Com

THE CORE DEBUGGING PROCESS 17

On the Nature of Software

Software is remarkable stuff. Sometimes, perhaps because we

work with it all the time, we forget just how remarkable it is .

Very little else in human experi ence is as malleable, allowing

us free rein to exercise our ingenuity and inventiveness almost

without limits. Also, with a very few exceptions that we’ll cover

later, software is deterministic—the next state is completely

determ ined by the current state, and (crucially) we have com-

plete access to all of that state whenever we want it.

Compared to traditional engin eeri ng, we are spoiled. What

do you think a Formula One engineer would give to be ab le

to instantaneously stop an engine when it’s rotating at 19,000

revolutions per minute and examine every aspect of it in

minute detail? To see the precise state of each component

whil e under pressure and stress, for exa mple, or to dyna mically

record the shape and position of the ﬂame front within the

combustion ch ambers during i gnition?

It is exactly this kind of trick that we are able to perform with our

software, which is why the empirical app roach is particularly

powerful when debugging.

but doing so is usually inefﬁcient and dangerous. You can track the

problem down much more effectively by carefully constructing experi-

ments and observing how the software behaves. Not only is this faster,

but these observations force you to reexamine ﬂawed assumptions in

your mental model about how the software behaves. The software itself

is the most powerful tool in your toolbox—allow it to show you what’s

going on.

The method described in the next section leverages this approach to

provide a structured means of zeroing i n on your quarry.

1.3 The Co r e Debugging Process

The core of the debugging process consists of four steps:

Reproduce:

Find a way to reliably and conveniently reproduce the problem on

demand.

Report erratum

this copy is (P1.0 printing, November 2009)

Prepared exclusively for Robert Walsh

Download at WoweBook.Com

FIRST THINGS FIRST 20

Battling Bug Reports

I once found myself working on a very simple bug—a report was being

generated without taking daylight saving time (DST) into account and was

therefor e incorrect when the clocks changed. I implemented a nice quick

ﬁx, and I moved on to the next problem.

A little later, however, another bug was reported saying that our

accountant can’t make the books balance. The numbers generated by the

report didn’t agree with the invoices we wer e receiving from our suppliers.

Sure enough, it turned out that these invoices didn’t take DST into

account, which explains the discrepancy. A little historical digging

showed that we had already discovered this a year ago, at which point

we’d addre ssed the problem by deliberately ignoring DST.

Clearly, the problem here wasn’t that the software wasn’t doing what we

wanted it to do but that we didn’t know what we wanted the software to

do. Because the report was used in different contexts, in some cases DST

should be taken into account, and in others it shouldn’t. The correct

solution was to add an option to the report to allow the user to choose.

One Problem at a Time

It’s sometimes tempting, when faced with several problems, t

o work on

them in parallel. This is especially true if the bugs are all in the same

general area. Don’t give in to this temptation.

Debugging is difﬁcult enough without “muddying the waters” unneces-

sarily. However careful you are, there’s a good chance th at the experi-

ments you perform to try to track down one bug will in terfere in some

way with the other. This makes it h ard to come to a clear understanding

of what’s happening. In addition (as we will see in Section 4.5, C

heck-

ing In, on page 82), when you eventually come to check in your ﬁx, you

want to stick to one check-in per logical change. This is very difﬁcult to

achieve if you work on several bugs simultaneously.

Occasionally, you’ll ﬁnd that what you thought was one bug turns out

to have more than one root cause. Normally, th e point at which this

becomes obvious is when you ﬁnd yourself in the twilight zone—weird

things happening that seem to have no obvious explanation. See Sec-

tion 3.4, M

ultiple Causes, on page 65 for further discussion.

3. Incidentally, the developer who originally cha nged the behavior could have sa ved us

quite a bit of trouble by simply adding a comment in the code explaining why DST was

ignored in this instance, making it clear that the behavior was intentional.

Report erratum

this copy is (P1.0 printing, November 2009)

Prepared exclusively for Robert Walsh

Download at WoweBook.Com

剩余215页未读，继续阅读

shiyoumaomao

粉丝: 9
资源: 40

调试艺术：从重现到修复的全面指南

SSD在分布式文件系统中的应用场景及方案对比.pdf

使用VC进行调试的一些技巧

基于Matlab面板版的卡尔曼小球运动跟踪[Matlab面板版].zip

Day01(1).py

面试-PHP高频面试题整理-面试题合集.zip

(最新整理)中国企业OFDI微观数据2005-2022年

毕业设计论文SpringBoot+Vue茶叶销售系统.docx

用于计算贴片天线的基本参数matlab代码.rar

毕业设计论文SpringBoot+Vue二手书籍交易系统.docx

毕业设计论文SpringBoot+Vue电子印章管理系统.docx

最新资源