Code Leader Using People, Tools, and Processes to Build Successful Software phần 1 pps

Simpo PDF Merge and Split Unregistered Version -
Code Leader
Using People, Tools, and Processes to
Build Successful Software
Patrick Cauldwell
Wiley Publishing, Inc.
Simpo PDF Merge and Split Unregistered Version -
Simpo PDF Merge and Split Unregistered Version -
Code Leader
Acknowledgments xv
Introduction
xxi
Part I: Philosophy
1
Chapter 1: Buy, Not Build
3
Chapter 2: Test-Driven Development
11
Chapter 3: Continuous Integration
21
Part II: Process
41
Chapter 4: Done Is Done
43
Chapter 5: Testing
57
Chapter 6: Source Control
107
Chapter 7: Static Analysis
135
Part III: Code Construction

145
Chapter 8: Contract, Contract, Contract!
147
Chapter 9: Limiting Dependencies
159
Chapter 10: The Model-View-Presenter (MVP) Model
173
Chapter 11: Tracing
189
Chapter 12: Error Handling
199
Part IV: Putting It All Together
211
Chapter 13: Calculator Project: A Case Study
213
Index
223
Simpo PDF Merge and Split Unregistered Version -
Simpo PDF Merge and Split Unregistered Version -
Code Leader
Simpo PDF Merge and Split Unregistered Version -
Simpo PDF Merge and Split Unregistered Version -
Code Leader
Using People, Tools, and Processes to
Build Successful Software
Patrick Cauldwell
Wiley Publishing, Inc.
Simpo PDF Merge and Split Unregistered Version -
Code Leader: Using People, Tools, and Processes to
Build Successful Software

Published by
Wiley Publishing, Inc.
10475 Crosspoint Boulevard
Indianapolis, IN 46256
www.wiley.com
Copyright © 2008 by Wiley Publishing, Inc., Indianapolis, Indiana
Published simultaneously in Canada
ISBN: 978-0-470-25924-5
Manufactured in the United States of America
10987654321
Library of Congress Cataloging-in-Publication Data is available from the publisher.
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form
or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise , except as
permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior
written permission of the Publisher, or authorization through payment of the appropriate per-copy fee
to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978)
646-8600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley
Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or
online at
/>.
Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or
warranties with respect to the accuracy or completeness of the contents of this work and specifically
disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No
warranty may be created or extended by sales or promotional materials. The advice and strategies
contained herein may not be suitable for every situation. This work is sold with the understanding that
the publisher is not engaged in rendering legal, accounting, or other professional services. If professional
assistance is required, the services of a competent professional person should be sought. Neither the
publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or
Website is referred to in this work as a citation and/or a potential source of further information does not
mean that the author or the publisher endorses the information the organization or Website may provide

or recommendations it may make. Further, readers should be aware that Internet Websites listed in this
work may have changed or disappeared between when this work was written and when it is read.
For general information on our other products and services p lease contact our Customer Care Depart-
ment within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317)
572-4002.
Trademarks: Wiley, the Wiley logo, Wrox, the Wrox logo, Wrox Programmer to Programmer, and related
trade dress are trademarks o r registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the
United States and other countries, a nd may not be used without written permission. All other trademarks
are the property of their respective owners. Wiley Publishing, Inc. is not associated with any product or
vendor mentioned in this book.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may
not be available in electronic books.
Simpo PDF Merge and Split Unregistered Version -
To my wife Vikki, who has supported me through many wacky endeavors, taken up the slack
when I’ve overcommitted myself, and generally been the best wife and mother ever.
Simpo PDF Merge and Split Unregistered Version -
Simpo PDF Merge and Split Unregistered Version -
About the Author
Patrick Cauldwell somehow found his way to a career in software despite earning a bachelor’s degree
in East Asian Studies. From a work-study job in the student computer lab at college through early jobs
in quality assurance and localization, and finally into full-time software engineering, Patrick has always
been interested in what makes computers tick. He’s worked in a wide range of software operations, from
very large projects at Intel to a very small start-up to a consulting job in the midst of the .COM boom.
Patrick pursues his passion for talking and writing about software development as often as possible.
He teaches computer science classes at the Oregon Institute of Technology, speaks at numerous devel-
oper conferences across the country, and once talked about the challenges of building a highly scalable
eCommerce web site as part of a 12-city developer road show.
After working for several product companies, Patrick recently returned to consulting full time.
Simpo PDF Merge and Split Unregistered Version -
Simpo PDF Merge and Split Unregistered Version -

