Tài liệu New Programmer’s Survival Manual pdf

www.it-ebooks.info
What Readers Are Saying About
New Programmer’s Survival Manual
I love the pragmatic tone and content.
➤
Bob Martin
President, Object Mentor, Inc., and author of The Clean Coder
An excellent overview of the “big picture” and the many facets of software
development that a lot of new developers lack. A great primer for starting
an exciting career in software development.
➤
Andy Keffalas
Software engineer and team lead
www.it-ebooks.info
A funny, honest, inside look at the ever-growing, ever-changing industry
of writing code. If y o u just got handed y o u r CS degree, this book is a must-
have.
➤
Sam Rose
Computer science student, University of Glamorgan
This book has everything I should have sought out to learn when I started
in the industry. A must-read for new developers and a good read for
everyone in the industry.
➤
Chad Dumler-Montplaisir
Software developer
www.it-ebooks.info
New Programmer’s
Survival Manual
Navigate Y o u r W o r k p l a c e ,
Cube Farm, or Startup

Josh Carter
The Pragmatic Bookshelf
Dallas, Texas • Raleigh, North Carolina
www.it-ebooks.info
Many of the designations used by manufacturers and sellers to distinguish their
products are claimed as trademarks. Where those designations appear in this book,
and The Pragmatic Programmers, LLC w a s aware of a trademark claim, the desig-
nations have been printed in initial capital letters or in all capitals. The Pragmatic
Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic
Bookshelf, PragProg and the linking g device are trademarks of The Pragmatic
Programmers, LLC.
Every precaution w a s taken in the preparation of this book. However, the publisher
assumes no responsibility for errors or omissions, or for damages that may result
from the use of information (including program listings) contained herein.
Our Pragmatic courses, w o r k s h o p s , and other products can help y o u and y o u r
team create better software and have more fun. For more information, as w e l l as
the latest Pragmatic titles, please visit us at

.
The team that produced this book includes:
Susannah Pfalzer (editor)
P o t o m a c Indexing, LLC (indexer)
Kim W i m p s e t t (copyeditor)
David J Kelly (typesetter)
Janet Furlow (producer)
Juliet Benda (rights)
Ellie Callahan (support)
Copyright © 2011 Pragmatic Programmers, LLC.
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 consent of
the publisher.
Printed in the United States of America.
ISBN-13: 978-1-934356-81-4
Printed on acid-free paper.
Book version: P1.0—November 2011
www.it-ebooks.info
For Daria and Genevieve.

www.it-ebooks.info
Contents
Acknowledgments . . . . . . . . ix
Introduction . . . . . . . . . xi
Part I — Professional Programming
1. Program for Production . . . . . . . 3
Tip 1. Beat Up Y o u r Code 6
Tip 2. Insist on Correctness 11
Tip 3. Design with T e s t s 21
Tip 4. T a m e Complexity 27
Tip 5. Fail Gracefully 35
Tip 6. Be Stylish 41
Tip 7. Improve Legacy Code 48
Tip 8. Review Code Early and Often 53
2. Get Y o u r T o o l s in Order . . . . . . . 59
Tip 9. Optimize Y o u r Environment 61
Tip 10. Speak Y o u r Language Fluently 69
Tip 11. Know Y o u r Platform 77
Tip 12. Automate Y o u r P a i n A w a y 83

Tip 13. Control Time (and Timelines) 87
Tip 14. Use the Source, Luke 92

