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

Code LeaderUsing People, Tools, and Processes to Build Successful Software Patrick Cauldwell Wiley Publishing, Inc... Code LeaderUsing People, Tools, and Processes to Build Successful So

Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com

Code Leader

Using People, Tools, and Processes to

Build Successful Software

Patrick Cauldwell

Wiley Publishing, Inc.

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

Code Leader

Code Leader

Using People, Tools, and Processes to

Build Successful Software

Patrick Cauldwell

Wiley Publishing, Inc.

Code Leader: Using People, Tools, and Processes to

Build Successful Software

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

10 9 8 7 6 5 4 3 2 1

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 aspermitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the priorwritten 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, WileyPublishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, oronline athttp://www.wiley.com/go/permissions

Limit of Liability/Disclaimer of Warranty:The publisher and the author make no representations orwarranties with respect to the accuracy or completeness of the contents of this work and specificallydisclaim all warranties, including without limitation warranties of fitness for a particular purpose Nowarranty may be created or extended by sales or promotional materials The advice and strategiescontained herein may not be suitable for every situation This work is sold with the understanding thatthe publisher is not engaged in rendering legal, accounting, or other professional services If professionalassistance is required, the services of a competent professional person should be sought Neither thepublisher nor the author shall be liable for damages arising herefrom The fact that an organization orWebsite is referred to in this work as a citation and/or a potential source of further information does notmean 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 thiswork 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 please 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 relatedtrade dress are trademarks or registered trademarks of John Wiley & Sons, Inc and/or its affiliates, in theUnited States and other countries, and may not be used without written permission All other trademarksare the property of their respective owners Wiley Publishing, Inc is not associated with any product orvendor mentioned in this book

Wiley also publishes its books in a variety of electronic formats Some content that appears in print maynot be available in electronic books

Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com

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.

About the Author

Patrick Cauldwellsomehow 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 alwaysbeen interested in what makes computers tick He’s worked in a wide range of software operations, fromvery 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 oper conferences across the country, and once talked about the challenges of building a highly scalableeCommerce web site as part of a 12-city developer road show

devel-After working for several product companies, Patrick recently returned to consulting full time

I have worked with Patrick Cauldwell, in one form or another, at two different companies for more thanhalf of my 15-year career in software He has been almost a constant in my professional life, and I am abetter programmer for working with him Why am I telling you this, dear reader, and why should youcare? Because you should always strive to surround yourself with people who are smarter than you, andwhen 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, becausefor many of us, they are Rather than including large formal code listings and leaving the reader hugechunks 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 softwareengineering

There are dozens of books that include lists of tools and techniques, but few attempt to put these toolsinto the larger context of actually shipping successful software I’ve found, while reading this book, thatit’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, but also the why These are the practical concepts

that we aren’t taught in school, but only learn after hard-won battles in the real world.

Scott HanselmanAuthor of ComputerZen Blog,www.computerzen.com

Senior Program Manager, Developer Division, Microsoft Corporation

Part I: Philosophy

Creating a Competitive Advantage 5

Taking Advantage of Your Platform 7

Tests Define Your Contract 13 Tests Communicate Your Intent 16

Integrate Early and Often 22

Fix a Broken Build before Integrating Changes 37

Part II: Process

Every Class Has a Test Fixture 45 Each Fixture Exercises Only One Class 48

Chapter 6: Source Control 107

Some Source Control History 108

Organizing Your Source Tree 117

Making the Most of Branching 122

Using Static Analysis Tools 135

Part III: Code Construction

xix

Making Messages Actionable 196

Part IV: Putting It All Together

I n t r o d u c t i o n

Writing software is a complicated business Once upon a time, software was written by an exclusivehacker 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 devicesthat 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 automobilefactories 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 (for1992) 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 twodevelopers

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 Onlinecommerce, 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, nohardware 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 inthe complexity of the software systems that we must design and build The advent of the Web has meantthat much of the software written today is designed to be distributed across more than one computer,and potentially used by many hundreds of thousands of customers It is no longer enough to writesoftware that solves a problem; it must also be fast, scalable, reliable, and easy to use Ever since theinfamous 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 thanbuilding new features

