《Debugging Applications》第二版：.NET与Windows调试指南

4星 · 超过85%的资源需积分: 10 91 浏览量更新于2024-08-02 收藏 8.41MB PDF 举报

"《Debugging Applications》第二版是由John Robbins撰写的一本专注于.NET和Windows应用程序调试的专业书籍。这本书深入探讨了如何调试这两种平台上的软件，是开发者解决代码问题的重要参考资料。" 在《Debugging Applications for Microsoft.NET and Microsoft Windows》第二版中，作者John Robbins将他的专业知识和经验分享给了读者，特别针对.NET框架的调试进行了详细阐述。这本书不仅涵盖了.NET程序的调试技术，同时也包含了对Microsoft Windows系统应用的调试方法。这对于那些在.NET平台上进行开发或者需要处理Windows系统级问题的程序员来说，是一份宝贵的资源。书中可能包括但不限于以下关键知识点： 1. **调试基础**：介绍调试的基本概念，如断点、单步执行、变量观察、调用堆栈分析等，帮助初学者建立调试思维。 2. **.NET调试工具**：详细讲解Visual Studio IDE中的调试功能，如使用.NET Framework的调试器（如Visual Studio Debugger）进行源代码级别的调试，以及如何利用.NET框架提供的诊断工具。 3. **异常处理**：深入讨论.NET异常机制，如何捕获和处理异常，以及如何通过调试来定位异常来源。 4. **内存和性能调试**：探讨内存泄漏检测、性能瓶颈分析等高级调试技巧，帮助开发者优化应用程序的性能。 5. **多线程调试**：针对.NET环境下的多线程编程，讲解如何跟踪和调试线程间的交互问题。 6. **远程调试**：如何设置和使用远程调试工具，以便在不同的计算机上测试和调试应用程序。 7. **Windows API调用调试**：对于那些与Windows系统紧密集成的应用，解释如何理解并调试API调用。 8. **调试策略与最佳实践**：提供一套完整的调试方法论，指导读者如何有效地定位和解决问题，减少调试时间。 9. **调试案例研究**：通过实际的案例分析，展示如何应用上述技巧解决实际开发中遇到的问题。 10. **索引与参考**：书后通常附有详细的索引，便于读者快速查找特定的调试技术或问题解决方案。该书的出版旨在帮助开发者提升他们的调试技能，无论你是.NET新手还是经验丰富的开发者，都可以从中获得有价值的洞察和技巧，从而提高软件质量并降低维护成本。由于版权原因，具体内容无法在此完全展示，但可以通过购买或合法获取电子版来获取全部信息。

corruption are the most common types of bugs. As we all know, some of these bugs are

easy to solve, and others are almost impossible. The main point to remember about

crashes and data corruption bugs is that you should never ship a product if you know it has

one of these bugs in it.

Process Bugs and Solutions

Although shipping software without bugs is possible—provided you give enough attention to

detail—I've shipped enough products to know that most teams haven't reached that level of

software development maturity. Bugs are a fact of life in this business. However, you can

minimize the number of bugs your applications have. That is what teams that ship high-

quality products—and there are many out there—do. The reasons for bugs generally fall

into the following process categories:

 Short or impossible deadlines

 The "Code First, Think Later" approach

 Misunderstood requirements

 Engineer ignorance or improper training

 Lack of commitment to quality

Short or Impossible Deadlines

We've all been part of development teams for which "management" has set a deadline that

was determined by either a tarot card reader or, if that was too expensive, a Magic 8-Ball.

Although we'd like to believe that managers are responsible for most unrealistic schedules,

more often than not, they aren't to blame. Engineers' work estimates are usually the basis

of the schedule, and sometimes engineers underestimate how long it will take them to

develop a solid product. Engineers are funny people. They are introverted but almost

always very positive thinkers. Given a task, they believe down to their bones that they can

make the computer stand up and dance. If their manager comes to them and says that they

have to add an XML transform to the application, the average engineer says "Sure, boss!

It'll be three days." Of course, that engineer might not even know how to spell "XML," but

he'll know it'll take three days. The big problem is that engineers and managers don't take

into account the learning time necessary to make a feature happen. In the section

"Scheduling Time for Building Debugging Systems" in Chapter 2, I'll cover some of the rules

that you should take into account when scheduling. Whether an unrealistic ship date is the