www.it-ebooks.info
Part II — People Skills
3. Manage Thy Self . . . . . . . . 101
Tip 15. Find a Mentor 103
Tip 16. Own the Image Y o u Project 107
Tip 17. Be V i s i b l e 110
Tip 18. Ace Y o u r P e r f o r m a n c e Review 114
Tip 19. Manage Y o u r Stress 121
Tip 20. T r e a t Y o u r Body Right 127
4. T e a m w o r k . . . . . . . . . 133
Tip 21. Grok P e r s o n a l i t y T y p e s 135
Tip 22. Connect the Dots 141
Tip 23. W o r k T o g e t h e r 144
Tip 24. Meet Effectively 148
Part III — The Corporate World
5. Inside the Company . . . . . . . 155
Tip 25. Know Y o u r P e e p s 157
Tip 26. Know Y o u r (Corporate) Anatomy 163
6. Mind Y o u r Business . . . . . . . 181
Tip 27. Get with the Project 183
Tip 28. Appreciate the Circle of (a Product’s) Life 189
Tip 29. Put Y o u r s e l f in the Company’s Shoes 200
Tip 30. Identify Corporate Antipatterns 203
Part IV — Looking Forward
7. Kaizen . . . . . . . . . . 211
Tip 31. Mind Y o u r Head 213
Tip 32. Never Stop Learning 217

Tip 33. Find Y o u r Place 222
A1. Bibliography . . . . . . . . . 227
Index . . . . . . . . . . 231
viii • Contents

www.it-ebooks.info
Acknowledgments
First, I must thank my ever-patient editor, Susannah
D avidson P falzer. This b o ok c ouldn’t h ave h a ppened w i thout
her clear-minded guidance, w o r d s of encouragement, and
occasional swift kick in the rear to keep me going. Susannah,
thank y o u so much for helping this first-time author bring
a book to life.
Next, numerous reviewers ranging from new programmers
to industry pros provided tremendous help. They read (or
should I say, endured) early drafts of this book and offered
their own viewpoints, expertise, and corrections. I’d like to
thank Daniel Bretoi, Bob Cochran, Russell Champoux, Javier
Collado, Geoff Drake, Chad Dumler-Montplaisir, Kevin Gisi,
Brian Hogan, Andy Keffalas, Steve Klabnik, Robert C. Mar-
tin, Rajesh Pillai, Antonio Gomes Rodrigues, Sam Rose, Brian
Schau, Julian Schrittwieser, Tibor Simic, Jen Spinney, Stefan
T u r a l s k i , Juho V e p s ä l ä i n e n , Nick W a t t s , and Chris W r i g h t .
Y o u have all made this book far, far better with y o u r diligent
and thorough reviews. I—and every reader of this
book—appreciate y o u r w o r k .
From the beginning, several friends and co-workers allowed
me to pester them over and over again for advice, including
Jeb Bolding, Mark “The Red” Harlan, Scott Knaster, David
Olson, Rich Rector, and Zz Zimmerman. I truly appreciate

y o u r patience.
Finally, an extra-special thanks for my two biggest fans. My
daughter, Genevieve, gave me grace many, many evenings
as I needed to duck away and write. And my wife, Daria,
not only gave me time to write, but she w a s the first to buy
and read the beta v e r s i o n of the book—in one sitting, no
less, starting at ten at night. She offered her thoughts and


www.it-ebooks.info
perspective since this book w a s just an idea I w a s pondering
over the dinner table. And she provided her support and
encouragement through the whole process.
Daria and Genevieve, I couldn’t have done it without y o u .
Thank y o u from the bottom of my heart.
x • Acknowledgments


www.it-ebooks.info
Introduction
It’s day one on the job. Y o u have programming chops, y o u ’ v e
landed the job, y o u ’r e sitting at y o u r w o r ks t a t i o n … n o w
what? Before y o u , a new jungle awaits:
• Programming at industry scale, with code bases mea-
sured in thousands (or hundreds of thousands) of lines
of code. How do y o u get yo u r bearings and start con-
tributing quickly?
• Navigating an organization containing programmers
but also people in many, many other roles. When y o u
need guidance on a product feature, who do y o u ask?