Foreword
I have worked with Patrick Cauldwell, in one form or another, at two different companies for more than
half of my 15-year career in software. He has been almost a constant in my professional life, and I am a
better programmer for working with him. Why am I telling you this, dear reader, and why should you
care? Because you should always strive to surround yourself with people who are smarter than you, and
when you can’t, you should at least read their books.
Patrick is a pragmatist with a purist’s knowledge. He has a deep understanding of what ‘‘smells’’ right,
and he knows when and how to find the right balance to get the job done. This philosophy of balanced
‘‘pure pragmatism’’ pervades this book and makes it useful.
He moves back and forth between code and prose as if they were the same thing — useful, because
for many of us, they are. Rather than including large formal code listings and leaving the reader huge
chunks of code to grok, he weaves code in and out of his prose with the result being a practical, emi-
nently readable book about the art and science, but most importantly, the process of modern software
engineering.
There are dozens of books that include lists of tools and techniques, but few attempt to put these tools
into the larger context of actually shipping successful software. I’ve found, while reading this book, that
it’s full of concepts that are intuitively obvious, but often forgotten within the scope of a large project. It’s
so nice to not just be preached the what and the how, butalsothewhy.Thesearethepracticalconcepts
that we aren’t taught in school, but only learn after hard-won battles in the real world.
Scott Hanselman
Author of ComputerZen Blog,
www.computerzen.com
Senior Program Manager, Developer Division, Microsoft Corporation
Simpo PDF Merge and Split Unregistered Version -
Simpo PDF Merge and Split Unregistered Version -
Credits
Acquisitions Director
Jim Minatel
Development Editor
Maryann Steinhart

Technical Editor
Douglas Parsons
Production Editor
Dassi Zeidel
Copy Editor
Foxxe Editorial Services
Editorial Manager
Mary Beth Wakefield
Production Manager
Tim Tate
Vice President and Executive Group Publisher
Richard Swadley
Vice President and Executive Publisher
Joseph B. Wikert
Project Coordinator, Cover
Lynsey Stanford
Proofreader
Kathy Pope, Word One
Indexer
Robert Swanson
Simpo PDF Merge and Split Unregistered Version -
Simpo PDF Merge and Split Unregistered Version -
Acknowledgments
Big thanks to Scott Hanselman, who has long been a good friend and who has always encouraged me to
tackle new challenges. Thanks also to Chris Brooks and Tom Cook, who gave me the chance to put many
of the ideas in this book into practice. I would also like to thank Jim Minatel, Maryann Steinhart, and the
rest of the folks at Wiley for making this book possible.
Simpo PDF Merge and Split Unregistered Version -
Simpo PDF Merge and Split Unregistered Version -
Contents

Introduction xxi
Part I: Philosophy
Chapter 1: Buy, Not Build 3
Cost versus Benefit 4
Creating a Competitive Advantage 5
Base Class Libraries 6
Open Source Software 7
Taking Advantage of Your Platform 7
Design 7
Risk 8
Services 9
Third-Party Components 9
Summary 10
Chapter 2: Test-Driven Development 11
Tests Define Your Contract 13
Tests Communicate Your Intent 16
Summary 19
Chapter 3: Continuous Integration 21
Integrate Early and Often 22
Keeping Testers Working 22
Keeping Developers Working 22
Barriers to Continuous Integration 23
Build Servers 25
Automating a Build Process 26
Expanding the Build Process 29
Setting Up a CI Server 31
Multiple Builds of the Same Project 35
Coordinating Build Output 35
Notifying People about Build Results 36
Simpo PDF Merge and Split Unregistered Version -