fault of management or engineering or both, the bottom line is that a schedule that's

impossible to meet leads to cut corners and a lower quality product.

I've been fortunate enough to work on several teams that have shipped software on time. In

each case, the development team truly owned the schedule, and we were good at

determining realistic ship dates. To figure out realistic ship dates, we based our dates on a

feature set. If the company found the proposed ship date unacceptable, we cut features to

move up the date. In addition, everyone on the development team agreed to the schedule

before we presented it to management. That way, the team's credibility was on the line to

finish the product on time. Interestingly, besides shipping on time, these products were

some of the highest quality products I've ever worked on.

The "Code First, Think Later" Approach

My friend Peter Ierardi coined the term "Code First, Think Later" to describe the all-too-

common situation in which an engineering team starts programming before they start

thinking. Every one of us is guilty of this approach to an extent. Playing with compilers,

writing code, and debugging is the fun stuff; it's why we got interested in this business in the

first place. Very few of us like to sit down and write documents that describe what we're

going to do.

If you don't write these documents, however, you'll start to run into bugs. Instead of

stopping and thinking about how to avoid bugs in the first place, you'll start tweaking the

code as you go along to work around the bugs. As you might imagine, this tactic will

compound the problem because you'll introduce more and more bugs into an already

unstable code base. The company I work for goes around the world helping debug the

nastiest problems that developers encounter. Unfortunately, many times we are brought in

to help solve corruption or performance problems and there's nothing we can do because

the problems are fundamentally architectural. When we bring the problems to the

management who hired us and tell them it's going to take a partial rewrite to fix the

problems, we sometimes hear, "We've got too big an investment in this code base to

change it now." That's a sure sign of a company that has fallen into the "Code First, Think

Later" problem. When reporting on a client, we simply report "CFTL" as the reason we were

unsuccessful when helping them.

Fortunately, the solution to this problem is simple: plan your projects. Some very good

books have been written about requirements gathering and project planning. I cite them in

Appendix B, and I highly recommend that you read them. Although it isn't very sexy and is

generally a little painful, up-front planning is vital to eliminating bugs.

One of the big complaints I got on the first version of this book was that I recommended that

you plan your projects but didn't tell you how to do it. That complaint is perfectly valid, and I

want to make sure I address the issue here in the second edition. The only problem is that I

really don't know how! Now you're wondering if I'm doing the bad author thing and leaving it

as an exercise to the reader. Read on, and I'll tell you what planning tactics have worked for

me. I hope they'll provide you with some ideas as well.

If you read my bio at the end of the book, you'll notice that I didn't get started in the software

business until I was in my late 20s and that it's really my second career. My first career was

to jump out of airplanes and hunt down the enemy, as I was a paratrooper and Green Beret

in the United States Army. If that's not preparation for the software business, I don't know

what is! Of course, if you meet me now, you'll see just a short fat guy with a pasty green

glow—a result of sitting in front of a monitor too much. However, I really did used to be a

man. I really did!

Being a Green Beret taught me how to plan. When you're planning a special operations

mission and the odds are fairly high that you could die, you are extremely motivated to do

the best planning possible. When planning one of those operations, the Army puts the

whole team in what's called "isolation." At Fort Bragg, North Carolina, the home of Special

Forces, there are special areas where they actually lock the team away to plan the mission.

The whole key during the planning was called "what if-ing yourself to death." We'd sit

around and think about scenarios. What happens if we're supposed to parachute in and we

pass the point of no return and the Air Force can't find the drop zone? What happens if we

have casualties before we jump? What happens if we hit the ground and can't find the

guerilla commander we're supposed to meet? What happens if the guerilla commander

we're supposed to meet has more people with him than he's supposed to? What happens if

we're ambushed? We'd spend forever thinking up questions and devising the answers to

these questions before ever leaving isolation. The idea was to have every contingency

planned out so that nothing was left to chance. Trust me: when there's a good chance you

might die when doing your job, you want to know all the variables and account for them.

When I got into the software business, that's the kind of planning I was used to doing. The

first time I sat in a meeting and said, "What if Bob dies before we get through the

requirements phase?" everyone got quite nervous, so now I phrase questions with a less

morbid spin, like "What if Bob wins the lottery and quits before we get through the

requirements phase?" However, the idea is still the same. Find all the areas of doubt and