• B ui l din g y o u r po rtfoli o of a chiev ement s eac h y e a r . When
performance reviews lurk on the horizon, do y o u know
what y o u r boss is looking for and how y o u ’ l l be judged?
…and so much more. Y o u r programming skills are only one
part of what y o u ’ l l need in these first y e a r s on the job.
The lucky among us have guides who already know the
landscape. This book is a virtual guide. It’ll get y o u oriented,
point out the mountains and canyons ahead, and also save
y o u from some nasty pitfalls.
Where I’m Coming From
Y o u may find some similarity between y o ur experience and
where I stood in college in 1995: I started on a traditional
path, a computer science and electrical engineering program
at Duke University. I we n t to my advisor, asking about
classes that wo u l d best prepare me for w o r k i n g in industry.
He w a s a smart guy—a Rhodes scholar and rising star in
the engineering school—and he responded, “I have no idea.
I’ve never w o r k e d a day in industry in my life.”


www.it-ebooks.info
I w a s more than a little disillusioned. I w a n t e d to build real,
shipping products—not write research papers. So, that
summer I managed to get my foot in the door at one of the
hottest start-ups in Silicon V a l l e y , General Magic. It w a s
founded by some of the same guys who created the original
Macintosh computer, Andy Hertzfeld and Bill Atkinson. My
peers included some of the top players from Apple’s System
7 (operating system) team and the guy who w o u l d later
found eBay.

I learned more about programming in my two-month intern-
ship than I could have learned in two y e a r s of school. I called
Duke and said I w a s n ’ t coming back. And so my wild ride
in industry began.
And Now About You
Readers of this book will fall into a few broad categories:
• College students and recent graduates taking computer
science classes and w o n d e r i n g , “Is this what program-
ming is like in the real w o r l d ? ” (Short answer: no.)
• Professionals from other backgrounds who got into
programming as a hobby or side job, now w a n t i n g to
take it on full-time.
• Others who are considering a job in programming but
w a n t the skinny on what the books and classes aren’t
telling them.
Regardless of path, here yo u are: it’s time to pay the bills
with code. There are plenty of books out there on the code
part. There’s not so much on everything else that goes with
the job—and that’s where this book comes in.
For the professionals coming from other fields, some sections
w o n ’ t apply as much to y o u — y o u don’t need me to tell y o u
what marketing does if y o u r background is marketing.
However, y o u will still benefit from details about how things
run within the engineering department and how code
evolves from concept to release.
xii • Introduction


www.it-ebooks.info
Structure of This Book

This book is written in small mini-chapters, called tips, that
are designed to address a single topic within a few pages.
Some are longer by necessity. Related tips are close together,
but y o u can read them in any order. If yo u ’r e going for the
big picture, go ahead and read it from cover to cover. But
feel free to flip around—when tips need to reference each
other, that’s stated explicitly in the text.
W e start close to the code: Chapter 1, Program for Production,
on page 3 starts from y o u r programming talent and gives
y o u guidance on making it production-ready. Nobody w a n t s
to ship buggy code, but it’s especially challenging on indus-
trial-scale projects to ensure that y o u r code is correct and
w e l l - t e s t e d .
Next, Chapter 2, Get Y o u r T o o l s in Order, on page 59 helps
with y o u r w o r k f l o w . Y o u ’ l l need to coordinate with others,
automate builds, and learn new technologies as y o u go. Plus,
y o u ’ l l need to hammer out a ton of code. It pays to invest in
y o u r tools up front.
Then w e get into the squishier side of things. The one man-
ager y o u ’ ll have throughout y o u r life is you, and Chapter 3,
Manage Thy Self, on page 101 gets y o u started on issues such
as stress management and job performance.
No programmer is an island, so Chapter 4, T e a m w o r k , on
page 133 focuses on w o r k i n g with others. Don’t discount
people skills—true, y o u w e r e hired to be good at computers,
but industry is a team sport.
Then w e get to the bigger picture. Chapter 5, Inside the
Company, on page 155 considers all the moving pieces that
make up a typical high-tech company and yo u r part within
the whole. It ultimately tries to answer, “What do all these

people do all day?”
Closer to home is the business of software. Chapter 6, Mind
Y o u r Business, on page 181 gets into who’s paying yo u r pay-
check and why, the life cycle of a software project, and how
y o u r day-to-day programming changes with that life cycle.

