Download programming plagarism and more Assignments Programming Paradigms in PDF only on Docsity!
I l@ve RuBoard
Front Matter Table of Contents About the Author
Pragmatic Programmer, The: From Journeyman to Master
Andrew Hunt David Thomas Publisher: Addison Wesley
First Edition October 13, 1999 ISBN: 0-201-61622-X, 352 pages
Straight from the programming trenches, The Pragmatic Programmer cuts through the increasing specialization and technicalities of modern software development to examine the core process--taking a requirement and producing working, maintainable code that delights its users. It covers topics ranging from personal responsibility and career development to architectural techniques for keeping your code flexible and easy to adapt and reuse. Read this book, and you’ll learn how to:
Fight software rot;
Avoid the trap of duplicating knowledge;
Write flexible, dynamic, and adaptable code;
Avoid programming by coincidence;
Bullet-proof your code with contracts, assertions, and exceptions;
Capture real requirements;
Test ruthlessly and effectively;
Delight your users;
Build teams of pragmatic programmers; and
Make your developments more precise with automation.
Written as a series of self-contained sections and filled with entertaining anecdotes, thoughtful examples, and interesting analogies, The Pragmatic Programmer illustrates the best practices and major pitfalls of many different aspects of software development. Whether you’re a new coder, an experienced programmer, or a manager responsible for software projects, use these lessons daily, and you’ll quickly see improvements in personal productivity, accuracy, and job satisfaction. You’ll learn skills and develop habits and attitudes that form the foundation for long-term success in your career. You’ll become a Pragmatic Programmer.
I l@ve RuBoard
Shell Games Power Editing Source Code Control But My Team Isn't Using Source Code Control Source Code Control Products Debugging Text Manipulation Exercises Code Generators
- Pragmatic Paranoia Design by Contract Dead Programs Tell No Lies Assertive Programming When to Use Exceptions How to Balance Resources Objects and Exceptions Balancing and Exceptions When You Can't Balance Resources Checking the Balance Exercises
- Bend or Break Decoupling and the Law of Demeter Metaprogramming Temporal Coupling It's Just a View Blackboards
- While You Are Coding Programming by Coincidence Algorithm Speed Refactoring Code That's Easy to Test Evil Wizards
- Before the Project The Requirements Pit Solving Impossible Puzzles Not Until You're Ready The Specification Trap Circles and Arrows
- Pragmatic Projects Pragmatic Teams Ubiquitous Automation
Ruthless Testing It's All Writing Great Expectations Pride and Prejudice
A. Resources Professional Societies Building a Library Internet Resources Bibliography
B. Answers to Exercises
I l@ve RuBoard
Visit AWL on the Web: http://www.awl.com/cseng
Library of Congress Catalogtng-in-Publication Data
Hunt, Andrew, 1964 –
The Pragmatic Programmer / Andrew Hunt, David Thomas.
p. cm.
Includes bibliographical references.
ISBN 0-201-61622-X
- Computer programming. I. Thomas, David, 1956–.
II. Title.
QA76.6.H857 1999
005.1--dc21 99–4358 1
CIP
Copyright © 2000 by Addison Wesley Longman, Inc.
All rights reserved. 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, or otherwise, without the prior written permission of the publisher. Printed in the United States of America. Published simultaneously in Canada.
3 4 5 6 7 8 9 10—CRS—0302010 0
Third printing, October 2000
For Ellie and Juliet,
Elizabeth and Zachay,
Stuart and Henry
I l@ve RuBoard
So imagine that these guys are thinking this way for a few years. Pretty soon they would have a collection of solutions. Now imagine them using their solutions in their work for a few more years, and discarding the ones that are too hard or don't always produce results.
Well, that approach just about defines pragmatic. Now imagine them taking a year or two
more to write their solutions down. You might think, That information would be a gold
mine. And you would be right.
The authors tell us how they program. And they tell us in a way that we can follow. But there is more to this second statement than you might think. Let me explain.
The authors have been careful to avoid proposing a theory of software development. This is fortunate, because if they had they would be obliged to warp each chapter to defend their theory. Such warping is the tradition in, say, the physical sciences, where theories eventually become laws or are quietly discarded. Programming on the other hand has few (if any) laws. So programming advice shaped around wanna-be laws may sound good in writing, but it fails to satisfy in practice. This is what goes wrong with so many methodology books.
I've studied this problem for a dozen years and found the most promise in a device called a
pattern language. In short, a pattern is a solution, and a pattern language is a system of
solutions that reinforce each other. A whole community has formed around the search for these systems.
This book is more than a collection of tips. It is a pattern language in sheep's clothing. I say that because each tip is drawn from experience, told as concrete advice, and related to others to form a system. These are the characteristics that allow us to learn and follow a pattern language. They work the same way here.
You can follow the advice in this book because it is concrete. You won't find vague abstractions. Dave and Andy write directly for you, as if each tip was a vital strategy for energizing your programming career. They make it simple, they tell a story, they use a light touch, and then they follow that up with answers to questions that will come up when you try.
And there is more. After you read ten or fifteen tips you will begin to see an extra
dimension to the work. We sometimes call it QWAN, short for the quality without a name.
The book has a philosophy that will ooze into your consciousness and mix with your own. It doesn't preach. It just tells what works. But in the telling more comes through. That's the beauty of the book: It embodies its philosophy, and it does so unpretentiously.
So here it is: an easy to read—and use—book about the whole practice of programming. I've gone on and on about why it works. You probably only care that it does work. It does. You will see.
— Ward Cunningham
I l@ve RuBoard
the relative importance of all the factors affecting a project and use your experience to produce appropriate solutions. And you do this continuously as the work progresses. Pragmatic Programmers get the job done, and do it well.
I l@ve RuBoard
I l@ve RuBoard
Who Should Read This Book?
This book is aimed at people who want to become more effective and more productive programmers. Perhaps you feel frustrated that you don't seem to be achieving your potential. Perhaps you look at colleagues who seem to be using tools to make themselves more productive than you. Maybe your current job uses older technologies, and you want to know how newer ideas can be applied to what you do.
We don't pretend to have all (or even most) of the answers, nor are all of our ideas applicable in all situations. All we can say is that if you follow our approach, you'll gain experience rapidly, your productivity will increase, and you'll have a better understanding of the entire development process. And you'll write better software.
I l@ve RuBoard
Care About Your Craft
We feel that there is no point in developing software unless you care about doing it well.
Tip 2
Think! About Your Work
In order to be a Pragmatic Programmer, we're challenging you to think about what you're doing while you're doing it. This isn't a one-time audit of current practices—it's an ongoing critical appraisal of every decision you make, every day, and on every development. Never run on auto-pilot. Constantly be thinking, critiquing your work in real time. The old IBM corporate motto, THINK!, is the Pragmatic Programmer's mantra.
If this sounds like hard work to you, then you're exhibiting the realistic characteristic. This
is going to take up some of your valuable time—time that is probably already under tremendous pressure. The reward is a more active involvement with a job you love, a feeling of mastery over an increasing range of subjects, and pleasure in a feeling of continuous improvement. Over the long term, your time investment will be repaid as you and your team become more efficient, write code that's easier to maintain, and spend less time in meetings.
I l@ve RuBoard
I l@ve RuBoard
Individual Pragmatists, Large Teams
Some people feel that there is no room for individuality on large teams or complex projects. "Software construction is an engineering discipline," they say, "that breaks down if individual team members make decisions for themselves."
We disagree.
The construction of software should be an engineering discipline. However, this doesn't
preclude individual craftsmanship. Think about the large cathedrals built in Europe during the Middle Ages. Each took thousands of person-years of effort, spread over many decades. Lessons learned were passed down to the next set of builders, who advanced the state of structural engineering with their accomplishments. But the carpenters, stonecutters, carvers, and glass workers were all craftspeople, interpreting the engineering requirements to produce a whole that transcended the purely mechanical side of the construction. It was their belief in their individual contributions that sustained the projects:
We who cut mere stones must always be envisioning cathedrals.
— Quarry worker's creed
Within the overall structure of a project there is always room for individuality and craftsmanship. This is particularly true given the current state of software engineering. One hundred years from now, our engineering may seem as archaic as the techniques used by medieval cathedral builders seem to today's civil engineers, while our craftsmanship will still be honored.
I l@ve RuBoard
I l@ve RuBoard
How the Book Is Organized
This book is written as a collection of short sections. Each section is self-contained, and addresses a particular topic. You'll find numerous cross references, which help put each topic in context. Feel free to read the sections in any order—this isn't a book you need to read front-to-back.
Occasionally you'll come across a box labeled Tip nn (such as Tip 1, "Care About Your
Craft" on page xix). As well as emphasizing points in the text, we feel the tips have a life of their own—we live by them daily. You'll find a summary of all the tips on a pull-out card inside the back cover.
Appendix A contains a set of resources: the book's bibliography, a list of URLs to Web resources, and a list of recommended periodicals, books, and professional organizations. Throughout the book you'll find references to the bibliography and to the list of URLs—such as [KP99] and [URL 18], respectively.
We've included exercises and challenges where appropriate. Exercises normally have relatively straightforward answers, while the challenges are more open-ended. To give you an idea of our thinking, we've included our answers to the exercises in Appendix B, but
very few have a single correct solution. The challenges might form the basis of group
discussions or essay work in advanced programming courses.
I l@ve RuBoard
I l@ve RuBoard
What's in a Name?
"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just
what I choose it to mean—neither more nor less."
Lewis Carroll, Through the Looking-Glass
Scattered throughout the book you'll find various bits of jargon—either perfectly good English words that have been corrupted to mean something technical, or horrendous made-up words that have been assigned meanings by computer scientists with a grudge against the language. The first time we use each of these jargon words, we try to define it, or at least give a hint to its meaning. However, we're sure that some have fallen through
the cracks, and others, such as object and relational database, are in common enough
usage that adding a definition would be boring. If you do come across a term you haven't seen before, please don't just skip over it. Take time to look it up, perhaps on the Web, or maybe in a computer science textbook. And, if you get a chance, drop us an e-mail and complain, so we can add a definition to the next edition.
Having said all this, we decided to get revenge against the computer scientists. Sometimes, there are perfectly good jargon words for concepts, words that we've decided to ignore. Why? Because the existing jargon is normally restricted to a particular problem domain, or to a particular phase of development. However, one of the basic philosophies of this book is that most of the techniques we're recommending are universal: modularity applies to code, designs, documentation, and team organization, for instance. When we wanted to use the conventional jargon word in a broader context, it got confusing—we couldn't seem to overcome the baggage the original term brought with it. When this happened, we contributed to the decline of the language by inventing our own terms.
Source Code and Other Resources
Most of the code shown in this book is extracted from compilable source files, available for download from our Web site:
http://www.pragmaticprogrammer.com
There you'll also find links to resources we find useful, along with updates to the book and news of other Pragmatic Programmer developments.