confusion in your plans and address them. It's not easy to do and will drive weaker

engineers crazy, but the key issues will always pop out if you drill down enough. For

example, in the requirements phase, you'll be asking questions such as, "What if our

requirements aren't what the user wants?" Such questions will prompt you to budget time

and money to find out if those requirements are what you need to be addressing. In the

design phase, you'll be asking questions like, "What if our performance isn't good enough?"

Such questions will make you remember to sit down and define your performance goals

and start planning how you're going to achieve those goals by testing against real-world

scenarios. Planning is much easier if you can get all the issues on the table. Just be

thankful that your life doesn't depend on shipping software on time!

Debugging War Story: Severe CFTL

The Battle

A client called us in because they had a big performance problem and the ship date was

fast approaching. One of the first things we ask for when we start on these emergency

problems is a 15-minute architectural overview so that we can get up to speed on the

terminology as well as get an idea of how the project fits together. The client hustled in one

of the architects and he started the explanation on the white board.

Normally, these circle and arrow sessions take 10 to 15 minutes. However, this architect

was still going strong 45 minutes later, and I was getting confused because I needed more

than a roadmap to keep up. I finally admitted that I was totally lost and asked again for the

10-minute system overview. I didn't need to know everything; I just needed to know the high

points. The architect started again and in 15 minutes was only about 25 percent through the

system!

The Outcome

This was a large COM system, and at about this point I started to figure out what the

performance problem was. Evidently, some architect on the team had become enamored

with COM. He didn't just sip from a glass of COM Kool-Aid; he immediately started guzzling

from the 55-gallon drum of COM. In what I later guessed was a system that needed 8–10

main objects, this team had over 80! To give you an idea how ridiculous this was, it was like

every character in a string was a COM object. This thing was over-engineered and

completely under-thought. It was the classic case in which the architects had zero hands-on

experience.

After about a half a day, I finally got the manager off to the side and said that there wasn't

much we could do for performance because the overhead of COM itself was killing them.

He was none too happy to hear this and immediately blurted out this infamous phrase:

"We've got too big an investment in this code to change now!" Unfortunately, with their

existing architecture, we couldn't do much to effect a performance boost.

The Lesson

This project suffered from several major problems right from the beginning. First, team

members handed over the complete design to nonimplementers. Second, they immediately

started coding when the plan came down from on high. There was absolutely no thought

other than to code this thing up and code it up now. It was the classic "Code First, Think

Later" problem preceded by "No-Thought Design." I can't stress this enough: you have to

get realistic technology assessments and plan your development before you ever turn on

the computer.

Misunderstood Requirements

Proper planning also minimizes one of the biggest bug causers in development: feature

creep. Feature creep—the tacking on of features not originally planned—is a symptom of

poor planning and inadequate requirements gathering. Adding last-minute features,

whether in response to competitive pressure, as a developer's pet feature, or on the whim

of management, causes more bugs in software than almost anything else.

Software engineering is an extremely detail-oriented business. The more details you hash

out and solve before you start coding, the fewer you leave to chance. The only way to

achieve proper attention to detail is to plan your milestones and the implementation for your

projects. Of course, this doesn't mean that you need to go completely overboard and

generate thousands of pages of documentation describing what you're going to do.

One of the best design documents I ever created for a product was simply a series of paper

drawings, or paper prototypes, of the user interface. Based on research and on the

teachings of Jared Spool and his company, User Interface Engineering, my team drew the

user interface and worked through each user scenario completely. In doing so, we had to

focus on the requirements for the product and figure out exactly how the users were going

to perform their tasks. In the end, we knew exactly what we were going to deliver, and more

important, so did everyone else in the company. If a question about what was supposed to

happen in a given scenario arose, we pulled out the paper prototypes and worked through

the scenario again.

Even though you might do all the planning in the world, you have to really understand your

product's requirements to implement them properly. At one company where I worked—

mercifully, for less than a year—the requirements for the product seemed very simple and

straightforward. As it turned out, however, most of the team members didn't understand the

customers' needs well enough to figure out what the product was supposed to do. The

company made the classic mistake of drastically increasing engineering head count but

failing to train the new engineers sufficiently. Consequently, even though the team planned

everything to extremes, the product shipped several years late and the market rejected it.