Introduction • xiii

www.it-ebooks.info
Finally, Chapter 7, Kaizen, on page 211 looks forward. The
Japanese Kaizen is a philosophy of continuous improvement,
and I hope to see y o u on that path before w e part w a y s .
Conventions Used in This Book
I often use the Ruby programming language in tips that have
example code. I chose Ruby simply because it’s concise and
easy to read. Don’t w o r r y if y o u don’t know Ruby; the intent
of the code should be self-evident. The examples are intend-
ed to demonstrate bigger-picture principles that may apply
to any programming language.
T h r ou gh ou t t h e b oo k y o u ’ l l e n co un te r s i d e b ar s t i t l e d i n d ustry
perspective. These are vo i c e s from industry pros: program-
mers and managers who have been down this road before.
Each contributor has decades of experience, so consider their
advice carefully.
White Belt to Black Belt (and Back)
Throughout the book I use the notion of martial arts belts
to signify when y o u ’ l l need to apply a certain tip. The color-
ing of belts has a story behind it that is helpful beyond the
martial arts. When a student begins, she starts with a white
belt, signifying innocence. White-belt tips, likewise, apply

from the v e r y beginning.
Over y e a r s of practice, her belt becomes soiled. The brown
belt is an intermediate step where the belt is, frankly, dirty.
(We modern wimps just buy a new belt that’s colored
brown.) For this book, I expect brown-belt topics to become
relevant between y e a r s two and five.
As the artist practices further, her belt becomes darker and
darker until it’s black. At this point, she dons the title master.
For the book I draw the line rather early, where black-belt
xiv • Introduction


www.it-ebooks.info
topics may apply around ye a r five and onward. In real life,
true mastery begins more around y e a r ten.
What happens as the new master continues to use her belt?
It becomes frayed and bleached from sunlight…it starts to
become white again. The masters of old discovered some-
thing about expertise that psychologists have only recently
studied: y o u need to get to a certain threshold before y o u
can know what y o u don’t know. And then y o u begin y o u r
learning anew.
Online Resources
This book’s w e b page is located here:
/>From here yo u can participate in a discussion forum with
me and other readers, check the errata for any bugs, and
report any new bugs y o u discover.
Onward
Enough chatter about the book. Y o u ’ r e sitting at y o u r
w o r k s t a t i o n w o n d e r i n g , “Now what?” And y o u r boss is

w o n d e r i n g why y o u ’ r e not wo r k i n g y e t . So, let’s get going!

Introduction • xv

www.it-ebooks.info
P a r t I
Professional Programming

www.it-ebooks.info
CHAPTER 1
Program for Production
When y o u program for fun, it’s easy to skimp on things such
as handling edge cases, error reporting, and so forth. It’s a
pain. But when yo u program for production—not to mention
a paycheck—you can’t take the shortcuts.
Production-quality code seems like a straightforward goal,
but our industry has had a heck of a time figuring out how
to get it right. W i n d o w s 95, for example, had a bug that
w o u l d hang the OS after 49.7 days of continuous opera-
tion—which w o u l d n ’ t be especially surprising except that
this bug took four years to discover because other bugs w o u l d
crash W i n d o w s 95 long before 49.7 days could pass.
1
Y o u can take one of two approaches to quality: build it in
from the beginning, or beat it in afterward. The former
approach requires a lot of discipline in y o u r day-to-day
coding. The latter requires a lot of testing and, in the end, a
lot of w o r k after y o u thought y o u w e r e done.
Beat-it-in-afterward is how it’s usually done. It’s implicit in
the w a t e r f a l l development method that dominates industry:

specify, design, build, test. T e s t comes last. The product goes
to the test department and blows up quickly. It goes back
to engineering, y o u fix bugs, y o u give another ve r s i o n to the
test department, that blows up in some other w a y , and so it
goes back and forth for many months (even y e a r s ) .
Much of this chapter’s focus is on build-it-in techniques
because that’s how y o u build a product that y o u can have
1. />