Contents
Fix a Broken Build before Integrating Changes 37
Summary 39
Part II: Process
Chapter 4: Done Is Done 43
Discuss Design Decisions 44
Every Class Has a Test Fixture 45
Each Fixture Exercises Only One Class 48
Code Coverage Is High 49
No Compiler Warnings 51
Static Analysis Tools Generate No Errors 52
Before Committing, Update 53
Documentation in Place 53
Summary 56
Chapter 5: Testing 57
Why Testing Doesn’t Get Done 58
How Testing Will Make You a Better Developer 59
Your Designs Will Be Better 59
You’ll Have to Write Less Code to Achieve Your Goals 59
You Will Learn More about Coding 60
You Will Develop Better Relationships with Your Testers 61
You Will Make Your Project Sponsors Happy 61
Code Coverage 64
Why Measure Code Coverage 65
Code Coverage Tools 67
Strategies for Improving Code Coverage 72
Types of Tests 74
Unit Tests 75
Integration Tests 84
Functional Tests 89

Performance Testing 93
Test Automation 96
Strategies for Test Automation 96
Testing Frameworks 97
Automation and Your Organization 104
Summary 106
xviii
Simpo PDF Merge and Split Unregistered Version -
Contents
Chapter 6: Source Control 107
Some Source Control History 108
Concurrent Versioning System (CVS) 110
Picking the Right SCCS 110
Performance and Scalability 111
Locking Models 111
Cost 112
Atomic Commits 112
Branching 113
Merging 114
Integration with Other Tools 114
Reporting 115
Extensibility 115
Making Your Choice 115
Organizing Your Source Tree 117
Using TreeSurgeon 117
Packaging 121
Adding Folders to Work with Source Control 121
Making the Most of Branching 122
Version Branches 123
Integration Branches 127

Personal Branches 129
Task Branches 130
Merging Branches 131
Summary 133
Chapter 7: Static Analysis 135
Using Static Analysis Tools 135
NDepend 136
FxCop 137
Simian 139
Who Benefits from Static Analysis? 139
How to Integrate Static Analysis into Your Process 140
Summary 143
Part III: Code Construction
Chapter 8: Contract, Contract, Contract! 147
Public Interfaces 152
xix
Simpo PDF Merge and Split Unregistered Version -
Contents
Data Contracts 155
Summary 158
Chapter 9: Limiting Dependencies 159
Limiting Surface Area 162
Dependency Injection 165
Inversion of C ontrol 167
Summary 170
Chapter 10: The Model-View-Presenter (MVP) Model 173
Why MVP? 173
What Is MVP? 174
Constructing the MVP Application 177
Testing MVP Applications 184

Summary 187
Chapter 11: Tracing 189
Different Kinds of Messages 189
Log Sources and Log Sinks 190
Activities and Correlation IDs 192
Defining a Policy 193
Making Messages Actionable 196
Summary 198
Chapter 12: Error Handling 199
Result Code Reading 200
Exception Throwing 201
Importance of a Policy 203
Defining a Policy 204
Where to Handle Errors 207
Summary 210
Part IV: Putting It All Together
Chapter 13: Calculator Project: A Case Study 213
Wrapping Up 220
Index 223
xx
Simpo PDF Merge and Split Unregistered Version -
Introduction
Writing software is a complicated business. Once upon a time, software was written by an exclusive
hacker priesthood that emerged from big businesses like the telephone company or big industrial con-
cerns. Most of them were electronics engineers who needed to write software to control hardware devices
that they built. Those early ‘‘programmers’’ mostly did just that. They wrote code to solve tangible prob-
lems, such as opening and closing phone switches and making sure that conveyor systems in automobile
factories worked the way they were supposed to. A very few of them wrote operating system software
or device drivers or networking protocols. In my first software job, I worked with a very complex (for
1992) network backup program that backed up client PCs to a tape drive attached to a Novell server.