There were two large mistakes on this project. The first was that the company wasn't willing

to take the time to thoroughly explain the customers' needs to the engineers who were new

to the problem domain, even though some of us begged for the training. The second

mistake was that many of the engineers, both old and new, didn't care to learn more about

the problem domain. As a result, the team kept changing direction each time marketing and

sales reexplained the requirements. The code base was so unstable that it took months to

get even the simplest user scenarios to work without crashing.

Very few companies train their engineers in their problem domain at all. Although many of

us have college degrees in engineering, we generally don't know much about how

customers will use our products. If companies spent adequate time up front helping their

engineers understand the problem domain, they could eliminate many bugs caused by

misunderstood requirements.

The fault isn't just with the companies, though. Engineers must make the commitment to

learn the problem domain as well. Some engineers like to think they're building tools that

enable a solution so that they can maintain their separation from the problem domain. As

engineers, we're responsible for solving the problem, not merely enabling a solution!

An example of enabling a solution is a situation in which you design a user interface that

technically works but doesn't match the way the user works. Another example of enabling a

solution is building your application in such a way that it solves the user's short-term

problem but doesn't move forward to accommodate the user's changing business needs.

When solving the user's problem rather than just enabling a solution, you, as the engineer,

become as knowledgeable as you can about the problem domain so that your software

product becomes an extension of the user. The best engineers are not those who can

twiddle bits but those who can solve a user's problem.

Engineer Ignorance or Improper Training

Another significant cause of bugs results from developers who don't understand the

operating system, the language, or the technology their projects use. Unfortunately, few

engineers are willing to admit this deficiency and seek training. Instead, they cover up their

lack of knowledge and, unintentionally, introduce avoidable bugs.

In many cases, however, this ignorance isn't a personal failing so much as a fact of life in

modern software development. So many layers and interdependencies are involved in

developing software these days that no one person can be expected to know the ins and

outs of every operating system, language, and technology. There's nothing wrong with

admitting that you don't know something. It's not a sign of weakness, and it won't take you

out of the running to be the office's alpha geek. In fact, if a team is healthy, acknowledging

the strengths and limitations of each member works to the team's advantage. By cataloging

the skills their developers have and don't have, the team can get the maximum advantage

from their training dollars. By strengthening every developer's weaknesses, the team will

better be able to adjust to unforeseen circumstances and, in turn, broaden the whole team's

skill set. The team can also schedule development time more accurately when team

members are willing to admit what they don't know. You can build in time for learning and

create a much more realistic schedule if team members are candid about the gaps in their

knowledge.

The best way to learn about a technology is to do something with that technology. Years

ago, when NuMega sent me off to learn about Microsoft Visual Basic so that we could write

products for Visual Basic developers, I laid out a schedule for what I was going to learn and

my boss was thrilled. The idea was to develop an application that insulted you,

appropriately called "The Insulter." Version 1 was a simple form with a single button that,

when pressed, popped up a random insult from the list of hard-coded insults. The second

version read insults from a database and allowed you to add new insults by using a form.

The third version connected to the company Microsoft Exchange server and allowed you to

e-mail insults to others in the company. My manager was very happy to see how and what I

was going to do to learn the technology. All your manager really cares about is being able

to tell his boss what you're doing day to day. If you give your manager that information,

you'll be his favorite employee. When I had my first encounter with .NET, I simply dusted off

the Insulter idea, and it became Insulter .NET!

I'll have more to say about what skills and knowledge are critical for developers to have in

the section "Prerequisites to Debugging" later in this chapter.

Common Debugging Question: Should we do code reviews?

Absolutely! Unfortunately, many companies go about them in completely the wrong way.

One company I worked for required formal code reviews that were straight out of one of

those only-in-fantasyland software engineering textbooks I had in college. Everything was

role-based: there was a Recorder for recording comments, a Secretary for keeping the

meeting moving, a Door Keeper to open the door, a Leader to suck oxygen, and so on. All

that you really had, however, were 40 people in a room, none of whom had read the code.

It was a huge waste of time.

The kind of code reviews I like are the one-on-one informal kind. You simply sit down with a

printout of the code and read it line by line with the developer. As you read it, you're

剩余720页未读，继续阅读

Fypher

粉丝: 2
资源: 12

《Debugging Applications》第二版：.NET与Windows调试指南

最新资源