www.it-ebooks.info
confidence in, add features to, and maintain for y e a r s . Of
course, building production-quality software is a topic that
spans more than one book, and its scope is much larger than
testing. This discussion, however, is limited to things y o u
can do right now to improve the quality of y o u r code:
• Before getting into specific practices, w e start with Tip
1, Beat Up Y o u r Code, on page 6 to get y o u into the right
mind-set.
• Next, in Tip 2, Insist on Correctness, on page 11, we focus
on v e r i f y i n g that y o u r code does what it should.
• Y o u can also go the other w a y around; in Tip 3, Design
with T e s t s , on page 21, w e look at starting from tests and
using those tests to drive yo u r design.
• V e r y soon y o u ’ l l be swimming in a huge code base. Tip
4, T a m e Complexity, on page 27 deals specifically with
the sheer mass of production-sized software projects.
• Tip 5, Fail Gracefully, on page 35 takes us far off the
happy path, where yo u r code needs to cope with prob-
lems outside its control.
• Just when things get really gnarly, w e take a short

breather: Tip 6, Be Stylish, on page 41 helps y o u keep
y o u r code pretty—and that helps more than yo u ’ d
imagine over the long haul.
• Back to the hard stuff. Tip 7, Improve Legacy Code, on
page 48 deals with code yo u ’ v e inherited from y o u r
predecessors.
• Finally, in Tip 8, Review Code Early and Often, on page
53 y o u ’ l l w o r k with y o u r team to ensure y o u r code is
ready to deploy.
A Note on What’s Not Here
There are other aspects to production-worthiness I don’t
have space to address, and within many industries there are
domain-specific standards y o u need to meet, too. The follow-
ing are examples:
• D e f e n s i ve p r o g r a mm i ng a g a i n s t m a l i ci o us c o d e , n e t w o r k
activity, and other security concerns
4 • Chapter 1. Program for Production


www.it-ebooks.info
• Protection of users’ data from hardware and systems
failure, software bugs, and security breaches
• Deployment and scale-out performance of software put
under great load
• …and so forth
Consult a senior programmer for advice: beyond writing
code that w o r k s — a l l the time, every time—what else does
it take for y o u r code to pass muster?

Chapter 1. Program for Production • 5

www.it-ebooks.info
Tip 1
Beat Up Your Code
[White Belt] As soon as you wr ite pr od uction
code, you need to prove it can take a beating.
Y o u might think that writing solid code is an obvious job
requirement. It’s not like the job post said “Wanted: program-
mer w ith good a tt itud e, t eam playe r, foosb all skills . O pti onal:
writes solid code.” Y e t so many programs have bugs. What
gives?
Before w e get into detailed discussions of day-to-day prac-
tices for assuring code quality, let’s discuss what it means
to write solid code. It’s not just a list of practices; it’s a mind-
set. Y o u must beat up y o u r code, and the product as a whole,
before it goes out to customers.
The customer, after all, will beat up y o u r product. They’ll
use it in w a y s y o u don’t anticipate. They’ll use it for extended
periods of time. They’ll use it in environments y o u didn’t
test in. The question y o u must consider is this: how many
bugs do y o u w a n t y o u r customer to find?
The more you beat up yo u r code right now, before it gets into
customers’ hands, the more bugs y o u ’ l l flush out, and the
fewer y o u ’ l l leave for the customer.
Forms of Quality Assurance
Although much of this chapter focuses on code-level quality
and unit testing, assuring product quality is a much larger
topic. Let’s consider what y o u r product will need to endure.
Code Review
The first obvious, simple w a y to assure code quality is to

have another programmer read it. It doesn’t need to be a
fancy review, either—even pair programming is a form of
real-time code review. T e a m s will use code reviews to catch
6 • Chapter 1. Program for Production