Luckily, the tools used to write software have improved at least as rapidly as the complexity of thesoftware has increased Most software today, particularly business software, is written in high-levellanguages that remove much of the drudgery once associated with day-to-day programming tasks Thatfrees 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 anymore if they want to advance in their careers Gone are the days when a project could be saved at the lastminute 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 ofits 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 teamswork together as you do about writing code, even if you are not in a project management or personnel

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 requirementsinto code

That isn’t to say that they should become project managers — that’s a completely different subject, andthis book is not about project management, although all of the topics covered in it apply equally well toany 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 theirproductivity

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 codecontrol 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 aredesigned to make it easier for teams of developers to work together in ways that allow them to coordinatetheir 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 fromthe 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 atightforloop

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 totechnical lead, then this book is for you The topics covered in this book will help you focus on deliveringsoftware at a higher quality and lower cost The book is about practical techniques and practices that willhelp 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 iswhat 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 morelanguages, and basic familiarity with building and testing software projects It also assumes that youhave at least a basic understanding of the software development life cycle, and how requirements fromcustomers 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 asprofessional 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 - http://www.simpopdf.com

while keeping quality up and costs down It is not for those who want to learn to write more efficient orliterate code There are plenty of other books available on those subjects, as mentioned previously.This is also not a book about project management or development methodology All of the strategies andtechniques presented here are just as applicable to waterfall projects as they are to those employing Agilemethodologies While certain strategies such as Test-Driven Development and Continuous Integrationhave risen to popularity hand in hand with Agile development methodologies, there is no couplingbetween them There are plenty of projects run using SCRUM that do not use TDD, and there are just

as many waterfall projects that do To learn more about development methodologies, I suggest Rapid

Application Development by Steve McConnell, or anything from the XP series beginning with Kent Beck’s eXtreme Programming eXplained While XP itself may not be as popular today as once it was, that first book

is a fantastic introduction to the Agile philosophy

Why I’m Writing This Book

I’ve been writing code professionally for the last 16 years In that time, I have worked for companiesranging from less than 20 people to 65,000 I have worked on projects with one or two other developers,and on at least one that had nearly 200 developers working on it I have seen both sides of the COMbubble While working for a consulting company during the COM boom, I saw the nature of softwarechange radically (and rapidly) from desktop applications to web sites to highly distributed applications

I saw some projects succeed, and more than a few fail spectacularly Many of those projects failed becausethe developers working on them didn’t have the skills they needed to work effectively together Animproperly used source control system can cause just as many schedule delays as changing requirements.Developers who cannot work effectively with their quality-assurance teams are not likely to deliverhigh-quality software

In my own career transition from individual contributor to team lead to architect, I’ve learned that puttingpolicies in place to help developers work together is at least as important as finding people who are good

at writing code The most brilliant architecture will fail if it is implemented in a way that is too buggy ortoo expensive to support

In writing this book I hope to get more developers excited about process, about working well with others,and about building software that is easy and less expensive to create and to support I think those thingsare at least as exciting as building a faster hashtable or a better reader-writer lock, if not more so

Philosophy versus Practicality

There are a lot of philosophical arguments in software development Exceptions versus result codes,strongly typed versus dynamic languages, and where to put your curly braces are just a few examples Icertainly have opinions about each and every one of those debates, but I have done what I could to steerclear of them here Most of the chapters in this book deal with practical steps that you as a developer cantake to improve your skills and improve the state of your project I make no claims that these practices

represent the way to write software They represent strategies that have worked well for me and other

developers who I have worked with closely

Philosophy certainly has its place in software development Much of the current thinking in projectmanagement has been influenced by the Agile philosophy, for example The next wave may be

xxiii