The system had to manage network traffic, multiple clients waiting for the same tape drive on the server,
full and incremental backup sets, and so on. That piece of software was written almost entirely by two
developers.
Those days are over. The vast majority of software today is written by professional software developers
to solve business problems. There is often no hardware device involved except for the PC itself. Online
commerce, business-to-business computing, financial and accounting software, and banking or health-
care software are what many if not most of us work on today. There are no device drivers involved, no
hardware switches, no robots — these are business problems that can be solved by software.
Along with changes in the nature of the problems to be solved with software has come a huge increase in
the complexity of the software systems that we must design and build. The advent of the Web has meant
that much of the software written today is designed to be distributed across more than one computer,
and potentially used by many hundreds of thousandsofcustomers.Itisnolongerenoughtowrite
software that solves a problem; it must also be fast, scalable, reliable, and easy to use. Ever since the
infamous .COM bubble burst, software must also be affordable, both to build and to support. Total cost
of ownership is becoming an increasingly important issue for software firms, sometimes more so than
building new features.
Luckily, the tools used to write software have improved at least as rapidly as the complexity of the
software has increased. Most software today, particularly business software, is written in high-level
languages that remove much of the drudgery once associated with day-to-day programming tasks. That
frees developers to concern themselves with solving business problems rather than with pure ‘‘coding’’
tasks.
The combination of these various trends has meant that professional developers can’t just be coders any
more if they want to advance in their careers. Gone are the days when a project could be saved at the last
minute by the heroic efforts of a super-genius coder. Although I’m sure that still happens here and there,
it certainly isn’t the norm. Most modern software projects are just too complicated to make that work.
Even a medium-sized software project these days is too much for one person to fully comprehend in all of
its detail. That means that we must work on teams on almost all software projects. Granted, that might be
a team of two or three in some cases, but more often it’s a team of 10 or more developers. That means that
to get ahead in the software industry these days you have to know just as much about how to help teams
work together as you do about writing code, even if you are not in a project management or personnel

Simpo PDF Merge and Split Unregistered Version -
Introduction
management role. A team lead, technical lead, or architect must be able to keep a team of developers
on track and working well together, just as much as he or she needs to be able to turn requirements
into code.
That isn’t to say that they should become project managers — that’s a completely different subject, and
this book is not about project management, although all of the topics covered in it apply equally well to
any project management methodology. It falls to the team lead to be familiar with strategies that make
it easier for teams of developers to work together in ways that enhance rather than detract from their
productivity.
Those strategies range from high-level development philosophies, such as Test-Driven Development
(TDD) or Continuous Integration (CI), to more concrete development process issues, from source code
control and static analysis to techniques involving code construction, such as programming by con-
tract and how to deal with errors and tracing. Taken collectively, all these strategies and techniques are
designed to make it easier for teams of developers to work together in ways that allow them to coordinate
their work for highest productivity, and to produce software that is easy to build, support, and maintain.
In today’s software job market, those are ultimately the skills that separate the career professional from
the hacker, and the great developer from the average one.
Being able to write good code is still a prerequisite, of course, but there are several other exceptional
books that cover that subject in depth. Code Complete by Steve McConnell and The Pragmatic Programmer:
From Journeyman to Master by Andrew Hunt and David Thomas are excellent examples. If you want to
make the transition from solid coder to team lead, however, you need to know more than how to write a
tight
for
loop.
Who This Book Is For
This book is for the career developer who wants to take his or her skill set and/or project to the next level.
If you are a professional software developer with 3–4 years of experience looking to bring a higher level
of discipline to your project, or to learn the skills that will help you transition from software engineer to
technical lead, then this book is for you. The topics covered in this book will help you focus on delivering

software at a higher quality and lower cost. The book is about practical techniques and practices that will
help you and your team realize those goals.
This book is for the developer who understands that the business of software is, first and foremost,
business. Writing code is fun, but writing high-quality code on time and at the lowest possible cost is
what makes a software project successful. A team lead or architect who wants to succeed must keep that
in mind.
Given that target audience, this book assumes a certain level of skill at reading code in one or more
languages, and basic familiarity with building and testing software projects. It also assumes that you
have at least a basic understanding of the software development life cycle, and how requirements from
customers become testable software projects.
Who This Book Is Not For
This is not a book for the entry-level developer fresh out of college, or for those just getting started as
professional coders. It isn’t a book about writing code; it’s a book about how we write code together
xxii
Simpo PDF Merge and Split Unregistered Version -