www.it-ebooks.info
bugs, enforce coding style and standards, and also spread
knowledge among team members. W e ’ l l discuss code
reviews in Tip 8, Review Code Early and Often, on page 53.
Unit Tests
As yo u ’r e building the business logic of y o u r application,
class by class and method by method, there’s no better w a y
to v e r i f y y o u r code than with unit tests. These innards-level
tests are designed to v e r i f y bits of logic in isolation. W e ’ l l
discuss them in Tip 2, Insist on Correctness, on page 11 and
Tip 3, Design with T e s t s , on page 21.
Acceptance Tests
Where unit tests view the product from the inside out, accep-
tance tests are designed to simulate real-world users as they
interact with the system. Ideally, they are automated and
written as a narrative of sorts. For example, an automated
bank teller application could have an acceptance story like
this: given that I have $0 in my checking account, when I go
to the A T M and select “Withdrawal” from “Checking Ac-
count,” then I should see “Sorry, y o u ’r e eating Ramen for
dinner tonight.”
Shakespeare it is not, but these tests exercise the whole sys-
tem from the user interface down to business logic. Whether
they’re automated or performed by people, y o u r company

needs to know—before any customers play with it—that all
system components are cooperating like they should.
Load Testing
Load tests put the product under realistic stress and measure
its responsiveness. A we b s i t e , for example, may need to
render a given page in 100 milliseconds when there are a
million records in the database. These tests will uncover
correct-but-bad behavior, such as code that scales exponen-
tially when it needs to scale linearly.
Directed Exploratory Testing
Acceptance tests cover all of the product’s behavior that w a s
specified, perhaps via a product requirements document or
meetings. Y e t programmers can usually think of w a y s to
break it—there are always dark corners that the specification

Beat Up Your Code • 7

www.it-ebooks.info
Just How Full Are “Full System” Tests?
I spent several y e a r s writing control software for industrial
robots. Unit tests w o u l d simulate the motor movements so I
could test the business logic on a w o r k s t a t i o n . Full-system tests,
of course, needed to run on real robots.
The great thing about robots is y o u can see y o u r code at w o r k .
The not-so-great thing is y o u can see (and hear and sometimes
smell) y o u r code fail. But more importantly, robots are not a
perfect environment. Each robot is different—it’s a combination
of thousands of mechanical and electrical parts, each with some
v a r i a t i o n . Therefore, it’s essential to test with multiple robots.
The same is true of more traditional systems: v e n d o r software

can crash, networks have latency, hard disks can barf up bad
data. Y o u r company’s test lab should simulate these less-ideal
environments, because ultimately y o u r product will encounter
them in customers’ hands.
overlooks. Directed exploratory testing ferrets out those
corner cases.
This testing is often performed by a human, perhaps the
programmers themselves, to explore and discover problems.
P a s t the initial exploration, however, any useful tests are
added to the acceptance test suite.
There are specialized v a r i a t i o n s on this theme, such as a
security audit. In those cases, a specialized tester uses their
domain expertise (and perhaps code review) to direct their
testing.
Agency Testing
Hardware products need v a r i o u s agency certifications: the
FCC measures electromagnetic emissions to ensure the
product doesn’t create radio interference; Underwriter’s
Laboratories (UL) looks at what happens when y o u set the
product on fire or lick its battery terminals. These tests are
run before a new product is launched and any time a hard-
w a r e change could affect the certification.
Environmental Testing
Hardware products also need to be pushed to extremes in
operating temperature and humidity. These are tested with
8 • Chapter 1. Program for Production


www.it-ebooks.info
White Box, Black Box

Y o u ’ l l hear the terms white-box and black-box testing. In white-
box testing, y o u get to look inside the program and see whether
everything is w o r k i n g right. Unit tests are a good example.
Black-box testing, on the other hand, looks at the product as the
customer w o u l d see it; what goes on inside isn’t relevant, only
that the product does the right thing on the outside. Acceptance
and load tests are forms of black-box testing.
an environmental chamber that controls both factors; it goes
to each of the four extremes while the product is operating
inside.
Compatibility Testing
When products need to interoperate with other prod-
ucts—for example, a wo r d processing program needs to
exchange documents with other w o r d processors—these
compatibility claims need to be v e r i f i e d on a regular basis.
They may run against a corpus of saved documents or in
real time with y o u r product connected to other products.
Longevity Testing
Y o u ’ l l notice that most of the tests mentioned here are run
as often and as quickly as possible. Some bugs, however,
show up only after extended use. Our 49.7-day bug is a good
example—that comes from a 32-bit counter that increments
every millisecond, and after 49.7 days it rolls over from its
maximum v a l u e back to zero.
2
Y o u w o n ’ t be able to find a
bug like that unless y o u run tests for extended durations.
Beta Test
Here’s where the product goes out to real customers—but
they’re customers who know what they’re getting into, and

they’ve agreed to submit reports if they find problems. The
purpose of a beta test is exactly what w e discussed at the
beginning of this tip: the beta tester will use the product in
w a y s y o u don’t anticipate, test it for extended periods of
time, and test it in environments y o u didn’t test in.
2. 2
32
= 4,294,967,296 milliseconds = 49.7 days, assuming an unsigned
counter. See
GetTickCount()
on W i n d o w s as an example.

Beat Up Your Code • 9

www.it-ebooks.info
Ongoing Testing
Y o u r company may continue to test after a product ships.
For hardware products in particular, it’s useful to pull a unit
off the manufacturing line once in a while and v e r i f y that it
w o r k s . These ongoing tests are designed to capture problems
due to v a r i a t i o n s in parts or assembly process.
Practices vs. Mind-Set
Y o u r team may have practices like “all code must have unit
tests” or “all code must be reviewed before checking in.”
But none of these practices will guarantee rock-solid code.
Think about what y o u ’ d do if there we r e zero quality prac-
tices at y o u r company—how w o u l d you beat up y o u r code
to make sure it’s solid?
This is the mind-set y o u need to establish before going fur-
ther. Commit to solid code. The quality practices are just a

means to an end—the ultimate judge will be the product’s
reliability in the hands of y o u r customers. Do y o u w a n t to
have y o u r name a ssocia ted w ith a product that h it the mar ket
as a buggy piece of junk? No, of course not.
Actions
• Of all the forms of testing mentioned earlier, which of
these does yo u r company use? Find the unit tests in the
source code, ask the test department for the acceptance
test plan, and ask how beta tests are done and where
that feedback goes. Also ask a senior engineer’s opinion:
is this enough to ensure a smooth experience for the
customer?
• Spend some time doing directed exploratory testing,
even if y o u r “direction” is somewhat v a g u e . Really use
the product to see whether y o u can break it. If yo u can,
file bug reports accordingly.
10 • Chapter 1. Program for Production


www.it-ebooks.info
Tip 2
Insist on Correctness
[White Belt] These considerations are essen-
tial to your coding from day one.
In toy programs it’s easy to tell the difference between correct
and incorrect. Does
factorial(n)
return the correct number?
That’s easy to check: one number goes in, and another
number comes out. But in big programs, there are potentially

many inputs—not just function parameters, but also state
within the system—and many outputs or other side effects.
That’s not so easy to check.
Isolation and Side Effects
T e x t b o o k s love to use math problems for programming
examples, partly because computers are good at math, but
mostly because it’s easy to reason about numbers in isolation.
Y o u can call
factorial(5)
all day long, and it’ll return the same
thing. Network connections, files on disk, or (especially)
users have a nasty habit of not being so predictable.
When a function changes something outside its local v a r i -
ables—for example, it writes data to a file or a network
socket—it’s said to have side effects. The opposite, a pure
function, always returns the same thing when given the
same arguments and does not change any outside state.
Obviously, pure functions are a lot easier to test than func-
tions with side effects.
Most programs have a mix of pure and impure code; how-
ever, not many programmers think about which parts are
which. Y o u might see something like this:
Download ReadStudentGrades.rb
def self.import_csv(filename)
File.open(filename) do |file|
file.each_line do |line|
name, grade = line.split(',')

Insist on Correctness • 11

www.it-ebooks.info