MistrzCzystegoKodu PDF

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.
com
Tytu oryginau: The Clean Coder: A Code of Conduct for Professional Programmers
Tumaczenie: Wojciech Moch
ISBN: 978-83-246-7537-1
Authorized translation from the English language edition, entitled: THE CLEAN CODER:
A CODE OF CONDUCT FOR PROFESSIONAL PROGRAMMERS; ISBN 0137081073;
by Robert C. Martin; published by Pearson Education, Inc, publishing as Prentice Hall.
Copyright 2011 Pearson Education, Inc.
All rights reserved. No part of this book may be reproduced od transmitted in any form or by any means, electronic or
mechanical, including photocopying, recording or by any information storage retrieval system, without permission from
Pearson Education, Inc.
Polish language edition published by HELION S.A., Copyright 2013.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or
mechanical, including photocopying, recording or by any information storage retrieval system, without permission from
the Publisher.
Wszelkie prawa zastrzeone. Nieautoryzowane rozpowszechnianie caoci lub fragmentu niniejszej publikacji
w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metod kserograficzn, fotograficzn, a take kopiowanie
ksiki na noniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji.
Wszystkie znaki wystpujce w tekcie s zastrzeonymi znakami firmowymi bd towarowymi ich wacicieli.
Autor oraz Wydawnictwo HELION dooyli wszelkich stara, by zawarte w tej ksice informacje byy kompletne
i rzetelne. Nie bior jednak adnej odpowiedzialnoci ani za ich wykorzystanie, ani za zwizane z tym ewentualne
naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponosz rwnie adnej
odpowiedzialnoci za ewentualne szkody wynike z wykorzystania informacji zawartych w ksice.
Wydawnictwo HELION
ul. Kociuszki 1c, 44-100 GLIWICE
tel. 32 231 22 19, 32 230 98 63
e-mail: helion@helion.pl
WWW: http://helion.pl (ksigarnia internetowa, katalog ksiek)
Drogi Czytelniku!
Jeeli chcesz oceni t ksik, zajrzyj pod adres
http://helion.pl/user/opinie/mckkod_ebook
Moesz tam wpisa swoje uwagi, spostrzeenia, recenzj.
Printed in Poland.
Pole ksik na Facebook.com
Ksigarnia internetowa
Kup w wersji papierowej
Lubi to! Nasza spoeczno
Oce ksik
Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com
Pochway dla Mistrza czystego kodu

Wujek Bob Martin w swojej nowej ksice zdecydowanie podnosi poprzeczk. Opisuje
swoje oczekiwania wobec zawodowych programistw w zakresie interakcji z kadr
zarzdzajc, zarzdzania czasem, radzenia sobie z presj, wsppracy w zespole oraz
doboru narzdzi. Martin zaznacza, e kady programista chccy uznawa si za
profesjonalist powinien zna techniki wykraczajce poza TDD oraz ATDD, a dodatkowo
powinien cile ledzi ich rozwj, tak eby podsyca swoj pasj do programowania.
Markus Grtner
Senior Software Developer
it-agile GmbH
www.it-agile.de
www.shino.de
Niektre ksiki techniczne nie tylko ucz, ale te inspiruj. Inne zachwycaj i bawi. Tylko
rzadko zdarza si, eby ksika techniczna miaa te wszystkie cechy. Ksiki Roberta Martina
zawsze na mnie dziaay, a Mistrz czystego kodu nie jest tu wyjtkiem. Czytaj, ucz si,
poznawaj lekcje zawarte w ksice, a z pewnoci uznasz si za zawodowego programist.
George Bullock
Senior Program Manager
Microsoft Corp.
Jeeli do uzyskania tytuu nauk komputerowych konieczne byoby przeczytanie pewnej
lektury, to na pewno byaby to ta ksika. W rzeczywistym wiecie zy kod nie znika
po zakoczeniu semestru, nie dostaje si pitki za maraton kodowania na dzie przed
oddaniem projektu, a najgorsze jest to, e trzeba kontaktowa si z innymi ludmi. Oznacza
to, e guru programowania niekoniecznie mona nazwa zawodowcami. Mistrz czystego
kodu opisuje podr w kierunku profesjonalizmu a robi to w wyjtkowo zabawny sposb.
Jeff Overbey
Uniwersytet stanu Illinois w UrbanaChampaign
Mistrz czystego kodu jest czym wicej ni tylko zbiorem zasad i wskazwek. Zawiera
mdro popart praktyk oraz wiedz, ktr normalnie trzeba zdobywa przez lata prb
i bdw, pracujc jako ucze mistrza. Jeeli nazywasz siebie zawodowym programist,
to ta ksika jest dla Ciebie niezbdna.
R.L. Bogetti
Lead System Designer
Baxter Healthcare
www.RLBogetti.com
W latach od 1986 do 2000 cile wsppracowaem z Jimem Newkirkiem, koleg z firmy

Teradyne. Mielimy wspln pasj do programowania i tworzenia czystego kodu.
Razem spdzalimy cae wieczory i noce, a nawet weekendy, bawic si rnymi stylami
programowania oraz technikami projektowymi. Bez ustanku zastanawialimy si nad
rnymi pomysami na biznes. W kocu zaoylimy firm Object Mentor Inc. Podczas
wsplnych prac nauczyem si od Jima wielu rzeczy. Jednak jego najwaniejsz cech
bya etyka pracy. To co, nad czym staram si cay czas pracowa. Jim jest zawodowcem,
a ja jestem dumny, e mogem razem z nim pracowa i nazywa go moim przyjacielem.
S PIS TRECI
Sowo wstpne
11
Wprowadzenie
17
Podzikowania
21
O autorze
25
Na okadce
27
Obowizkowy wstp
29
Rozdzia 1
Profesjonalizm
35
Uwaaj, czego sobie yczysz

Przejmowanie odpowiedzialnoci
Po pierwsze nie szkodzi
Etyka pracy
Bibliografia
36
36
38
43
48
Kiedy mwi nie
49
Przeciwstawne role
Wysokie stawki
Gracz zespoowy
Koszta przytakiwania
Kod niemoliwy
51
54
55
60
65
Rozdzia 2
7
S PIS TRECI
Rozdzia 3
Rozdzia 4
Rozdzia 5
Rozdzia 6
Kiedy mwi tak
69
Jzyk zobowiza
Naucz si, jak mwi tak
Wnioski
71
75
78
Kodowanie
79
Przygotowanie
Strefa
Blokada twrcza
Debugowanie
Wyznaczanie sobie rytmu
Spnienia
Pomoc
Bibliografia
80
83
85
87
90
91
93
95
TDD
97
Sd na sali
Trzy prawa TDD
Czym TDD nie jest
Bibliografia
98
99
103
103
wiczenia
Kilka wicze w tle
Dojo kodowania
Zwikszanie dowiadczenia
Wnioski
Bibliografia
Rozdzia 7
Rozdzia 8
Testy akceptacyjne
105
106
109
112
113
113
115
Komunikowanie wymaga
Testy akceptacyjne
Wnioski
115
120
129
Strategie testowania
131
Kontrola jakoci nie powinna nic znale

Piramida automatyzacji testw
Wnioski
Bibliografia
8
132
133
136
136
S PIS TRECI
Rozdzia 9
Zarzdzanie czasem
Spotkania
Manna skupienia
Paczkowanie czasu i pomidory
Uniki
lepe uliczki
Marsze, bagna i baagan
Wnioski
Rozdzia 10
Szacowanie
Czym jest szacowanie?
PERT
Szacowanie zada
Prawo wielkich liczb
Wnioski
Bibliografia
Rozdzia 11
Presja
Unikanie presji
Jak radzi sobie z presj
Wnioski
Rozdzia 12
Wsppraca
Programici kontra ludzie
Mdki
Wnioski
Rozdzia 13
Rozdzia 14
137
138
142
144
145
146
146
147
149
151
154
157
159
160
160
161
163
165
166
167
169
173
174
Zespoy i projekty
175
Mona to zmiksowa?
Wnioski
Bibliografia
176
178
179
Nauczanie, terminowanie i mistrzostwo

Stopnie niepowodzenia
Nauczanie
Terminowanie
Rzemioso
Wnioski
181
181
182
187
190
191
9
S PIS TRECI
Dodatek A
Narzdzia
Narzdzia
Kontrola kodu rdowego
IDE i edytor
ledzenie problemw
Ciga kompilacja
Narzdzia do testw jednostkowych
Narzdzia do testw komponentw
Narzdzia do testw integracyjnych
UML/MDA
Wnioski
Skorowidz
10
193
195
195
199
201
202
202
203
204
205
207
209
S OWO WSTPNE
Skoro ta ksika wzbudzia w Tobie zainteresowanie, to zakadam, e mam do czynienia

z zawodowcem. To dobrze, bo i ja si za takiego uwaam. A skoro zdobyem ju Twoje
zainteresowanie, to pozwl, e powiem, dlaczego ja zajem si t ksik.
Wszystko zaczo si nie tak dawno temu, w cakiem nieodlegym miejscu. Kurtyna w gr,
wiata, kamery i Charley
Kilka lat temu pracowaem w redniej wielkoci korporacji sprzedajcej produkty podlegajce
cisej regulacji. Z pewnoci znasz ten typ: siedzielimy w przedziaach, w trzypitrowym
budynku. Dyrektorzy i tym podobni mieli prywatne gabinety, a zebranie wszystkich osb
potrzebnych na jednym spotkaniu trwao mniej wicej tydzie.
Dziaalimy na rynku z bardzo du konkurencj, a wtedy rzd otworzy drzwi dla cakowicie
nowego produktu.
Nagle stana przed nami caa rzesza nowych, potencjalnych klientw. Wystarczyo tylko
przekona ich do zakupu naszego produktu. Oznaczao to, e musielimy zoy we
waciwym czasie i w odpowiednim urzdzie pewien dokument, nastpnie w okrelonym
terminie przej pozytywnie audyt i szybko wprowadzi produkt na rynek.
Od czasu do czasu kadra zarzdzajca przypominaa nam o tym, jak wane s poszczeglne
daty. Jeden polizg i urzdnicy na rok wyklucz nas z rynku, a jeeli klienci nie bd mogli
skorzysta z naszego produktu ju od samego pocztku, to pjd do konkurencji, przez co
cakowicie wypadniemy z obiegu.
Powstao to specyficzne rodowisko, w ktrym cz ludzi narzeka, a inni powtarzaj tylko,
e pod cinieniem powstaj diamenty.
11
S OWO WSTPNE
Byem technicznym menederem projektu, awansowanym z dziau rozwojowego. Moim

zadaniem byo uruchomienie strony projektu w dniu jego oficjalnego udostpnienia, tak
eby potencjalni klienci mogli pobra niezbdne informacje, a przede wszystkim formularze
zamwie. Moim wsppracownikiem w ramach tego projektu by meneder biznesowy,
ktrego tutaj bd nazywa Joe. Jego zadaniem bya praca po drugiej stronie, czyli obsuga
sprzeday, marketingu oraz wymaga niezwizanych z technikaliami. By te jednym z tych
powtarzajcych fraz o diamentach powstajcych pod cinieniem.
Jeeli zdarzyo Ci si pracowa w amerykaskich korporacjach, to zapewne wiesz, e to cae
wskazywanie palcem, poszukiwanie winnych i niech do pracy s cakowicie naturalne.
W naszej firmie Joe i ja znalelimy cakiem ciekawe rozwizanie tego problemu.
Naszym zadaniem byo wykonanie roboty i czulimy si z tym zupenie jak Batman i Robin.
Codziennie spotykaem si z zespoem technicznym, za kadym razem poprawialimy plan
prac, wypatrywalimy potencjalnych problemw i usuwalimy z naszej drogi wszystkie
powstajce przeszkody. Jeeli kto potrzebowa okrelonego oprogramowania, to je
zdobywalimy. Jeeli kto z chci zajby si konfiguracj zapory internetowej, ale
o rany, wanie mam przerw obiadow, to kupowalimy i dostarczalimy cay obiad.
Jeeli kto chcia popracowa nad problemem z konfiguracj, ale mia aktualnie inne
priorytety, to Joe i ja zaczynalimy rozmawia z jego przeoonym.
A potem z menederem.
A potem z dyrektorem.
Po prostu wszystko zaatwialimy.
Moe pewn przesad jest twierdzenie, e przewracalimy krzesa, krzyczelimy
i wrzeszczelimy, ale dla osignicia celu wykorzystalimy wszystkie znane nam metody,
przy okazji wymylajc kilka nowych. Wszystko, co robilimy, robilimy zgodnie z zasadami
etyki, z czego jestem dumny do dzisiaj.
Uwaaem si za czonka zespou. Nie byem ponad to, eby samodzielnie napisa
wymagane zapytanie SQL albo wykona inne prace, byle tylko przygotowa kod na czas.
Wtedy podobnie mylaem i o Joe jako o czonku zespou, a nie kim ponad nami.
Ostatecznie przekonaem si, e Joe nie podziela tej opinii. To by dla mnie bardzo
smutny dzie.
By pitek, godzina 13.00, a tworzona przez nas strona bya gotowa do uruchomienia
w nastpny poniedziaek.
Bylimy gotowi. GOTOWI. Kady system by sprawdzony i przygotowany. Zebraem cay
zesp w ramach ostatniego spotkania scrumu, na ktrym gratulowalimy sobie doskonaej
12
S OWO WSTPNE
pracy. I nie chodzio tylko o zesp techniczny. Towarzyszyy nam te osoby z dziau
marketingu, a nawet waciciele produktu.
Wszyscy bylimy dumni. To by naprawd wspaniay moment.
Wtedy na zebranie wpad Joe.
Powiedzia co w rodzaju: Ze wieci. Dzia prawny nie przygotowa jeszcze formularzy
zamwie, czyli nie moemy jeszcze uruchomi strony.
Nie by to wielki problem. Przez cay czas trwania projektu wstrzymyway nas najrniejsze
przeciwnoci, dziki czemu cakiem dobrze odnajdowalimy si w rolach Batmana i Robina.
Byem gotowy, dlatego odpowiedziaem: Dobra, partnerze. Zrobimy to jeszcze raz. Dzia
prawny jest na trzecim pitrze, o ile pamitam.
I wtedy si zaczo.
Zamiast si ze mn zgodzi, Joe zapyta: O czym ty w ogle mwisz, Matt?.
Odpowiedziaem: No wiesz, ten nasz zwyczajowy taniec. W kocu chodzi o cztery pliki
PDF. Do tego one s gotowe. Dzia prawny musi tylko je zatwierdzi. Powisimy w ich
boksach, pozocimy si na nich i w kocu to zaatwi.
Joe nie zgodzi si z moj ocen i po prostu stwierdzi: Uruchomimy stron w cigu
przyszego tygodnia. To przecie aden kopot.
Z pewnoci moesz sobie wyobrazi cig dalszy tej rozmowy. Szo mniej wicej tak:
Matt: A niby dlaczego? Przecie mog to zrobi w par godzin.
Joe:
Oj, to moe potrwa troch duej.
Matt: Przecie maj cay weekend. To masa czasu. Do roboty!.

Joe:
Matt, to przecie zawodowcy. Nie moemy przecie wisie nad nimi i da,
eby powicali swj prywatny czas dla naszego maego projektu.
Matt: (chwila ciszy) Joe a co niby robilimy z zespoem inynierw przez kilka
ostatnich miesicy?.
Joe:
No tak, ale tutaj mwimy o zawodowcach.
Cisza.
Gboki oddech.
Co. Joe. Wanie. Powiedzia?
13
S OWO WSTPNE
W tym czasie uwaaem, e zesp techniczny skada si z zawodowcw w najlepszym

znaczeniu tego sowa.
Teraz gdy o tym myl, wcale nie jestem tego pewien.
Przyjrzyjmy si jeszcze raz technice Batmana i Robina, przyjmujc tym razem inn
perspektyw. Sdziem, e w ten sposb motywujemy zesp do jeszcze lepszej pracy,
ale teraz myl, e Joe bawi si z nami i zakada, e zesp techniczny jest jego
przeciwnikiem. Wystarczy pomyle: Dlaczego konieczne byy cige bieganie,
przewracanie krzese i inne dziaania?
Czy nie moglimy po prostu zapyta zespou, kiedy bd gotowi, otrzyma solidnej
odpowiedzi, w ktr moglibymy uwierzy, i si na niej nie sparzy?
Oczywicie w przypadku zawodowcw moglibymy a jednoczenie wcale nie. Joe nie
dowierza naszym zapewnieniom i dlatego uzna, e konieczne bdzie mikrozarzdzanie
caym zespoem technicznym. Rwnoczenie z tych samych powodw by w stanie
zaufa dziaowi prawnemu i wcale nie chcia stosowa wobec nich mikrozarzdzania.
O co tu chodzi?
W jaki sposb dzia prawny zademonstrowa swj profesjonalizm, czego nie zdoa zrobi
zesp techniczny.
Innej grupie udao si przekona Joego, e niepotrzebny jest jej nadzorca, e nie bawi si
w takie gierki i e naley ich traktowa jak godnych szacunku wsppracownikw.
Nie sdz, eby miay tu znaczenie te wszystkie certyfikaty wiszce na cianach ani kilka
dodatkowych lat studiw. Cho to ostatnie mogo pomc w uzyskaniu dowiadczenia
i umiejtnoci waciwego zachowania si w takich sytuacjach.
Od tego dnia, a byo to ju lata temu, zastanawiaem si, jak bd si musiay zmieni
zawody techniczne, eby w kocu ich przedstawicieli uznano za zawodowcw.
I rzeczywicie wpado mi kilka pomysw. Troch blogowaem, sporo czytaem, zdoaem
poprawi wasn sytuacj w pracy, a nawet pomc kilku innym osobom. Nie znam jednak
adnej ksiki, ktra szkicowaaby czytelnikowi okrelony plan i jawnie prezentowaa
poszczeglne elementy.
W kocu ktrego dnia, cakowicie niespodziewanie, otrzymaem ofert recenzowania
wczesnego szkicu ksiki. Dokadnie tej, ktr wanie trzymasz w rku.
To z tej ksiki dowiesz si, jak prezentowa si i wsppracowa jak na zawodowca
przystao. Bez stosowania tanich sztuczek, bez wykorzystywania hakw, ale wanie tak,
jak naley to robi.
14
S OWO WSTPNE
W niektrych przypadkach takie przykady s absolutnie dosowne.

Cz przykadw zawiera odpowiedzi, kontry, wyjanienia, a nawet porady na wypadek,
gdyby ta druga osoba prbowaa Ci po prostu ignorowa.
Och, popatrz na to, Joe wraca na scen, cho tym razem co si zmienia: znowu jestemy
w wielkiej firmie, Joe i ja, i znw pracujemy nad wielkim projektem konwersji strony WWW.
Jednak tym razem wyobra sobie nieco inn sytuacj.
Zamiast unika zobowiza, zesp techniczny faktycznie je podejmuje. Zamiast przemilcza
szacunki albo pozwala na przygotowywanie planw przez innych (a potem narzeka na te
plany), zesp techniczny sam si organizuje i definiuje rzeczywiste zobowizania.
Wyobra sobie, e taki zesp rzeczywicie ze sob wsppracuje. Jeeli infrastruktura
wytrzymuje programistw, to wystarczy jeden telefon, eby administratorzy wykonali
niezbdne prace.
Gdy Joe zamierza przyspieszy prace nad bdem 14321, to okazuje si, e nie ma takiej
potrzeby, poniewa od razu widzi, e administrator bazy danych nad nim pracuje, a nie
surfuje w sieci. Podobnie wszystkie szacunki, jakie otrzyma od zespou, nie s ze sob
sprzeczne i nie tworz wraenia, e cay projekt otrzyma priorytet gdzie midzy obiadem
a sprawdzaniem poczty. Na wszelkie prby manipulowania przygotowanym planem zesp
nie odpowiada sprbujemy, ale to s nasze zobowizania, jeeli chcesz tworzy wasne,
to rb je we wasnym zakresie.
Sdz, e po pewnym czasie Joe zaczby uwaa zesp techniczny za, zaskoczenie,
zawodowcw. I miaby cakowit racj.
Co trzeba zrobi, eby przeksztaci si ze zwykego technika w zawodowca? Wszystko
znajdziesz w tej ksice.
Witaj na kolejnym etapie swojej kariery. Wydaje mi si, e bdzie Ci si podoba.
Matthew Heusser
Software Process Naturalist
15
S OWO WSTPNE
16
Wprowadzenie
28 stycznia 1986 roku, o godzinie 11.39, po zaledwie 73,124 sekundy od startu, na wysokoci
48 000 stp prom kosmiczny Challenger zosta rozerwany na strzpy przez uszkodzenie
prawego silnika wspomagajcego. Zgino siedmioro dzielnych astronautw, w tym
nauczycielka Christa McAuliffe. Do dzisiaj przeladuje mnie wyraz twarzy jej matki
obserwujcej mier swojej crki 15 kilometrw nad sob.
Challenger rozpad si, poniewa gorce gazy wylotowe z uszkodzonego silnika
wspomagajcego wydostay si spomidzy segmentw jego obudowy, trafiajc na gwny
zbiornik paliwa. Podstawa gwnego zbiornika z ciekym wodorem zostaa rozerwana,
paliwo si zapalio, przez co zbiornik przesun si w kierunku zbiornika z ciekym
tlenem. W tym samym momencie silnik wspomagajcy zerwa si z tylnego wspornika
i obrci wok tylnego. Jego czubek przebi zbiornik z ciekym tlenem. Te wszystkie
17
WPOWADZENIE
nieskoordynowane siy spowodoway, e leccy z prdkoci 1,5 macha prom zacz

obraca si w poprzek strumienia powietrza. Siy aerodynamiczne szybko rozerway cao
na kawaeczki.
Pomidzy koncentrycznymi segmentami silnika znajdoway si dwie okrge uszczelki
z syntetycznej gumy. Gdy segmenty byy czone ze sob, uszczelki zostay cinite,
tworzc uszczelnienie, ktrego gazy wylotowe nie powinny by w stanie przebi.
Niestety, w noc poprzedzajc start temperatura na wyrzutni spada do 8C (17F), czyli
o 12C (23F) poniej minimalnej temperatury dla tych uszczelek. Byo to te o caych
18C (33F) mniej ni przy ktrymkolwiek wczeniejszym starcie. W efekcie uszczelki
zesztywniay i nie byy w stanie odpowiednio blokowa gorcych gazw. W momencie
odpalenia silnika wspomagajcego nastpi nagy wzrost cinienia wynikajcy z szybkiego
gromadzenia si gazw wylotowych. Segmenty silnika zostay rozcignite, co zmniejszyo
stopie cinicia uszczelek, ktre byy na tyle zesztywniae, e nie zdoay si odpowiednio
rozpry i wypeni powstaych szczelin. W efekcie cz uciekajcych gorcych gazw
odparowaa uszczelki na dugoci 70% uku.
Inynierowie z firmy Morton-Thiokol, ktrzy projektowali silniki wspomagajce, wiedzieli
o problemach z uszczelkami i przez siedem poprzednich lat informowali o nich kadr
zarzdzajc firmy oraz NASA. Rzeczywicie uszczelki uywane w poprzednich startach
zostay uszkodzone na kilka rnych sposobw, cho adne z tych uszkodze nie mogo
doprowadzi do katastrofy. Podczas startu w najniszej temperaturze zostay jednak
uszkodzone najmocniej. Inynierowie przygotowali rozwizanie tego problemu, ale jego
wprowadzenie zostao mocno opnione.
Inynierowie podejrzewali, e uszczelki sztywniay pod wpywem zimna. Wiedzieli te,
e temperatury panujce podczas startu Challengera byy nisze ni podczas ktregokolwiek
wczeniejszego startu znacznie poniej temperatury dopuszczalnej. W skrcie:
inynierowie wiedzieli, e ryzyko jest zbyt wielkie i wykorzystujc t wiedz, zaczli
odpowiednio dziaa. Pisali notatki i zapalali wiata alarmowe. Nastawali na menederw
Thiokolu i NASA, eby opni start. Na jedenastogodzinnym spotkaniu tu przed
startem zaprezentowali wszystkim posiadane dane. Wciekali si, przymilali, komu trzeba,
i protestowali. Ostatecznie jednak menederowie ich zignorowali.
Cz inynierw nie chciaa nawet oglda przekazw ze startu wahadowca, poniewa
obawiali si, e wybuchnie jeszcze na platformie. Jednak Challenger zgrabnie wznis si
w niebo, przez co napicie zaczo opada. Na kilka chwil przed zniszczeniem pojazdu,
w momencie gdy przekracza on prdko 1 macha, jeden z inynierw stwierdzi,
e tym razem si udao.
Mimo wszystkich protestw, notatek i uwag zgaszanych przez inynierw menederowie
uznali, e to oni maj racj. Sdzili, e inynierowie najzwyczajniej przesadzaj, dlatego
18
WPOWADZENIE
nie ufali ich danym oraz wnioskom. Uruchomili silniki Challengera, poniewa sami byli
pod wielk presj finansow i polityczn. Mieli tylko nadziej, e wszystko si uda.
Wszyscy ci menederowie nie tylko byli gupi, ale stali si przestpcami. Tego mronego
poranka zgino siedmioro dzielnych kobiet i mczyzn, a nadzieje caych pokole
marzcych o podrach w kosmos zostay zawiedzione dlatego, e kilku menederw
przedoyo wasne obawy, nadzieje i przeczucia nad sowa zatrudnianych przez siebie
ekspertw. Podjli decyzj, ktrej nie mieli prawa podejmowa. Przypisali sobie autorytet
ludzi, ktrzy wiedzieli, co robi: inynierw.
A co z inynierami? Z pewnoci zrobili to wszystko, co powinni byli zrobi. Poinformowali
przeoonych i ciko walczyli, prezentujc swoje zalecenia. Przeszli przez wszystkie
waciwe kanay i powoali si na odpowiednie protokoy. Zrobili zatem, co mogli w ramach
istniejcego systemu, ale menederowie i tak postawili na swoim. Wyglda na to,
e inynierowie mog mie czyste sumienie.
Czasami jednak zastanawiam si, czy ktry z nich nie moe spa w nocy, przeladowany
przez obraz matki Christy McAuliffe, rozwaajc, dlaczego nie zadzwoni do Dana Rathera.
O tej ksice
To ksika o profesjonalizmie przy tworzeniu oprogramowania. Zawiera wiele
pragmatycznych wskazwek i prbuje w ten sposb odpowiedzie na takie pytania, jak:
Kim jest zawodowy programista?
Jak zachowuje si profesjonalista?
Jak zawodowiec radzi sobie z konfliktami, krtkimi terminami i nierozsdnymi
menederami?
Kiedy i jak profesjonalista powinien powiedzie nie?
Jak zawodowiec radzi sobie z naciskami?
W tych pragmatycznych poradach znajdziesz te rodzc si postaw. Jest to postawa pena

godnoci, honoru, poszanowania oraz dumy. Jest w niej te gotowo do zaakceptowania
tego straszliwego zobowizania zwizanego z byciem rzemielnikiem i inynierem. Czci
tego zobowizania jest konieczno wykonywania czystej i dobrej pracy, a take utrzymania
dobrej komunikacji i dokonywania prawidowych szacunkw. Dotyczy ono te zarzdzania
swoim czasem i mierzenia si ze skomplikowanymi decyzjami typu ryzyko nagroda.
Do tego zobowizania naley te jeszcze jedna, niezwykle przeraajca rzecz. Jako inynier
dysponujesz dogbn wiedz o swoich systemach i projektach, ktra nie jest dostpna dla
menederw. Z t wiedz zwizane jest zobowizanie do dziaania.
19
WPOWADZENIE
Bibliografia
[McConnell87]: Malcolm McConnell, Challenger. A Major Malfunction, New York,
Simon & Schuster, 1987.
[Wiki-Challenger]: Katastrofa promu Challenger, http://pl.wikipedia.org/wiki/
Katastrofa_promu_Challenger.
20
P ODZIKOWANIA
Moja kariera jest ca seri epizodw wsppracy i planowania. Sam miaem wiele rnych
marze i de, ale zawsze udawao mi si znale kogo, kto je podziela. Pod tym wzgldem
czuj si troch jak Sith. Zawsze dwch ich jest.
Pierwsza wsppraca, ktr mgbym uzna za profesjonaln, miaa miejsce, gdy miaem
13 lat, a moim wsppracownikiem by John Marchese. Razem planowalimy zbudowanie
wasnego komputera. Ja miaem mzg, a on minie. Pokazywaem mu, gdzie ma przylutowa
przewd, a on go przylutowywa. Pokazywaem, gdzie ma zamocowa przekanik, a on go
mocowa. To bya przednia zabawa, na ktrej spdzilimy setki godzin. I rzeczywicie
zbudowalimy kilka cakiem imponujco wygldajcych rzeczy wyposaonych w przyciski,
przekaniki, wiateka, a nawet teletekst! Oczywicie adna z tych rzeczy nie wykonywaa
nic konkretnego, ale byy niezwykle imponujce i powicilimy im bardzo duo czasu.
Dzikuj Ci za to, John!
W pierwszym roku szkoy redniej na lekcjach niemieckiego spotkaem Tima Conrada.
Tim by naprawd mdry. Gdy przystpowalimy do budowania komputera, to on by
mzgiem, a ja miniami. Nauczy mnie elektroniki i zapozna z komputerem PDP-8.
Razem zbudowalimy dziaajcy elektroniczny kalkulator 18-bitowy, wykorzystujc
do tego podstawowe elementy. Potrafi on dodawa, odejmowa, mnoy i dzieli. Zajo
nam to wszystkie weekendy jednego roku oraz cae wakacje letnie i boonarodzeniowe.
Pracowalimy nad nim bez ustanku i na koniec kalkulator dziaa doskonale. Dzikuj
Ci za to, Tim!
Razem z Timem nauczyem si programowa komputery. W roku 1968 nie byo to atwe,
ale jako si udao. Zdobylimy ksiki o asemblerze komputera PDP-8, o jzykach Fortran,
Cobol oraz PL/1 i po prostu je pochanialimy. Pisalimy programy, ktrych nie dao si
21
P ODZIKOWANIA
nawet uruchomi, poniewa nie mielimy dostpu do komputera. Ale pisalimy je mimo
to z czystej przyjemnoci.
W drugiej klasie liceum nasza szkoa zacza prowadzi zajcia z nauk komputerowych.
Do modemu telefonicznego o prdkoci 110 bodw podczono teletekst ASR-33. Szkoa
miaa wasne konto w systemie podziau czasu Univac 1108 prowadzonym przez Institute
of Technology w stanie Illinois. Tim i ja bardzo szybko stalimy si faktycznymi operatorami
tego sprztu. Nikt poza nami nie mia prawa si do niego zblia.
Poczenie modemowe wykonywao si przez podniesienie suchawki i rczne wybranie
numeru. Po usyszeniu piskw modemu z drugiej strony naleao nacisn przycisk orig
na teletekcie, eby nasz modem zacz piszcze w drug stron. Teraz wystarczyo odwiesi
suchawk i poczenie byo ustanowione.
Tarcza telefonu bya zabezpieczona kluczem, do ktrego dostp mieli wycznie nauczyciele.
Nie miao to jednak znaczenia, poniewa wykombinowalimy, e mona wybra numer
(dowolny), wystukujc go za pomoc wycznika pod suchawk. Byem perkusist, wic
miaem cakiem nieze wyczucie czasu i refleks. Nawet przy zablokowanej tarczy telefonu
byem w stanie wybra numer w mniej ni 10 sekund.
W laboratorium dostpne byy dwa telegrafy. Tylko jeden z nich by maszyn podczon
do sieci telefonicznej, ale oba byy uywane przez uczniw do pisania programw. Pisali
oni programy, ktrych kod by wybijany na tamie papierowej. Kade nacinicie klawisza
powodowao wybicie nowych dziurek w tamie. Programy byy pisane w niezwykle
rozbudowanym, interpretowanym jzyku IITran. Przygotowane tamy z programami
naleao zostawi w koszyku umieszczonym obok telegrafw.
Po szkole Tim i ja wybieralimy numer komputera (oczywicie wystukujc go), adowalimy
zawarto tam do systemu wykonawczego IITran i rozczalimy si. Przy prdkoci 10
znakw na sekund caa procedura zajmowaa troch czasu. Po mniej wicej godzinie
ponownie czylimy si z komputerem, aby wydrukowa wyniki. Znw z prdkoci 10
znakw na sekund. System nie rozdziela listingw poszczeglnych uczniw na pojedyncze
strony. Drukowa po prostu stron za stron, dlatego musielimy poci je noyczkami,
doczy odpowiednie tamy z programami i odoy do koszyka z wynikami.
Tim i ja bylimy w tym mistrzami. Nawet nauczyciele nas nie nadzorowali, gdy bylimy
w laboratorium. Wiedzieli, e wykonujemy ich prac, cho nigdy nas o to nie prosili ani
nawet nie zasugerowali takiej moliwoci. Nigdy te nie dostalimy klucza do telefonu.
Po prostu my si tym zajmowalimy, a oni wychodzili, pozostawiajc nam bardzo duo
swobody. Dzikuj zatem moim nauczycielom matematyki: panu McDermitowi, panu
Fogelowi i panu Robienowi.
Potem, po zakoczeniu prac domowych, moglimy zaj si zabaw. Pisalimy program
za programem, a robiy one najrniejsze szalone i dziwaczne rzeczy. Napisalimy program
22
P ODZIKOWANIA
rysujcy okrgi i parabole za pomoc znakw ASCII drukowanych przez telegraf. Pisalimy
generatory losowych sw. Do ostatniej cyfry wyliczalimy silni z 50. Powicalimy cae
godziny na wymylanie programw, pisanie ich i uruchamianie.
Dwa lata pniej Tim, nasz kolega Richard Lloyd i ja zostalimy zatrudnieni jako programici
w firmie ASC Tabulating w Lake Bluff w stanie Illinois. W tym czasie Tim i ja mielimy
po 18 lat. Zdecydowalimy, e liceum to strata czasu i powinnimy od razu zacz nasze
kariery. To wanie w tej firmie spotkalimy Billa Hohriego, Franka Rydera, Wielkiego Jima
Carlina oraz Jona Millera. To dziki nim todzioby mogy si dowiedzie, co oznacza
profesjonalne tworzenie oprogramowania. Dowiadczenie to nie byo ani cakowicie
pozytywne, ani cakowicie negatywne, ale z ca pewnoci byo pouczajce. Dzikuj zatem
wszystkim wymienionym oraz Richardowi, ktry by katalizatorem i si napdow caego
tego procesu.
W wieku 20 lat, po zoeniu wypowiedzenia i uspokojeniu si, przez pewien czas pracowaem
jako serwisant kosiarek do trawy w firmie mojego szwagra. W tym fachu byem tak fatalny,
e szwagier by zmuszony mnie wyrzuci z pracy. I za to Ci dzikuj, Wes!
Jaki rok pniej rozpoczem prac w firmie Outboard Marine Corporation. W tym czasie
miaem ju on i dziecko w drodze. Stamtd te zostaem zwolniony. Dzikuj Wam, John,
Ralph i Tom!
Nastpnie zaczem prac w firmie Teradyne, gdzie spotkaem Russa Ashdowna, Kena
Findera, Boba Copithornea, Chucka Studee oraz CK Srithrana (teraz Krisa Iyera). Ken by
moim szefem, a Chuck i CK kolegami. Od nich wszystkich bardzo duo si nauczyem.
Dzikuj Wam, chopaki!
Pniej pojawi si Mike Carew. W Teradyne razem stworzylimy dynamiczny duet.
Razem napisalimy kilka systemw. Jeeli kto chcia co przygotowa i zrobi to naprawd
szybko, to Bob i Mike doskonale si do tego nadawali. wietnie si razem bawilimy.
Dzikuj Ci, Mike.
Jerry Fitzpatrick rwnie pracowa w Teradyne. Poznalimy si podczas wsplnych
sesji Dungeons & Dragons i bardzo szybko zaczlimy wsppracowa. Napisalimy
oprogramowanie dla Commodore 64 wspomagajce graczy w D&D. W Teradyne
rozpoczlimy te prace nad nowym projektem, ktry otrzyma nazw elektronicznego
recepcjonisty. Pracowalimy razem przez kilka lat, a Jerry zosta i pozosta moim bliskim
przyjacielem. Dzikuj Ci za to, Jerry!
Pracujc dla firmy Teradyne, spdziem cay rok w Anglii, gdzie spotkaem Mikea
Kergozou. Razem snulimy wiele rnych planw, cho wikszo z nich bya zwizana
z motocyklami i pubami. Mike by jednak oddanym programist powicajcym wiele
uwagi kwestiom jakoci i dyscypliny (cho sam pewnie by si nie zgodzi z tym twierdzeniem).
Dzikuj Ci, Mike!
23
P ODZIKOWANIA
Gdy w 1987 roku wrciem z Anglii, zaczem swoje zwyke planowanie wsplnie z Jimem
Newkirkiem. Obaj odeszlimy z Teradyne (w odstpie miesica) i zatrudnilimy si
w start-upie o nazwie Clear Communications. Nastpnych kilka lat spdzilimy razem,
harujc w nadziei na miliony, ktre jako si nie pojawiy. Nigdy jednak nie zaprzestalimy
planowania. Dzikuj Ci, Jim!
Na koniec wsplnie zaoylimy firm Object Mentor. Jim jest najbardziej bezporedni,
zdyscyplinowan i skupion osob, z jak kiedykolwiek zdarzyo mi si pracowa. Nauczy
mnie tak wielu rzeczy, e nawet trudno byoby mi je wymieni. W zamian zadedykowaem
mu t ksik.
Wsppracowaem i snuem plany z wieloma innymi osobami, a jeszcze wicej miao wpyw
na moje zawodowe ycie: Lowell Lindstrom, Dave Thomas, Michael Feathers, Bob Koss,
Brett Schuchert, Dean Wampler, Pascal Roy, Jeff Langr, James Grenning, Brian Button,
Alan Francis, Mike Hill, Eric Meade, Ron Jeffries, Kent Beck, Martin Fowler, Grady Booch
i wielu, wielu innych. Wszystkim Wam z caego serca dzikuj.
Oczywicie moim najwaniejszym wsppracownikiem bya moja ukochana ona Ann
Marie. Oeniem si z ni w wieku 20 lat, cae trzy dni po jej 18 urodzinach. Przez 38 lat
bya moim niezomnym kompanem, moim sternikiem i aglem, mioci mojego ycia.
Mam nadziej przey z ni kolejne cztery dekady.
Aktualnie moimi wsppracownikami i partnerami w snuciu planw s moje dzieci. cile
wsppracuj z moj najstarsz crk Angel moj dzieln opiekunk i nieustraszon
pomocnic. Nigdy nie pozwala mi zboczy z wybranej cieki ani zapomnie o terminach
lub zobowizaniach. Obmylam plany biznesowe z moim synem Micahem, zaoycielem
firmy 8thlight.com. Musz powiedzie, e ma znacznie lepsz gow do interesw, ni ja
miaem kiedykolwiek. Nasz ostatni projekt cleancoders.com jest naprawd bardzo
ekscytujcy.
Mj modszy syn Justin wanie zacz pracowa razem z Micahem w 8th Light. Z kolei
modsza crka Gina jest chemikiem i pracuje dla Honeywell. Z tymi dwojgiem dopiero
zaczlimy powane planowanie.
To wanie dzieci s w stanie nauczy Ci wicej ni ktokolwiek inny w Twoim yciu.
Dzikuj Wam za to, dzieciaki!
24
AUTORZE
Robert C. Martin (Wujek Bob) by programist od 1970 roku. Jest zaoycielem

i prezesem Object Mentor, midzynarodowej firmy skupiajcej dowiadczonych inynierw
oprogramowania oraz menederw specjalizujcych si we wspomaganiu firm podczas prac
nad najrniejszymi projektami. Firma Object Mentor oferuje korporacjom na caym wiecie
konsultacje z usprawniania procesw i obiektowego projektowania oprogramowania,
szkolenia oraz usugi z zakresu rozwoju umiejtnoci oprogramowania.
Martin opublikowa dziesitki artykuw w najrniejszych specjalistycznych magazynach
i jest czstym prelegentem na midzynarodowych konferencjach i targach.
Jest autorem oraz redaktorem wielu ksiek, w tym:
Designing Object Oriented C++ Applications Using the Booch Method
Patterns Languages of Program Design 3
More C++ Gems
25
AUTORZE
Extreme Programming in Practice

Agile Software Development: Principles, Patterns, and Practices
UML for Java Programmers
Czysty kod. Podrcznik dobrego programisty, (Helion 2010)
Bdc liderem przemysu tworzcego oprogramowanie, Martin przez trzy lata pracowa
jako gwny redaktor magazynu C++ Report oraz przewodniczcy organizacji Agile
Alliance.
Robert jest te zaoycielem firmy Uncle Bob Consulting LLC, a wsplnie ze swoim synem
Micahem wspzaoycielem firmy The Clean Coders LLC.
26
N A OKADCE
Niesamowity obraz umieszczony na okadce (przypomina oko Saurona) to M1 lub mgawica

kraba. M1 znajduje si w gwiazdozbiorze Byka, mniej wicej jeden stopie na prawo od
Zeta Tauri, czyli gwiazdy znajdujcej si na czubku lewego rogu byka. Mgawica kraba jest
pozostaoci po supernowej, ktra wybucha 4 lipca 1054 roku. Mimo odlegoci 6500 lat
wietlnych eksplozja ta pojawia si przed oczami chiskich obserwatorw jako nowa
gwiazda o jasnoci zblionej do jasnoci Jowisza. Podobno bya widoczna nawet w dzie!
Przez nastpnych sze miesicy powoli blada, a znikna z nieboskonu.
27
N A OKADCE
Obrazek umieszczony na okadce jest zoeniem obrazw wiata widzialnego oraz

promieni X. Obraz w wietle widzialnym zosta zarejestrowany przez teleskop Hubbla
i umieszczony w zewntrznej winiecie. Wntrze obrazu, przypominajce troch niebiesk
tarcz ucznicz, zostao zarejestrowane przez teleskop rentgenowski Chandra.
Prezentowany obraz przedstawia szybko rozprzestrzeniajc si chmur pyw i gazw,
poprzetykan ciszymi elementami pozostaymi po eksplozji supernowej. Ta chmura
ma teraz 11 lat wietlnych rednicy, wag rwn 4,5 masy naszego Soca i rozszerza si
z przeraajc prdkoci 1500 kilometrw na sekund. Powiedzie, e energia kinetyczna
tej starej eksplozji jest imponujca, to lekkie niedopowiedzenie.
W samym rodku znajduje si maa niebieska kropka. Wanie w tym miejscu mieci si
pulsar. To jego narodziny spowodoway eksplozj starej gwiazdy. Materia jdra gincej
gwiazdy o masie niemale dorwnujcej masie naszego Soca implodowa, tworzc
kul neutronw o rednicy mniej wicej 30 kilometrw. Energia kinetyczna tej implozji,
poczona z niezwykym ostrzaem neutrin powstaych podczas tworzenia tych wszystkich
neutronw, rozsadzia powoki gwiazdy i rozerwaa j na strzpy.
Powstay pulsar obraca si z prdkoci mniej wicej 30 obrotw na sekund, jednoczenie
byskajc, co moemy obserwowa przez nasze teleskopy. Wanie to pulsujce wiato
sprawio, e takie gwiazdy s nazywane pulsarami, co jest skrtem od Pulsating Star, czyli
pulsujca gwiazda.
28
O BOWIZKOWY WSTP
(Nie pomijaj tego, bdzie pniej potrzebne).
Zakadam, e masz w rce t ksik, poniewa jeste programist i zaintrygowaa Ci

wzmianka o profesjonalizmie. Tak powinno by. Profesjonalizm jest czym, czego nasz
zawd bardzo potrzebuje.
Ja rwnie jestem programist. Byem nim przez ostatnie 421 lata i w tym czasie naprawd
nie kami widziaem ju wszystko. Zostaem zwolniony z pracy, byem wychwalany,
byem szefem zespou, menederem, szeregowym programist, a nawet prezesem firmy.
Wsppracowaem ze znakomitymi programistami, ale i z nieudacznikami. Pracowaem
Bez paniki.
29
O BOWIZKOWY WSTP
na najnowoczeniejszych, osadzonych systemach sprztowo-programowych, ale te na

budetowych systemach korporacyjnych. Programowaem w COBOL-u, FORTRAN-ie,
BAL-u, PDP-8, PDP-11, C, C++, Javie, Ruby, Smalltalku i masie innych jzykw i systemw
operacyjnych. Wsppracowaem z niegodnymi zaufania zodziejami wypat, ale take
z doskonaymi zawodowcami. Ale tematem niniejszej ksiki jest ta ostatnia klasyfikacja.
Na stronach tej ksiki bd si stara zdefiniowa znaczenie terminu profesjonalny
programista. Bd opisywa nastawienie, dyscypliny i dziaania, ktre uwaam za niezbdne
dla osignicia profesjonalizmu.
Skd wiem, e wanie o te cechy chodzi? Poniewa uzyskaem t wiedz w czasie lat swojej
pracy. Gdy dostaem pierwsz prac jako programista, zdecydowanie nie mona byo mnie
okreli mianem profesjonalisty.
By to rok 1969, a ja miaem 17 lat. Mj ojciec namwi lokaln firm o nazwie ASC, eby
zatrudnia mnie jako tymczasowego programist na p etatu. (Owszem, mj ojciec umia
robi takie rzeczy. Raz nawet widziaem, jak wyszed prosto przed mask przekraczajcego
dozwolon prdko samochodu, krzyczc w jego kierunku Stj! Samochd si zatrzyma.
Nikt nie umia odmwi mojemu ojcu). Firma zapdzia mnie do pracy w pomieszczeniu,
w ktrym trzymane byy wszystkie podrczniki do komputerw IBM. Kazali mi doda do
nich cae lata aktualizacji. To wanie wtedy pierwszy raz zobaczyem tekst Ta strona jest
celowo pusta.
Po paru dniach aktualizowania podrcznikw mj przeoony poprosi mnie o napisanie
prostego programu w jzyku Easycoder2. Byem zaszczycony tak prob. Jeszcze nigdy
wczeniej nie pisaem programw dla prawdziwego komputera. Zdyem ju jednak
przeczyta ksik o jzyku Autocoder i wiedziaem mniej wicej, jak naley zacz.
Program mia tylko odczytywa rekordy z tamy i zamienia ich identyfikatory na inne.
Nowe identyfikatory zaczynay si od 1 i kady nastpny rekord mia otrzymywa warto
wiksz o 1 od poprzedniego. Oczywicie rekordy z nowymi identyfikatorami miay by
zapisywane na tamie.
Mj przeoony pokaza mi pk, na ktrej leao wiele zestaww czerwonych i niebieskich
kart perforowanych. Wyobra sobie, e kupujesz 50 talii kart do gry, 25 czerwonych i 25
niebieskich. Nastpnie ukadasz talie jedna na drugiej. Dokadnie tak wyglday te karty
perforowane. Uoone byy w czerwone i niebieskie paski, a kady z paskw skada si
z jakich 200 kart i zawiera kod rdowy biblioteki procedur uywanych przez programistw.
Programici zwykle brali grn tali kart, uwaajc, eby chwyci tylko czerwone albo tylko
niebieskie karty. Potem kadli j na kocu talii ze swoim programem.
Easycoder by jzykiem asemblera komputerw Honeywell H200, bardzo podobnym do jzyka

Autocoder dla komputerw IBM 1401.
30
O BOWIZKOWY WSTP
Swj program napisaem na formularzach do programowania. Byy to wielkie prostoktne

arkusze podzielone na 25 wierszy po 80 kolumn. Kady wiersz reprezentowa jedn kart.
Program pisao si na nich, stosujc wielkie litery i uywajc owka. W ostatnich 6 kolumnach
owkiem zapisywany by numer sekwencji. Zazwyczaj numery byy powikszane o 10,
tak eby moliwe byo pniejsze wstawienie nowych kart.
Formularz by nastpnie przekazywany do wybijaczy kart. W firmie pracowao kilkadziesit
kobiet, ktre pobieray takie formularze z korytka i wpisyway je do maszyn wybijajcych
karty. Maszyny te byy podobne do maszyn do pisania, jednak znaki nie byy drukowane
na papierze, ale wybijane na kartach.
Nazajutrz w firmowej poczcie dostaem swj program w postaci kart perforowanych.
Moja maa talia kart bya owinita w formularz do programowania i gumk. Przejrzaem
wszystkie karty, szukajc na nich bdw powstaych przy przepisywaniu, ale ich nie
znalazem. Wziem zatem tali z bibliotek procedur, poczyem j z tali mojego programu
i zabraem je do operatorw komputerw.
Komputery znajdoway si za zamknitymi drzwiami w pomieszczeniu klimatyzowanym
o podniesionej pododze (musiaa pomieci te wszystkie kable). Zapukaem do drzwi
i jeden z operatorw bez sowa wzi moj tali i pooy j w kolejnym korytku. Gdy przyjdzie
na to czas, zajm si uruchomieniem mojego programu.
Nastpnego dnia znowu dostaem swoj tali. Bya owinita w list wynikw pracy programu,
ktr przytrzymywaa gumka. (W tamtych czasach uywalimy wielu gumek!)
Otwarem list wynikw i zobaczyem, e mojego programu nie udao si skompilowa.
Wypisane komunikaty o bdach byy dla mnie sabo zrozumiae, dlatego poszedem do
przeoonego. Przejrza ca list, mamroczc co pod nosem, dopisa szybko kilka sw,
zapa moj tali kart i kaza i za nim.
Zabra mnie do pokoju z wybijakami kart i usiad przy jednej z wolnych maszyn. Po kolei
poprawia karty zawierajce bdy i doda jedn now lub dwie. Opisywa mi, co wanie
robi, ale wszystko dziao si zdecydowanie za szybko.
Now tali zabra do pomieszczenia komputerw i zapuka do drzwi. Jednemu z operatorw
powiedzia kilka magicznych sw i wszed do pomieszczenia za nim, pokazujc mi, e i ja
mam wej. Operator przygotowa napdy tamowe i zaadowa tali kart, a my po prostu
patrzylimy. Tamy zaczy si krci, drukarka zacza trzaska i ju byo po wszystkim.
Program zadziaa.
Nastpnego dnia mj przeoony podzikowa mi za pomoc i wypowiedzia prac.
Najwyraniej firma nie miaa czasu na niaczenie siedemnastolatka.
Ale moje zwizki z ASC jeszcze si nie skoczyy. Kilka miesicy pniej dostaem peny etat
na drugiej zmianie jako operator drukarek. Drukoway one pisma reklamowe na podstawie
31
O BOWIZKOWY WSTP
danych zapisywanych na tamie. Moim zadaniem byo adowanie papieru do drukarek,

adowanie tam do napdw, usuwanie zacitych kartek i pilnowanie, eby maszyny dziaay.
By rok 1970. Nie miaem szans na studiowanie, ale ta perspektywa nie bya te dla mnie
szczeglnie kuszca. Nadal szalaa wojna w Wietnamie, a na kampusach panowa chaos.
Nadal pochaniaem ksiki o COBOL-u, FORTRAN-ie, PL/1, PDP-8 i asemblerze IBM
360. Miaem plan, eby pomin szko i jak najszybciej dosta prac jako programista.
Dwanacie miesicy pniej udao mi si osign ten cel. Dostaem awans na programist
w firmie ASC. Ja oraz dwch moich dobrych przyjaci, Richard i Tim (rwnie mieli po
19 lat), pracowalimy w zespole z trzema innymi programistami, tworzc dziaajcy w czasie
rzeczywistym system ksigowy dla Teamsters Union. Do dyspozycji mielimy maszyn
Varian 620i, czyli po prostu minikomputer o architekturze zblionej do PDP-8, z t rnic,
e mia 2 rejestry i by 16-bitowy. Uywanym jzykiem by asembler.
W tym systemie pisalimy kady wiersz kodu. Dosownie kady. Napisalimy system
operacyjny, obsug przerwa, sterowniki wejcia i wyjcia, system plikw na potrzeby
dysku, przecznik nakadek, a nawet konsolidator. Nie wspominajc nawet o kodzie samej
aplikacji. Pisalimy to wszystko przez 8 miesicy, pracujc po 70 lub 80 godzin na tydzie,
by dotrzyma wyznaczonego terminu. Moja pensja wynosia wtedy 7200 dolarw rocznie.
Dostarczylimy system na czas, a zaraz potem zoylimy wypowiedzenie.
Odeszlimy nagle i z pen premedytacj. Po tak gigantycznej pracy, gdy na czas
dostarczylimy wietnie dziaajcy system, firma daa nam podwyk o cae 2%.
Czulimy si oszukani i wykorzystani. Niektrzy z nas dostali prac w innych firmach
i po prostu odeszli.
Ja jednak przyjem nie do koca szczliwe rozwizanie. Razem z koleg wpadlimy do
biura naszego szefa i cakiem gono rzucilimy prac. Przez jeden dzie byo to naprawd
satysfakcjonujce.
Nastpnego dnia dotaro do mnie, e nie mam pracy. Miaem 19 lat, byem bezrobotny
i nie miaem skoczonych studiw. Staraem si o kilka stanowisk programisty, ale rozmowy
kwalifikacyjne nie poszy najlepiej. Zaczem wic pracowa w firmie naprawiajcej kosiarki
nalecej do mojego szwagra, w ktrej przetrwaem cztery miesice. Niestety, do naprawiania
kosiarek zupenie si nie nadawaem. Ostatecznie szwagier musia mnie poegna, co napdzio
mi wielkiego stracha.
Co noc siedziaem do 3 nad ranem przed starym czarno-biaym telewizorem moich rodzicw,
jedzc pizz i ogldajc stare filmy o potworach. W ku leaem potem do 1 po poudniu,
poniewa nie chciaem mierzy si z przeraajc rzeczywistoci. Na miejscowym
uniwersytecie skorzystaem z kursu analizy matematycznej, ktrego nie udao mi si zaliczy.
Pograem si.
32
O BOWIZKOWY WSTP
Matka wzia mnie pewnego dnia na stron i powiedziaa mi, e moje ycie to katastrofa,
e byem idiot, rzucajc prac i nie majc nic w zamian, rzucajc j tak emocjonalnie
i wsplnie z koleg. Powiedziaa mi te, e nie wolno rzuca pracy, jeli nie ma si ju
nowego kontraktu, e takie rzeczy robi si po cichu, spokojnie i samodzielnie. Powiedziaa
mi, e mam zadzwoni do swojego byego szefa i baga go o ponowne przyjcie. Na koniec
stwierdzia: Musisz nauczy si pokory.
Dziewitnastoletni chopcy raczej nie maj ochoty na nauk pokory, a ja nie byem adnym
wyjtkiem, jednak okolicznoci mocno nadwtliy moj dum. Ostatecznie musiaem
zadzwoni do byego szefa i si przed nim upokorzy. Ale zadziaao. Bardzo chtnie
zatrudni mnie za 6800 dolarw rocznie, a ja byem szczliwy, e mam prac.
W tej pracy spdziem kolejnych 18 miesicy, pilnujc si i prbujc by jak najbardziej
wartociowym pracownikiem. Zostaem za to nagrodzony awansami, podwykami
i regularn wypat. ycie nabrao kolorw. Gdy ponownie opuciem t firm, odbyo
si to na dobrych warunkach, a co waniejsze, miaem ju wtedy propozycj lepszej pracy.
Moesz sdzi, e czego si w tym czasie nauczyem, e staem si profesjonalist. Byem
od tego daleki. To bya dopiero pierwsza z czekajcych mnie lekcji. W kolejnych latach
zostaem zwolniony z pracy za niedbanie o dotrzymywanie wanych terminw, a z innej
prawie mnie wyrzucono za nieumylne przekazanie klientowi tajnych informacji.
Zajmowaem si prowadzeniem projektu skazanego na porak; pozwoliem na jego
zagad, poniewa nie poprosiem nikogo o pomoc, ktrej tak bardzo potrzebowaem.
Agresywnie broniem swoich decyzji technicznych, mimo e w konfrontacji z potrzebami
klienta nie miay one sensu. Przyjem do pracy osob zupenie do niej nieprzygotowan,
czym wpdziem pracodawc w kopoty prawne. A co gorsza, moja niezdarno jako
przeoony spowodowaa, e dwie osoby zostay zwolnione z pracy.
T ksik mona zatem traktowa jak zbir moich wasnych bdw, katalog moich
wystpkw i zbir wskazwek pozwalajcych Ci unikn wpadnicia w te same puapki.
33
O BOWIZKOWY WSTP
34
P ROFESJONALIZM
miej si, Curtin! Kto spata nam figla! Bg, los, natura sam wybierz.
Jednak ktokolwiek to by, mia nieze poczucie humoru!
Howard, Skarb Sierra Madre
35
R OZDZIA 1.
P ROFESJONALIZM
Dobrze rozumiem, e chcesz by zawodowym programist? Chcesz unie wysoko gow

i zakomunikowa caemu wiatu: Jestem zawodowcem!. Chcesz, eby ludzie patrzyli na
Ciebie z szacunkiem i traktowali Ci z powaaniem. Chcesz, eby matki wskazyway Ci
palcem, mwic swoim dzieciom, e maj stara si upodobni do Ciebie. Tego wanie
chcesz. Mam racj?
Uwaaj, czego sobie yczysz

Profesjonalizm to bardzo przeadowane pojcie. Z ca pewnoci jest powodem do dumy,
ale te znakiem odpowiedzialnoci. Te dwa elementy s nierozczne. Nie da si czu dumy
z czego, za co nie jest si odpowiedzialnym.
Znacznie atwiej jest nie by profesjonalist. Nie trzeba wtedy bra odpowiedzialnoci za
swoj prac t mona pozostawi pracodawcom. Jeeli nieprofesjonalista popenia bd,
to pracodawca musi po nim posprzta. Jeeli jednak bd popenia profesjonalista, to sam
stara si go skorygowa.
Co by si stao, gdyby z powodu Twojego niedopatrzenia do systemu wkrad si bd, ktry
kosztowaby firm 10 000 dolarw? Nieprofesjonalista wzruszyby ramionami, stwierdzajc
takie rzeczy si zdarzaj, i przystpiby do pracy nad kolejnym moduem. Profesjonalista
wypisaby dla firmy czek na kwot 10 000 dolarw1!
Gdy chodzi o Twoje wasne pienidze, cao wyglda nieco inaczej. Ale tak wanie
czuje si profesjonalista. Co wicej, to uczucie jest esencj profesjonalizmu. Po prostu
w profesjonalizmie chodzi o przyjcie odpowiedzialnoci.
Przejmowanie odpowiedzialnoci
Mam nadziej, e przeczytae wprowadzenie. Jeeli nie, to lepiej zrb to w tej chwili.
To wanie wprowadzenie tworzy kontekst dla caej zawartoci ksiki.
Wszystko, co wiem na temat odpowiedzialnoci, poznaem jako konsekwencj braku
odpowiedzialnoci.
W 1979 roku pracowaem dla firmy o nazwie Teradyne. Byem tam inynierem
odpowiedzialnym za oprogramowanie kontrolujce system mini- i mikrokomputerowy
mierzcy jako linii telefonicznych. Centralny minikomputer by poczony za pomoc
dedykowanych linii telefonicznych o szybkoci 300 bodw z dziesitkami satelitarnych
mikrokomputerw sterujcych oprogramowaniem pomiarowym. Cao kodu zostaa
napisana w asemblerze.
Mona mie nadziej, e wyznaje dobre zasady radzenia sobie z bdami i omykami.
36
P RZEJMOWANIE ODPOWIEDZIALNOCI
Naszymi klientami byli menederowie serwisu najwikszych firm telekomunikacyjnych.

Kady z nich by odpowiedzialny za przynajmniej 100 000 linii telefonicznych. Mj system
pomaga im znale i naprawi usterk linii telefonicznej, jeszcze zanim zauwayli j klienci.
Takie dziaanie zmniejszao liczb skarg skadanych przez klientw, ktra bya kontrolowana
przez instytucje publiczne ustalajce stawki pobierane przez firmy telekomunikacyjne.
W skrcie: te systemy byy niezmiernie wane.
Co noc systemy uruchamiay specjaln procedur nocn, w ramach ktrej centralny
minikomputer nakazywa poszczeglnym satelickim mikrokomputerom, eby te
przetestoway wszystkie linie telefoniczne znajdujce si pod ich kontrol. Kadego ranka
centralny komputer zbiera list uszkodzonych linii wraz ze szczegami na temat kadego
uszkodzenia. Menederowie serwisowi korzystali z tych raportw w celu przygotowania
planu prac dla serwisantw, tak eby mogli oni usun usterki, zanim zauwa je klienci.
Pewnego dnia wysaem do kilku klientw now wersj oprogramowania. Wysaem
jest tutaj okreleniem jak najbardziej na miejscu. Zapisaem oprogramowanie na tamach
i wysaem je poczt do klientw. Klienci po otrzymaniu tam zaadowali je do systemw
i ponownie uruchomili komputery.
Nowa wersja usuwaa kilka drobnych defektw i dodawaa now funkcj, ktrej klienci
domagali si ju od pewnego czasu. Poinformowalimy, e funkcj t dostarczymy przed
okrelon dat, a terminu udao si dotrzyma tylko dlatego, e zdyem jeszcze wysa
tamy przesyk ekspresow, dostarczan nastpnego dnia.
Dwa dni pniej zadzwoni do mnie nasz meneder serwisu Tom. Powiedzia mi, e cz
klientw skary si z powodu nieukoczenia procedury nocnej i braku raportw
o uszkodzeniach. Robiem wszystko, co w mojej mocy, eby wysa oprogramowanie na
czas, ale przy okazji pominem testy procedury nocnej. Przeprowadziem wiele testw
pozostaych funkcji systemu, ale testowanie tej procedury cigno si godzinami, a ja
musiaem przygotowa wysyk. adna z wprowadzonych poprawek nie dotyczya procedury
nocnej, wic nie widziaem te takiej potrzeby.
Utrata raportu nocnego bya powanym problemem. Oznaczaa, e serwisanci mieli mniej
pracy, ale za to pniej byli przecieni. Oznaczaa, e klienci zauwaali usterk i skadali
reklamacj. Utrata danych z raportu nocnego bya wystarczajca, eby menederowie
serwisowi dzwonili do Toma z awantur.
Uruchomiem nasz system laboratoryjny, zaadowaem nowe oprogramowanie
i uruchomiem procedur. Dziaaa przez kilka godzin, po czym zostaa przerwana.
Caa procedura nocna si zaamaa. Gdybym uruchomi ten test jeszcze przed wysaniem
tam, to klienci nie traciliby danych, a menederowie serwisu nie przypiekaliby Toma
ywym ogniem.
37
R OZDZIA 1.
P ROFESJONALIZM
Zadzwoniem to Toma, mwic mu, e udao mi si odtworzy problem. Odpowiedzia,

e do tej pory wikszo klientw dzwonia ju do niego, by zgosi t sam usterk.
Zapyta te, kiedy uda mi si to naprawi. Powiedziaem, e nie wiem, ale cay czas nad
tym pracuj. Jako tymczasowe rozwizanie zaproponowaem, eby klienci wrcili do
poprzedniej wersji oprogramowania. By na mnie zy, bo oznaczao to podwjny kopot
dla klientw. Po pierwsze utracili dane, a po drugie nie mogli skorzysta z nowej funkcji,
na ktr tak czekali.
Znalezienie bdu byo naprawd trudne, a testowanie cigno si caymi godzinami.
Pierwsza poprawka nie zadziaaa, podobnie jak druga. Znalezienie przyczyny wymagao
przynajmniej kilku nieudanych prb, przez co cao trwaa par dni. W tym czasie Tom
dzwoni do mnie co kilka godzin, pytajc, czy ju poprawiem bd. Przy okazji przekazywa
mi pomyje, jakimi czstowali go dzwonicy menederowie serwisu, i przypomina, jakim
wstydem byo dla niego informowanie klientw o koniecznoci uycia starych tam.
W kocu udao mi si znale usterk, wysa nowe tamy i wszystko wrcio do normy.
Tom nie by moim szefem, dlatego po pewnym czasie uspokoi si i cay ten epizod
pucilimy w niepami. Z kolei mj szef przyszed do mnie i powiedzia: Zao si,
e wicej takiego numeru nie wykrcisz. Nie mogem si nie zgodzi.
Zastanawiajc si nad tym incydentem, doszedem do wniosku, e wysanie tam bez
przeprowadzenia penych testw byo nieodpowiedzialne. Jedynym powodem pominicia
procedury testowej bya ch wysania tam na czas. Chciaem w ten sposb zachowa
twarz. Nie zastanawiaem si nad konsekwencjami dla klientw i pracodawcy. Mylaem
wycznie o swojej reputacji. Powinienem by jednak ju wczeniej zadzwoni do Toma
i powiedzie mu, e testy nie s jeszcze zakoczone i nie jestem gotowy, eby wysa
oprogramowanie na czas. To byoby trudne, a Tom na pewno by si zdenerwowa.
Ale aden z klientw nie straciby swoich danych i aden meneder serwisu nie musiaby
do nas dzwoni.
Po pierwsze nie szkodzi

W jaki sposb bierzemy na siebie odpowiedzialno? Istnieje w tym zakresie kilka zasad.
Korzystanie z przysigi Hipokratesa moe wydawa si aroganckie, ale czy mamy jakie
lepsze rdo? Poza tym, czy nie jest sensowne, e pierwszym celem i podstawow
odpowiedzialnoci profesjonalisty powinno by wykorzystanie swoich umiejtnoci
do czynienia dobra?
Jakich szkd moe narobi programista? Z punktu widzenia czysto programowego moe
uszkodzi zarwno funkcje, jak i struktur oprogramowania. Sprbujemy teraz zastanowi
si, jak mona tego unikn.
38
P O PIERWSZE NIE SZKODZI
Nie szkodzi funkcji

Oczywicie chcemy, eby nasze oprogramowanie dziaao. Z pewnoci wikszo z nas
jest dzisiaj programistami, poniewa swego czasu udao si nam co uruchomi i chcemy
ponownie poczu si tak samo jak wtedy. Nie jestemy jednak jedynymi osobami, ktre
chc, eby oprogramowanie dziaao. Chc tego rwnie nasi klienci i pracodawcy. Co wicej,
pac nam za to, ebymy przygotowali oprogramowanie, ktre bdzie dziaao tak, jak oni
to sobie wyobraaj.
Funkcj naszego oprogramowania uszkadzamy, wprowadzajc do niego bdy. Oznacza to,
e chcc by profesjonalistami, nie moemy robi bdw.
Ju sysz, jak wiele gosw odzywa si w stylu: Momencik! Przecie to nie ma sensu.
Oprogramowanie jest zbyt zoone, eby udao si je wytworzy bez adnych bdw.
Zgadzam si cakowicie. Oprogramowanie jest zbyt skomplikowane, eby mona je byo
tworzy bez bdw. Niestety, nie zwalnia nas to z odpowiedzialnoci. Ludzkie ciao jest
zbyt zoone, eby mona byo zrozumie kady jego szczeg, a mimo to lekarze przysigaj,
e nie bd szkodzi. Skoro oni nie uciekaj przed odpowiedzialnoci, to czy my moemy
to robi?
Chcesz powiedzie, e mamy by doskonali? Czybym sysza protesty?
Nie, twierdz jedynie, e musimy by odpowiedzialni za swoje niedoskonaoci. Fakt,
e bdy na pewno pojawi si w Twoim kodzie, nie oznacza, e nie masz bra za nie
odpowiedzialnoci. Fakt, e zadanie tworzenia doskonaego oprogramowania jest
praktycznie nie do wykonania, nie oznacza, e nie jestemy odpowiedzialni za swoje
niedoskonaoci.
Cech wyrniajc zawodowca jest to, e bierze odpowiedzialno za bdy, mimo
i ich pojawienie si jest niemal cakowicie pewne. Oznacza to, e aspirujc do miana
profesjonalisty, przede wszystkim musisz nauczy si przeprasza. Przeprosiny s
niezbdne, ale niestety nie s wystarczajce. Nie moesz po prostu cay czas robi nowych
bdw. Dojrzewajc w swoim zawodzie, musisz stara si, eby liczba generowanych
bdw cay czas spadaa asymptotycznie w kierunku zera. Nigdy nie uda Ci si osign
zera, ale Twoim zadaniem jest zbliy si do niego tak bardzo, jak si da.

Oznacza to, e gdy przygotowujesz now wersj oprogramowania, spodziewasz si, e dzia
kontroli jakoci nie znajdzie w niej adnych problemw. Niezwykle nieprofesjonalne jest
przesyanie do kontroli kodu, o ktrym wiesz, e zawiera bdy. A o jakim kodzie wiesz,
e zawiera bdy? Chodzi o dowolny kod, co do ktrego nie masz cakowitej pewnoci.
39
R OZDZIA 1.
P ROFESJONALIZM
Znam ludzi, ktrzy wykorzystuj dzia kontroli jakoci jako wykrywacz bdw. Wysyaj
do niego kod, ktrego nie sprawdzili do dokadnie. Maj nadziej, e kontrola jakoci
znajdzie w kodzie bdy i przele informacj o nich do programistw. Co wicej, niektre
firmy nagradzaj pracownikw kontroli jakoci na podstawie liczby znalezionych bdw.
Im wicej bdw, tym wysza nagroda.
Pomimy ju nawet to, e jest to niezwykle drogie zachowanie, ktre szkodzi zarwno
firmie, jak i oprogramowaniu. Przymknijmy oko na to, e takie zachowanie niszczy plany
i podminowuje zaufanie firmy do zespou programistw. Spumy zason milczenia
na fakt, e takie dziaanie jest przykadem lenistwa i nieodpowiedzialnoci. Przekazywanie
do dziau kontroli jakoci kodu, co do ktrego nie mamy pewnoci, czy dziaa, jest
najzwyczajniej w wiecie nieprofesjonalne. W ten sposb naruszana jest zasada nie szkodzi.
Czy dzia kontroli jakoci znajdzie bdy? Zapewne tak, dlatego przygotuj ju przeprosiny,
a potem zastanw si, jak tym bdom udao si umkn Twojej uwadze, i zrb wszystko,
eby w przyszoci si to nie powtrzyo.
Za kadym razem, gdy kontrola jakoci albo co gorsza uytkownik znajd w oprogramowaniu
bd, powinnimy by zaskoczeni, zniesmaczeni i zdeterminowani, eby si to nigdy wicej
nie powtrzyo.
Musisz wiedzie, e to dziaa

Jak moesz mie pewno, e Twj kod dziaa? To cakiem proste. Przetestuj go. A potem
jeszcze raz. Przetestuj dogbnie i na wylot. Testuj go na wszelkie moliwe sposoby.
Moesz si zastanawia, czy taki ogrom testw nie bdzie zajmowa zbyt wiele czasu.
W kocu musisz zrealizowa plany i dotrzyma terminw. Jeeli cay swj czas powicisz
na testowanie, to nie zdoasz napisa waciwego kodu. Suszna uwaga! Oznacza to tylko,
e musisz zautomatyzowa swoje testy. Napisz testy jednostkowe, ktre bdzie mona
uruchomi w sekund, i uruchamiaj je tak czsto, jak to bdzie moliwe.
Jaka cz kodu powinna by testowana za pomoc tych zautomatyzowanych testw
jednostkowych? Czy naprawd musz odpowiada na to pytanie? Oczywicie, e cao!
Czy sugeruj tu stuprocentowe pokrycie kodu? Nie, wcale tego nie sugeruj. Ja si tego
domagam. Kady wiersz kodu, ktry wyszed spod Twoich palcw, powinien zosta
przetestowany. Kropka.
Czy to nie jest aby nierealistyczne? Oczywicie, e nie. Piszesz kod tylko dlatego, e oczekujesz
jego wykonania. A skoro oczekujesz, e zostanie wykonany, to musisz mie pewno, e dziaa
waciwie. Jedyn metod, eby to osign, jest jego przetestowanie.
Jestem gwnym programist i wsptwrc otwartordowego projektu o nazwie FitNesse.
Aktualnie projekt ten skada si z ponad 60 000 wierszy kodu. Spord tych 60 a 26 skada
40
P O PIERWSZE NIE SZKODZI
si na ponad 2000 testw jednostkowych. Wedug raportw Emma pokrycie generowane

przez te testy wynosi okoo 90%.
Dlaczego nie uzyskaem wikszego pokrycia kodu? Wynika to z tego, e Emma nie widzi
wszystkich wierszy wykonywanego kodu. Sdz zatem, e rzeczywiste pokrycie jest o wiele
wiksze. Czy wynosi 100%? Nie, warto 100% jest tutaj asymptot.
Ale czy cz kodu nie jest trudna do przetestowania? Owszem, ale tylko wtedy, gdy zosta
on zaprojektowany tak, eby trudno byo go testowa. Rozwizaniem jest zawsze
przygotowanie takiego projektu, ktry bdzie uatwia testowanie kodu. A najlepszym
sposobem na uzyskanie takiego projektu jest pisanie testw najpierw, jeszcze przed
powstaniem kodu, ktry ma je przechodzi.
Taki sposb postpowania zyska nazw TDD (Test Driven Development programowanie
sterowane testami), o czym opowiem wicej w jednym z pniejszych rozdziaw.
Zautomatyzowana kontrola jakoci

Cay proces kontroli jakoci dla projektu FitNesse polega na uruchomieniu testw
jednostkowych i akceptacyjnych. Jeeli te testy zostan zaliczone, to mog dostarczy
kolejn wersj. Oznacza to, e moja procedura kontroli jakoci zajmuje mi jakie trzy
minuty i mog j uruchomi w dowolnym momencie.
Oczywicie w razie wystpienia jakiego bdu w FitNesse raczej nikt nie umrze ani nikt
nie straci milionw dolarw. Projekt ma jednak baz wielu tysicy uytkownikw
i jednoczenie bardzo krtk list bdw.
Z ca pewnoci istniej systemy tak wane, e krtki zautomatyzowany test nie jest
wystarczajcy, aby sprawdzi jego gotowo do pracy. Ponadto kady programista potrzebuje
wzgldnie szybkiego i skutecznego mechanizmu informujcego go o tym, czy napisany kod
nie wpywa negatywnie na pozostae czci systemu. Oznacza to, e zautomatyzowane testy
mog powiedzie nam, czy system ma szanse przej kontrol jakoci.
Nie szkodzi strukturze

Prawdziwy zawodowiec wie, e realizowanie funkcji kosztem struktury to postpowanie
gupca. To wanie struktura kodu pozwala mu zachowa elastyczno. Jeeli naruszysz
t struktur, zaszkodzisz przyszoci projektu.
Podstawowym zaoeniem kadego projektu oprogramowania jest umoliwianie atwej
zmiany programu. Jeeli naruszymy to zaoenie, tworzc nieelastyczne struktury, to
zaczniemy podcina model ekonomiczny, na ktrym bazuje caa nasza ga przemysu.
41
R OZDZIA 1.
P ROFESJONALIZM
W skrcie: Musisz zachowa moliwo wprowadzania zmian bez generowania

gigantycznych kosztw.
Niestety, zbyt wiele projektw potrafi utkn w botnistym dole le zaprojektowanych
struktur. Zadania, ktre wczeniej trway kilka dni, zaczynaj zajmowa tygodnie, a potem
nawet miesice. Kadra zarzdzajca w desperackiej prbie odzyskania poprzedniej
prdkoci prac zatrudnia wicej programistw. Ale ci nowi programici pogbiaj tylko
istniejce bagno, zwikszajc liczb nieprawidowoci w strukturach oprogramowania
i spitrzajc przeszkody.
Wiele napisano ju na temat zasad i wzorcw projektowych oprogramowania, ktre
pozwalaj na tworzenie elastycznych i atwych w utrzymaniu struktur2. Profesjonalni
twrcy oprogramowania zawsze pamitaj o tych rzeczach i staraj si tworzy zgodne
z nimi oprogramowanie. Istnieje jednak pewna sztuczka, o ktrej wie znacznie mniej
programistw: Jeeli chcesz, eby oprogramowanie byo elastyczne, to musisz je pozgina!
Jedyn metod udowodnienia, e oprogramowanie jest elastyczne, jest wprowadzenie
w nim zmian. Jeeli stwierdzisz, e ich wprowadzenie nie jest tak proste, jak si pocztkowo
wydawao, to znaczy, e konieczna jest zmiana projektu, tak aby zmiany byy atwiejsze.
Kiedy wprowadza si takie proste zmiany? Cay czas! Za kadym razem, gdy patrzysz
na modu, poprawiasz w nim szczegy usprawniajce ca struktur. Za kadym razem,
gdy czytasz kod, dopasowujesz jego struktur.
Ta filozofia czasami nazywana jest bezlitosn refaktoryzacj. Ja nazywam j regu skauta:
dany modu zawsze pozostaw czystszy, ni go zastae. Przegldajc kod, zawsze wywiadcz
mu jak przysug.
To zupenie inny sposb mylenia o oprogramowaniu, by moe obcy wikszoci ludzi.
Zwykle uwaa si, e wprowadzanie cigych zmian do dziaajcego ju oprogramowania
jest niebezpieczne. Tak wcale nie jest! Niebezpieczne jest pozwalanie na ustatkowanie si
kodu. Jeeli nie jest on cay czas zginany, to gdy zajdzie potrzeba wprowadzenia zmian,
okae si, e bdzie on na nie niepodatny.
Dlaczego wikszo programistw obawia si wprowadzania zmian do swojego kodu?
Po prostu boj si, e mog co zepsu! A dlaczego boj si takiej ewentualnoci?
Poniewa nie korzystaj z testw.
Wszystko sprowadza si do testw. Jeeli masz zautomatyzowany zestaw testw
pokrywajcych prawie 100% kodu i zestaw ten moe zosta szybko uruchomiony
w dowolnym momencie, to po prostu nie boisz si wprowadzania zmian do kodu.
Jak moesz udowodni, e nie boisz si wprowadzania zmian do kodu? Cay czas
go zmieniajc.
2
[PPP2002].
42
E TYKA PRACY
Profesjonalni programici s tak pewni swojego kodu i testw, e bez adnych oporw
prowadzaj do kodu rne oportunistyczne zmiany. Ot tak zmieniaj nazw klasy. Jeeli
podczas czytania kodu moduu zauwa przydug metod, to przy okazji podziel j na
mniejsze kawaki. Zamieni instrukcj wyboru w rozwizanie polimorficzne albo zwin
hierarchi dziedziczenia w struktur typu acuch dowodzenia. W skrcie: traktuj
oprogramowanie tak jak rzebiarz traktuje glin cay czas je przeksztacaj i formuj.
Etyka pracy
Twoja kariera to Twoja odpowiedzialno. Zapewnienie Twojej atrakcyjnoci na rynku
pracy nie jest zadaniem Twojego pracodawcy. Jego zadaniem nie jest te szkolenie Ci,
wysyanie na konferencje ani kupowanie Ci ksiek. To wszystko to Twoja odpowiedzialno.
Biada programicie, ktry zawierzy swoj karier pracodawcy.
Niektrzy pracodawcy chtnie kupuj ksiki dla pracownikw, wysyaj ich na kursy
i konferencje. To bardzo mio, e robi Ci takie przysugi. Nigdy jednak nie wpadaj
w puapk mylenia, e jest to zadanie pracodawcy. Jeeli pracodawca tego nie robi,
to musisz szuka sposobu, eby robi to samodzielnie.
Podobnie nie jest zadaniem pracodawcy organizowanie Ci czasu niezbdnego na nauk.
Niektrzy pracodawcy taki czas wygospodarowuj, a cz pracownikw moe si nawet
tego domaga. I tu ponownie trzeba zaznaczy, e takie dziaanie moe by tylko miym
gestem pracodawcy, ktry musimy odpowiednio doceni. Nie mona jednak od pracodawcy
oczekiwa takich prezentw.
Swojemu pracodawcy winni jestemy okrelony czas oraz nakad pracy. Na potrzeby
tej dyskusji przyjmijmy standardowe w USA 40 godzin na tydzie. Tych 40 godzin
powinnimy spdzi, rozwizujc problemy pracodawcy, a nie swoje.
Naley jednak planowa prac w zakresie 60 godzin w tygodniu, pierwszych 40 powicajc
swojemu pracodawcy, a pozostae 20 zachowujc dla siebie. Podczas tych dodatkowych
20 godzin moesz czyta, wiczy, uczy si lub w inny sposb rozwija swoj karier.
Zapewne zaczynasz teraz myle: A co z moj rodzin? Co z moim yciem prywatnym?
Czy mam je powici na rzecz pracodawcy?.
Nie mwi jednak o caym Twoim czasie wolnym, a jedynie o dodatkowych 20 godzinach
tygodniowo. To zaledwie trzy godziny dziennie. Jeeli wykorzystasz przerw obiadow na
czytanie, w drodze do i z pracy posuchasz podcastw, a 90 minut powicisz kadego dnia
na nauk nowego jzyka, to nic wicej nie trzeba.
To prosta matematyka. W tygodniu mamy 168 godzin. Pracodawcy powicasz 40, a na
rozwj kariery kolejnych 20. Pozostaje 108 godzin. Sen zajmuje 56, a zatem zostaj nam
52 godziny na inne aktywnoci.
43
R OZDZIA 1.
P ROFESJONALIZM
By moe nie chcesz takiego powicenia. Nie ma sprawy, ale wtedy nie myl o sobie jako
o profesjonalicie. Zawodowcy powicaj czas, eby zadba o swoj profesj.
Mylisz zapewne, e praca powinna pozosta w pracy i nie naley przynosi jej do domu.
Cakowicie si zgadzam! Podczas tych dodatkowych 20 godzin nie naley pracowa dla
swojego pracodawcy. Ten czas powi na prac nad wasn karier.
Czasami te dwa cele s ze sob zgodne. Czasami praca dla pracodawcy jest bardzo korzystna
dla Twojej kariery. W takiej sytuacji cakiem rozsdne bdzie powicenie czci z tych
20 godzin pracodawcy. Pamitaj jednak, e te 20 godzin ma suy przede wszystkim Tobie.
Dziki nim masz podnie swoj warto jako zawodowca.
Moesz teraz pomyle, e jest to prosta recepta na wypalenie zawodowe. Wrcz przeciwnie!
To recepta na uniknicie wypalenia. Zakadam, e wybr zawodu programisty wynika
z Twojej pasji zwizanej z tworzeniem oprogramowania i dysz do tego, by zosta
profesjonalist napdzanym pasj. Podczas tych 20 godzin naley robi wszystko, eby
t pasj podsyca. Tych 20 godzin ma sprawia Ci przyjemno!
Znaj swoje otoczenie

Wiesz, czym jest wykres Nassiego-Schneidermana? Jeeli nie wiesz, to dlaczego? Znasz
rnic midzy maszynami stanu Mealyego i Moora? Kady powinien j zna. Jeste
w stanie napisa procedur quicksort bez szukania informacji? Wiesz, co oznacza pojcie
analiza transformacji? Jeste w stanie wykona funkcjonaln dekompozycj za pomoc
diagramu przepywu danych? Co oznacza pojcie wdrowne dane (ang. tramp data)?
Obio Ci si o uszy pojcie conascence? A co z tablicami Parnasa?
Przez ostatnie 50 lat istnienia naszej dziedziny nauki powstao wiele ciekawych idei, technik,
narzdzi i terminologii. Ile z nich udao Ci si pozna? Jeeli chcesz by profesjonalist,
to musisz zna ich cakiem sporo i cay czas powiksza swoj wiedz.
Dlaczego musimy to wszystko zna? Czy nasza dziedzina nie posuwa si naprzd w takim
tempie, e te stare idee trac na istotnoci? Pierwsza cz tego pytania tylko z pozoru jest
oczywista. Faktycznie nasza dziedzina rozwija si w szalonym tempie, ale co ciekawe,
rozwj ten pod wieloma wzgldami jest jedynie powierzchowny. To prawda, e nie czekamy
ju 24 godziny na kompilacj kodu. To prawda, e piszemy systemy, ktrych rozmiary
dochodz do gigabajtw. To prawda, e pracujemy w sieci rozcigajcej si na cay wiat,
ktra pozwala nam na natychmiastowy dostp do informacji. Mimo to nadal piszemy te
same instrukcje if i while, z ktrych korzystalimy ju 50 lat temu. Wiele si zmienio,
ale wiele pozostao bez zmian.
Druga cz pytania nie jest ju tak oczywista. Zaledwie niewielka cz idei powstaych
w cigu tych 50 lat stracia na wanoci. To prawda, e niektre z nich zostay zepchnite
na boczny tor. Metoda tworzenia oprogramowania w systemie wodospadu nie ma ju tak
44
E TYKA PRACY
dobrej prasy. Ale nie oznacza to, e nie powinnimy wiedzie, na czym ona polega i jakie
s jej dobre i ze strony.
Mimo wszystko wikszo idei wypracowanych w cigu tych 50 lat dzi nadal jest tak samo
wartociowa. Cz z nich nawet zyskaa na wartoci.
Pamitaj o przeklestwie Santayany: Kto nie pamita o przeszoci, skazany jest na to,
eby j powtarza.
Oto minimalna lista rzeczy, ktre powinien wiedzie kady zawodowy twrca
oprogramowania:
Wzorce projektowe. Musisz by w stanie opisa wszystkie 24 wzorce opisane w ksice
GOF i mie dowiadczenie w pracy z wieloma wzorcami opisywanymi w ksikach POSA.

Zasady projektowania. Musisz zna zasady SOLID i dobrze pozna poszczeglne terminy.
Metody. Musisz zna metodologie XP, Scrum, Lean, Kanban, wodospadu, analizy
strukturalnej i projektowania strukturalnego.

Dziedziny. Musisz korzysta z technik TDD, projektowania obiektowego, programowania
strukturalnego, cigej integracji i programowania w parach.

Artefakty. Musisz wiedzie, jak korzysta z UML, DFD, wykresw struktur, sieci Petriego,
diagramw i tabel przej stanw, diagramw przepywu oraz tabel decyzji.
Ciga nauka
To niezwyke tempo zmian w naszej gazi przemysu sprawia, e twrcy oprogramowania
musz cigle przyswaja ogromne iloci wiedzy, tylko po to, eby nady za tym rozwojem.
Biada architektowi, ktry zaprzestanie tworzenia kodu. Bardzo szybko okae si, e nie
przystaje do rzeczywistoci. Biada programistom, ktrzy przestali uczy si nowych jzykw.
Bd mogli tylko popatrze, jak oddala si od nich czowka. Biada projektantom, ktrzy
przestan uczy si nowych technik i rozwiza. Koledzy szybko ich przecign.
Chcesz korzysta z usug doktora, ktry przesta czyta o najnowszych postpach
w medycynie? Zatrudnisz doradc podatkowego, ktry nie ledzi najnowszych zmian
w prawie? Dlaczego zatem mielibymy zatrudnia programistw, ktrzy nie ledz nowoci?
Czytaj ksiki, artykuy, blogi i tweety. Jed na konferencje. Wstpuj do grup
uytkownikw. We udzia w spotkaniach grup naukowych i czytelniczych. Ucz si rzeczy,
ktre nie s dla Ciebie najatwiejsze. Jeeli jeste programist .NET, to naucz si Javy.
Jeeli normalnie programujesz w Javie, to poznaj jzyk Ruby. Jeeli programujesz w C,
naucz si Lispu. A jeeli naprawd chcesz zmusi mzg do pracy, to zacznij poznawa
Prolog lub Forth.
45
R OZDZIA 1.
P ROFESJONALIZM
wiczenia
Zawodowcy nieustannie wicz. Prawdziwi zawodowcy ciko pracuj nad cigym
rozwojem swoich umiejtnoci. Nie wystarczy tylko wykonywa swojej codziennej pracy
i nazywa to wiczeniem. W czasie pracy chodzi o wydajno, a nie wiczenia. O wiczeniu
mona mwi wtedy, gdy wykorzystujesz swoje umiejtnoci poza normaln prac tylko
po to, eby te je utrwali i rozwin.
Co zatem dla programisty oznacza wiczenie? Na pierwszy rzut oka ta koncepcja jest
troch absurdalna. Ale wystarczy przez chwil pomyle. Zastanw si, jak muzycy
doskonal swoje rzemioso. Wcale nie wystpujc, tylko wiczc. A jak to robi? Midzy
innymi maj specjalne wiczenia, ktre regularnie wykonuj. Skale, etiudy i sekwencje.
Powtarzaj je w nieskoczono, wiczc swoje palce i umysy, prbujc osign
doskonao w tym, co robi.
Co zatem mog robi programici w ramach wicze? W tej ksice cay rozdzia
powiciem rnym rodzajom wicze, dlatego nie bd si tutaj rozpisywa. Jedn
z technik, z ktrych sam czsto korzystam, jest powtarzanie prostych wicze, takich
jak Gra w krgle (ang. Bowling game) lub Czynnik pierwszy (ang. Prime factor). Takie
wiczenia nazywam kata. Istnieje spory zbir takich kata do wyboru.
Kata najczciej zdefiniowane jest jako prosty problem programistyczny, ktry naley
rozwiza, taki jak napisanie funkcji obliczajcej czynniki pierwsze danej liczby cakowitej.
Celem wykonywania kata nie jest wymylenie sposobu rozwizania problemu, poniewa
kady zna ju jego rozwizanie. Celem jest tutaj wywiczenie swoich palcw i umysu.
Kadego dnia robi jedno lub dwa kata, czsto w ramach przygotowa do waciwej pracy.
Mog wykona je w Javie, w Ruby albo w Clojure lub dowolnym innym jzyku, ktrego
zasady w danym momencie chc sobie przypomnie. Wykorzystuj kata do poprawienia
okrelonej umiejtnoci, takiej jak przypomnienie palcom rnych skrtw klawiszowych,
albo wykonania okrelonych rodzajw refaktoryzacji.
O kata moesz myle jak o dziesiciominutowych rozgrzewkach o poranku
i dziesiciominutowym rozciganiu po poudniu.
Wsppraca
Kolejn dobr metod nauki jest wsppraca z innymi ludmi. Zawodowi programici
szczeglnie staraj si wsplnie programowa, wiczy, projektowa i planowa. W ten
sposb wiele si nawzajem od siebie ucz, a poza tym wykonuj zadania w znacznie
krtszym czasie i z mniejsz liczb bdw.
Nie oznacza to, e musisz 100% swojego czasu spdza, pracujc wsplnie z innymi. Rwnie
wany jest czas wykorzystywany samodzielnie. Jak bardzo bym lubi programowanie
46
E TYKA PRACY
w parze z innym koleg, to brak moliwoci samodzielnego popracowania od czasu

do czasu sprawia, e le si czuj.
Nauczanie
Najlepsz metod uczenia siebie jest nauczanie innych. Nic tak szybko nie wprowadzi
do gowy nowych faktw i wartoci jak przekazywanie ich ludziom, za ktrych jestemy
odpowiedzialni. Oznacza to, e zalety nauczania zdecydowanie le po stronie
nauczajcego.
Wedug tego samego schematu mona powiedzie, e nie ma lepszego sposobu na
wprowadzenie nowej osoby do organizacji, ni usi razem z ni i pokaza jej wszystkie
szczegy. Zawodowcy przejmuj osobist odpowiedzialno za nauczanie modych.
Nie pozwalaj modzikom na nienadzorowane zabawy.
Znaj swj fach

Zadaniem kadego zawodowego twrcy oprogramowania jest dokadne poznanie dziedziny
i rozwiza, ktre ma zaprogramowa. Jeeli tworzysz system ksigowy, to naleaoby zna
si na ksigowoci. Jeeli piszesz aplikacj do zamawiania wycieczek, to dobrze byoby
zna si troch na sprzeday wycieczek. Nie musisz by ekspertem w tych dziedzinach,
ale odpowiedni poziom wiedzy na ich temat na pewno jest wskazany.
Uruchamiajc projekt w nowej dziedzinie, przeczytaj przynajmniej jedn powicon jej
ksik. Porozmawiaj z klientem i uytkownikami o podstawach danej dziedziny. Troch
czasu spd z ekspertami, prbujc pozna ich zasady i wartoci.
Przystpienie do tworzenia kodu, gdy opieramy si jedynie na specyfikacji, bez prby
zrozumienia, dlaczego ta specyfikacja pasuje do danego rodzaju dziaalnoci, jest
najgorszym przykadem nieprofesjonalnego dziaania. Musisz dowiedzie si na tyle
duo o tej dziaalnoci, eby mc rozpoznawa i wskazywa bdy w specyfikacji.
Identyfikuj si ze swoim pracodawc lub klientem

Problemy Twojego pracodawcy s Twoimi problemami. Musisz pozna te problemy i stara
si wspomaga ich rozwizywanie. Rozwijajc dany system, musisz spojrze na niego oczami
pracodawcy i upewni si, e rozwijane przez Ciebie funkcje na pewno bd zaspokajay
potrzeby pracodawcy.
Programistom bardzo atwo jest identyfikowa si ze sob nawzajem. Czsto przyjmuj
zatem wzgldem pracodawcy postaw my kontra oni. Profesjonalici staraj si tego za
wszelk cen unika.
47
R OZDZIA 1.
P ROFESJONALIZM
Pokora
Programowanie jest aktem tworzenia. Piszc kod, tworzymy co z niczego. Odwanie
wymuszamy porzdek w chaosie. Pewnie i szczegowo nakazujemy maszynie okrelone
zachowania, ktre zdefiniowane inaczej, mogyby spowodowa nieobliczalne straty.
Oznacza to, e programowanie jest aktem gigantycznej arogancji.
Profesjonalici wiedz, e s aroganccy, i dlatego nie obnosz si z faszyw skromnoci.
Zawodowiec zna swoj prac i czuje dum, widzc swoje dziea. Profesjonalista jest pewien
swoich umiejtnoci i na tej podstawie podejmuje odwane, cho kalkulowane ryzyko.
Zawodowiec nie bdzie niemiay.
Mimo tego profesjonalista wie, e przyjdzie taki czas, kiedy si pomyli, jego ocena ryzyka
okae si bdna, a umiejtnoci niewystarczajce. Spojrzy wtedy w lustro i zobaczy
miejcego si do niego aroganckiego gupca.
Oznacza to, e gdy zawodowiec stanie si obiektem kpin, sam bdzie si z nich mia.
Nigdy nie bdzie wykpiwa innych, ale przyjmie kpiny, na ktre zasuy, a wymieje te
niezasuone. Nie bdzie ponia nikogo za popenione bdy, poniewa wie, e sam moe
wkrtce si pomyli.
Profesjonalista zna rozmiary swojej arogancji i wie, e los w kocu te j zauway
i odpowiednio potraktuje. A gdy si to stanie, najlepsze, co bdzie mona zrobi,
to skorzysta z rady Howarda: mia si.
Bibliografia
[PPP2002]: Robert C. Martin, Agile Software Development. Principles, Patterns,
and Practices, Upper Saddle River, NJ: Prentice Hall, 2002.
48
K IEDY MWI NIE
Zrb albo nie rb. Nie ma prbowania.

Yoda
Na pocztku lat 70. razem z dwoma moimi dziewitnastoletnimi przyjacimi pracowalimy
w firmie Teamsters z Chicago nad systemem ksigowym dziaajcym w czasie rzeczywistym,
przeznaczonym dla firmy o nazwie ASC. Jeeli komu przypomina si w zwizku z nim
nazwisko Jimmyego Hoffy, to dobrze. W roku 1971 lepiej byo nie zadziera z Teamsters.
Nasz system mia zosta uruchomiony okrelonego dnia. Z t dat zwizana bya caa
gra pienidzy. Nasz zesp pracowa 60, 70, a nawet 80 godzin tygodniowo, byle tylko
dotrzyma terminu.
49
R OZDZIA 2.
K IEDY MWI NIE
Na tydzie przed terminem w kocu udao si nam zoy system w cao. Musielimy si
jednak upora z dug list bdw i problemw, nad ktr nadal wytrwale pracowalimy.
Nie mielimy czasu na jedzenie, spanie, nie mwic ju o myleniu.
Frank, meneder z ASC, by emerytowanym pukownikiem Air Force. By jednym z tych
gonych i bardzo bezporednich kierownikw. Nie znosi sprzeciwu i kady jego przejaw
dusi brutalnie ju w samym zarodku. Nasza trjka dziewitnastolatkw nie bya w stanie
nawet nawiza z nim kontaktu wzrokowego.
Frank powiedzia, e system ma by gotowy do wyznaczonego dnia. Nie byo adnej dyskusji.
Wielki dzie nadejdzie i system bdzie gotowy. Kropka. adnych dyskusji. Bez odbioru.
Mj szef Bill by cakiem miym czowiekiem. Z Frankiem pracowa ju od adnych kilku
lat i wiedzia, na co mona sobie z nim pozwoli, a co byo wykluczone. Powiedzia nam,
e system zostanie uruchomiony wyznaczonego dnia, niezalenie od okolicznoci.
A zatem system zosta uruchomiony. To bya prawdziwa katastrofa.
Mielimy tuzin pdupleksowych terminali o szybkoci 300 bodw, ktre czyy siedzib
firmy Teamsters w Chicago z naszym komputerem znajdujcym si 50 kilometrw na pnoc
od miasta. Kady z tych terminali blokowa si mniej wicej co 30 minut. Wiedzielimy ju
wczeniej o tym problemie, ale nigdy nie symulowalimy ruchu, ktry zaczli generowa
pracownicy klienta.
eby byo jeszcze gorzej, podczas drukowania arkuszy za pomoc teletekstw ASR-35,
podczonych do systemu liniami telefonicznymi o szybkoci 110 bodw, zdarzay si
blokady w samym rodku arkusza.
Rozwizaniem przy kadej takiej blokadzie byo ponowne uruchomienie systemu. Oznaczao
to, e kada osoba, ktrej terminal jeszcze dziaa, musiaa dokoczy prac i si zatrzyma.
Gdy ju nikt nie pracowa, mogli do nas zadzwoni z prob o ponowne uruchomienie.
Osoba, ktrej zdarzya si blokada, musiaa zaczyna swoj prac od pocztku. A zdarzao
si to kilka razy na godzin.
Po kilku godzinach takiej zabawy meneder biura Teamsters nakaza nam zamkn system
i nie uruchamia go ponownie, dopki nie bdzie dziaa poprawnie. Ju stracili p dnia
pracy i byli zmuszeni ponownie wprowadza te same dane do starego systemu.
W caym budynku sycha byo krzyki i przeklestwa rzucane przez Franka. Trwao to
ca wieczno. Pniej przyszed do nas Bill w towarzystwie analityka systemowego Jalila
z pytaniem, na kiedy moemy doprowadzi system do stanu stabilnego. Powiedziaem,
e za cztery tygodnie.
Na ich twarzach pojawiy si przeraenie i determinacja. To niemoliwe powiedzieli
musi dziaa ju w pitek.
50
P RZECIWSTAWNE ROLE
Odpowiedziaem: Przecie w zeszym tygodniu dopiero co udao si nam jako tako poskada
system. Musimy pozby si wszystkich problemw i bdw, a na to potrzebujemy czterech
tygodni.
Niestety, Bill i Jalil byli niewzruszeni. Nie, musi dziaa ju w pitek. Moecie przynajmniej
sprbowa?
I wtedy szef naszego zespou powiedzia: No dobra, sprbujemy.
Pitek by cakiem niezym wyborem, poniewa weekendowe obcienie systemu byo
o wiele mniejsze. Przed poniedziakiem moglimy znale i usun jeszcze wicej bdw.
Mimo wszystko cay ten domek z kart zawali si raz jeszcze. Problemy z zawieszaniem si
terminali pojawiay si jeszcze raz lub dwa razy kadego dnia. Oprcz tego system trapiy
te inne problemy. Jednak powoli, w cigu kilku tygodni doprowadzilimy go do stanu,
w ktrym skargi nie byy ju a tak czste, a normalno wydawaa si cakiem osigalna.
Wtedy, tak jak wspomniaem ju we wstpie, wszyscy zoylimy wypowiedzenie. Firma
miaa teraz naprawd powany problem. Musiaa zatrudni nowych programistw, ktrzy
mieli prbowa zaj si ogromnym strumieniem problemw zgaszanych przez klienta.
Kogo mona byo wini za t sytuacj? Z pewnoci sposb bycia Franka stanowi jaki
problem. Jego cige oniemielanie rozmwcy sprawiao, e ciko byo mu usysze
prawd. Z pewnoci Bill i Jalil powinni byli bardziej naciska Franka. Z pewnoci szef
zespou programistw nie powinien by zgadza si na pitkowy termin. Ostatecznie
ja sam powinienem by powiedzie nie, zamiast ustawia si za szefem zespou.
Profesjonalici mwi prawd niezalenie od sytuacji. Profesjonalici maj odwag
powiedzie nie swoim przeoonym.
Ale jak powiedzie nie swojemu szefowi? W kocu to Twj szef! Czy nie naleaoby
robi tego, co szef nakazuje?
Nie. Nie, jeeli uwaasz si za profesjonalist.
Niewolnik nie ma prawa powiedzie nie. Robotnicy mog mie opory przed mwieniem
nie. Ale od profesjonalistw oczekuje si, e bd mwi nie. Co wicej, dobrzy
menederowie szukaj ludzi, ktrzy maj charakter, eby si sprzeciwia. Tylko w ten
sposb mona naprawd wiele osign.
Przeciwstawne role
Jeden z recenzentw naprawd nienawidzi tego rozdziau. Powiedzia, e z jego powodu
prawie odoy ksik na pk. Tworzy ju zespoy, w ktrych nie byo wrogich stosunkw.
Takie zespoy pracoway w harmonii, bez adnych konfrontacji.
51
R OZDZIA 2.
K IEDY MWI NIE
Ciesz si z sytuacji tego recenzenta, ale zastanawiam si, czy jego zespoy naprawd byy
tak harmonijne, jak twierdzi. Jeeli takie byy, to zastanawiam si, czy byy tak wydajne,
jak mogyby by. Z mojego dowiadczenia wynika, e najtrudniejsze decyzje najlepiej
podejmuje si w trakcie konfrontacji przeciwstawnych rl.
Menederowie s ludmi, ktrym powierzono okrelone zadanie, i wikszo z nich
doskonale wie, jak to zadanie wykona. Cz ich pracy polega na jak najagresywniejszej
obronie wyznaczonych im celw.
Podobnie programici te s ludmi, ktrzy rwnie maj do wykonania pewne zadanie
i wikszo z nich wie, jak si z niego dobrze wywiza. Jeeli s oni profesjonalistami,
to bd starali si broni swoich celw tak agresywnie, jak tylko bd mogli.
Gdy Twj kierownik mwi Ci, e strona logowania ma by gotowa na jutro, to stara si
osiga swoje wasne cele. Wykonuje po prostu swoj prac. Jeeli doskonale wiesz, e
przygotowanie strony logowania na jutro jest po prostu niemoliwe, to mwic: OK,
sprbuj, zdecydowanie nie wykonujesz swojej pracy. T prac wykonasz waciwie,
tylko twierdzc, e to jest niemoliwe.
Czy jednak nie masz obowizku wykonywania polece przeoonego? Wcale nie. Twj
meneder liczy wanie na to, e bdziesz broni swoich celw tak agresywnie, jak on
broni swoich. Tylko w ten sposb bdziecie w stanie wypracowa rozwizanie najlepsze
z moliwych.
Takim rozwizaniem jest cel, pod ktrym Ty i Twj kierownik moecie si podpisa.
Caa sztuka polega na odnalezieniu takiego celu, a to zwykle wymaga negocjowania.
Czasami takie negocjacje mog by cakiem przyjemne.
Mike: Paula, ta strona logowania musi by gotowa na jutro.
Paula: O rany! Tak szybko? Ale OK, sprbuj.
Mike: wietnie, wielkie dziki!.
To bya cakiem mia rozmowa. Cakowity brak konfrontacji, a obie strony rozstay si
z umiechem. Wspaniale.
Jednak obie strony zachoway si bardzo nieprofesjonalnie. Paula wie doskonale, e
przygotowanie strony logowania zajmie jej troch wicej ni jeden dzie, a zatem kamie.
By moe nawet nie myli o tym w kategorii kamstwa i naprawd ma zamiar sprbowa,
bo ma cho cie nadziei, e uda jej si dotrzyma terminu. Jak by na to nie patrze, to nadal
jest kamstwo.
Jednake Mike uzna sowo sprbuj za tak. To wyjtkowo gupie zaoenie. Powinien
by wiedzie, e Paula prbuje tylko unikn konfrontacji, dlatego mia pocign t spraw
52
P RZECIWSTAWNE ROLE
dalej, mwic: Dobrze, widz, e si wahasz. Na pewno uda ci si przygotowa stron

do jutra?.
A oto inna mia rozmowa.
Paula: Przykro mi, Mike, ale to zajmie troch wicej czasu.
Mike: W takim razie na kiedy bdzie gotowa?.
Paula: Co powiesz na jakie dwa tygodnie?.
Mike: (wpisuje co do notatnika) OK, dziki.
Cho bya cakiem mia, to jednoczenie bya straszliwie niewaciwa i potwornie
nieprofesjonalna. Obie strony nawet nie staray si znale lepszego rozwizania.
Zamiast pyta, czy dwa tygodnie bd w porzdku, Paula powinna bya odpowiedzie
bardziej asertywnie: Oj, to zajmie jakie dwa tygodnie.
Z kolei Mike po prostu przyj do wiadomoci termin wyznaczony przez Paul, tak jakby
jego wasne cele nie miay znaczenia. Mona si zastanawia, czy czasem nie poinformuje
swojego szefa, e demo dla klienta zostanie opnione z powodu Pauli. Tego rodzaju
pasywno-agresywne zachowanie jest cakowicie niemoralne.
W obu przedstawionych przypadkach adna ze stron nie prbowaa zdefiniowa wsplnego
celu. Nikt nie prbowa poszuka najlepszego rozwizania. Przyjrzyjmy si zatem tej
rozmowie.
Paula: Przykro mi, Mike, ale to robota na dwa tygodnie.
Mike: Dwa tygodnie? Architekci szacowali to na trzy dni, a mino ju pi!.
Paula: To znaczy, e architekci si pomylili. Swoje szacunki przygotowali, jeszcze
zanim marketing zakoczy definiowanie wymaga systemowych. Roboty jest
tyle, e zajmie mi to jeszcze przynajmniej dziesi dni. Nie widziae moich
szacunkw w wiki?.
Mike: (spoglda surowo i a trzsie si ze zoci) Paula! Nie mog tego zaakceptowa.
Klienci chc jutro zobaczy demo i musz im pokaza dziaajc stron
logowania.
Paula: Ktra cz strony musi do jutra dziaa?.
Mike: Potrzebuj strony logowania. Musz si jako zalogowa do systemu.
Paula: OK, mog da ci szablon strony logowania, ktry pozwoli ci si zalogowa.
Ta cz ju dziaa. Pamitaj tylko, e nie sprawdza nazwy uytkownika ani
hasa i nie przele na maila zapomnianego hasa. Nie pojawi si wielki firmowy
banner w stylu Time Square, a przycisk pomocy nie bdzie szczeglnie pomocny.
53
R OZDZIA 2.
K IEDY MWI NIE
Nie zapisz si ciasteczka zapamitujce uytkownika na przyszo, a przede

wszystkim ten szablon w aden sposb nie ograniczy ci dostpu do systemu.
No, ale bdziesz mg si zalogowa. Wystarczy?.
Mike: Na pewno bd mg si zalogowa?.
Paula: Owszem, bdziesz mg.
Mike: Paula, to wietnie! Ratujesz mi ycie (odchodzi, podskakujc i krzyczc yes!)!
Udao im si znale najlepsze rozwizanie. Zrobili to, mwic najpierw nie, a potem
starajc si zdefiniowa rozwizanie zadowalajce dla obu stron. Zachowali si jak
prawdziwi zawodowcy. Rozmowa nie bya cakiem przyjemna, pojawio si w niej kilka
zgrzytw, ale tego naleao oczekiwa od dwch osb asertywnie bronicych celw, ktre
nie s ze sob zgodne.
A co z dlaczego?
Moesz myle, e Paula powinna bya wyjani, dlaczego przygotowanie strony logowania
zajmie duo wicej czasu. Z mojego dowiadczenia wynika jednak, e powd ma duo
mniejsze znaczenie od faktu. A faktem jest, e prace nad stron logowania potrwaj dwa
tygodnie. Dlaczego potrwa to tak dugo, jest ju tylko mao znaczcym szczegem.
Mimo to, znajc powody, Mike mgby zrozumie, a przez to i zaakceptowa sam fakt.
Zgadza si. I w sytuacjach, w ktrych Mike ma odpowiedni wiedz techniczn oraz ch
zrozumienia, takie wyjanienia mogyby by przydatne. Jednak Mike mgby si te nie
zgodzi z takimi wnioskami. Mgby doj do wniosku, e Paula wszystko robi le. Mgby
stwierdzi, e wcale nie potrzeba jej tych wszystkich testw, kontroli, a poza tym krok 12.
mona miao pomin. Prezentowanie zbyt wielu informacji moe by zaproszeniem do
mikrozarzdzania.
Wysokie stawki
Najmocniej naley sprzeciwia si wtedy, gdy stawka jest najwysza. Im wysza stawka,
tym wiksz si zyskuje Twoje nie.
To w ogle nie powinno wymaga wyjanie. Jeeli koszt pomyki byby tak duy, e
zaleaoby od tego przetrwanie firmy, Twoim bezwzgldnym obowizkiem jest przekazanie
menederom jak najdokadniejszych informacji. A to czsto oznacza sprzeciwianie si
ich daniom.
Don (dyrektor dziau rozwoju): Zgodnie z naszymi aktualnymi szacunkami projekt
Zota Kura powinien zosta ukoczony za dwanacie tygodni z dokadnoci
do plus minus piciu tygodni.
54
G RACZ ZESPOOWY
Charles (prezes): (siedzi przez pitnacie sekund z coraz bardziej czerwon twarz)
Chcesz przez to powiedzie, e bdziemy gotowi dopiero za siedemnacie
tygodni?.
Don:
Tak, to moliwe.
Charles: (wstaje, sekund pniej wstaje te Don) Do jasnej cholery! Cao miaa by
gotowa trzy tygodnie temu! Klienci dzwoni do mnie codziennie i wypytuj,
gdzie podziewa si ich system. Nie mam zamiaru informowa ich, e bd
musieli poczeka jeszcze cztery miesice. Musisz si bardziej postara!
Don:
Charles, mwiem ci ju trzy miesice temu, e po tych zwolnieniach bdziemy

potrzebowa czterech dodatkowych miesicy. Wyrzucie ponad 20 procent
mojego zespou! Czy ju wtedy informowae klientw, e projekt si opni?.
Charles: Dobrze wiesz, e tego nie zrobiem. Don, nie moemy sobie pozwoli na
utrat tego zamwienia (milknie i blednie). Przecie bez niego siedzimy
w gbokim bagnie. Chyba dobrze o tym wiesz. A teraz jeszcze to opnienie.
Obawiam si co ja mam powiedzie zarzdowi? (Powoli siada w swoim
fotelu, prbujc zebra si w sobie). Naprawd musisz si bardziej postara.
Don:
Tutaj nic nie mog zrobi. Przerabialimy to ju. Klient nie chce ograniczy
projektu ani nie chce zaakceptowa czciowych wyda. Chc mie jedn
wielk instalacj i zapomnie o wszystkim. W tych warunkach nie da si zrobi
nic szybciej. Po prostu si nie da.
Charles: Cholera. Gdyby to twoja posada bya zagroona, pewnie nie byby tak twardy.
Don:
Przykro mi, ale zwolnienie mnie w aden sposb nie poprawi szacunkw.
Charles: Dobra, koczymy. Wracaj do swojego zespou i pchaj ten projekt do przodu.
Ja musz wykona kilka mao przyjemnych telefonw.
Oczywicie Charles powinien by poinformowa klienta o nowych terminach ju trzy
miesice temu, gdy tylko si o nich dowiedzia. Przynajmniej teraz podj waciw decyzj
i zapa za telefon (zarzd te musi poinformowa). Jeeli jednak Don nie obstawaby przy
swoim, to te telefony z pewnoci nie zostayby wykonane.
Gracz zespoowy
Wszyscy wielokrotnie syszelimy, jak wane jest, eby by graczem zespoowym. Gracz
zespoowy gra na swojej pozycji tak dobrze, jak tylko potrafi, i pomaga kolegom z zespou,
gdy tego potrzebuj. Gracz zespoowy czsto wymienia si informacjami, wsppracuje
z caym zespoem, a swoje obowizki wykonuje tak dobrze, jak tylko potrafi.
Graczem zespoowym nie jest jednak kto, kto na wszystko si zgadza. Przyjrzyjmy si
kolejnej rozmowie.
55
R OZDZIA 2.
K IEDY MWI NIE
Paula: Mike! Mam dla ciebie kilka szacunkw. Zesp zdecydowa, e bdziemy
w stanie dostarczy wersj demonstracyjn za mniej wicej osiem tygodni.
Plus minus tydzie.
Mike: Chyba artujesz. Wedug oficjalnego planu demo ma by gotowe za sze
tygodni.
Paula: I nie zapytalicie nas o zdanie? Daj spokj, przecie nie moesz tak wymusza
terminw.
Mike: Przykro mi, ju si stao.
Paula: (wzdycha) OK, zapytam w zespole, czy moemy co zrobi, eby cokolwiek
dostarczy w cigu szeciu tygodni. Ale na cay system nie ma najmniejszych
szans. Pewnych funkcji bdzie brakowao, a i dane bd niekompletne.
Mike: Paula, klienci chc zobaczy w peni funkcjonalne demo.
Paula: Zapomnij. Na to nie ma najmniejszych szans.
Mike: Cholera! Dobra, zobacz, co si da zrobi, i do jutra mnie poinformuj.
Paula: Tyle mog ci obieca.
Mike: Nie ma adnej moliwoci, eby skrci prace? Moe da si pracowa jako
sprytniej i szybciej?.
Paula: Wszyscy dziaamy ju cakiem sprytnie. Doskonale wiemy, jak si za to zabra,
i z szacunkw wynika, e cao bdzie gotowa za osiem lub dziewi tygodni.
Ale nie za sze.
Mike: Moe jakie nadgodziny?.
Paula: To tylko wszystko spowolni. Pamitasz, jaki powsta baagan, gdy ostatnio
zarzdzono prac w nadgodzinach?.
Mike: No tak, ale tym razem wcale tak nie musi by.
Paula: Nie ud si. Bdzie tak jak ostatnio. Moesz mi zaufa. Demo bdzie gotowe
za osiem lub dziewi tygodni. Nie za sze.
Mike: Dobra, przelij mi szczegowy plan, ale zastanw si jeszcze, jak zaatwi to
w sze tygodni. Wiem, e co si wam uda wymyli.
Paula: Mike! Nie! Nie uda si! Mog ci dostarczy plan na sze tygodni, ale w demo
bdzie brakowao pewnych funkcji i danych. Tylko tak masz moliwo.
Mike: OK, OK. I tak wiem, e jak si postaracie, to bdziecie w stanie zdziaa cuda
(odchodzi, krcc gow).
Pniej, w trakcie zebrania dyrektorw w sprawie strategii.
Don: Mike, jak wiesz, klient zawita do nas za sze tygodni i bdzie chcia obejrze
demo swojego systemu. Mwili ju, e chcieliby, aby wszystko do tego czasu
dziaao.
56
G RACZ ZESPOOWY
Mike: Nie ma sprawy. Bdziemy gotowi! Mj zesp urabia si po okcie, eby ze

wszystkim zdy. Zapewne bdzie trzeba zrobi troch nadgodzin i zastosowa
par sprytnych rozwiza, ale wierz, e nam si uda.
Don: Mio sysze, e mamy w firmie grup wspaniaych graczy zespoowych.
Kto w tym scenariuszu by prawdziwym graczem zespoowym? Paula wystpowaa w imieniu
swojego zespou i najlepiej, jak potrafia, prezentowaa, co mona, a czego nie mona
oczekiwa. Agresywnie bronia swoich pozycji pomimo pochlebstw i podstpw Mikea.
Mike z kolei gra w zespole jednoosobowym. Dziaa tylko w swoim interesie. Zdecydowanie
nie naley do zespou Pauli, poniewa podj za ni zobowizanie, ktre ona jasno opisaa
jako nie do wykonania. Nie gra te w zespole Dona (cho z pewnoci by si z tym nie
zgodzi), poniewa okama go bez zmruenia oka.
Dlaczego zatem Mike robi takie rzeczy? Chce, eby Don uzna go za gracza zespoowego.
Jednoczenie wierzy, e bdzie w stanie w ten lub inny sposb przymusi Paul, by
sprbowaa zrobi wszystko w sze tygodni. Mike wcale nie jest zy. Jest pewien wasnych
umiejtnoci, za pomoc ktrych narzuca ludziom swoj wol.
Prbowanie
Najgorsz odpowiedzi, jakiej Paula mogaby udzieli w wyniku manipulacji Mikea,
byoby: OK, sprbujemy. Nie chciabym tu brzmie jak Yoda, ale w tym przypadku
ma on cakowit racj. Nie ma prbowania.
Moliwe, e ta idea Ci si nie podoba. By moe sdzisz, e prbowanie jest czym
pozytywnym. W kocu czy Kolumb odkryby Ameryk, gdyby nie prbowa?
Niestety, sowo prbowa ma wiele definicji. Definicja, z ktr mam najwicej problemw,
jest taka: Dooy stara. Jakich dodatkowych stara mona wymaga od Pauli, eby
dostarczya system na czas? Jeeli daoby si zwikszy starania w tym zakresie, to znaczyoby,
e zesp Pauli i ona sama nie wykorzystywali wszystkich swoich moliwoci. Musieli
ukrywa pewne rezerwy na wszelki wypadek1.
Obietnica sprbowania jest jednoczenie przyznaniem si, e nie wykorzystujesz wszystkich
swoich moliwoci; e masz jeszcze w zanadrzu co, czego mona uy. Obietnica
sprbowania jest te przyznaniem, e cel jest osigalny, o ile zostan zastosowane te
dodatkowe rodki. Co wicej, jest te zobowizaniem si do wykorzystania tych rodkw,
aby osign cel. Oznacza to, e obiecujc sprbowa, zobowizujesz si do osignicia
wyznaczonych celw. Na obiecujcego spada zatem cay ciar. Jeeli wasze prbowanie
nie przyniesie podanych skutkw, to znaczy, e zawiedlicie.
Tak jak Kurak Leghorn: Na takie wanie przypadki zawsze numeruj swoje pira.
57
R OZDZIA 2.
K IEDY MWI NIE
Masz jaki dodatkowy rezerwuar energii na czarn godzin? Jeeli wykorzystasz te rezerwy,
to uda si zrealizowa plan? Czy moe obiecujc sprbowa, najzwyczajniej w wiecie
podpisujesz wyrok na siebie i zesp?
Obiecujc sprbowa, obiecujesz te zmieni dotychczasowe plany. W kocu te stare byy
niewystarczajce. Obiecujc sprbowa, przyznajesz, e istnieje jaki nowy plan. Jak zatem
on wyglda? Jakie zmiany wprowadzisz w swoim zachowaniu? Czym bd rniy si Twoje
dziaania, poniewa teraz zaczynasz prbowa?
Jeeli nie masz adnego nowego planu, jeeli nie wprowadzisz zmiany w swoim dziaaniu,
jeeli bdziesz pracowa dokadnie tak jak do tej pory, zanim zaczo si prbowanie,
to na czym to prbowanie ma niby polega?
Jeeli jednak nie masz adnych rezerw energetycznych, jeeli nie masz nowego planu, jeeli
nie masz zamiaru zmienia swoich zachowa i jeeli masz cakowit pewno co do swojego
pierwotnego planu, to obietnica sprbowania bdzie absolutnie nieszczera. Mona bdzie
nazwa j kamstwem. Jedynym powodem, dla ktrego skadasz tak obietnic, jest prba
zachowania dobrej opinii i uniknicia konfrontacji.
Postawa Pauli jest tu zdecydowanie lepsza. Cay czas przypominaa Mikeowi, e szacunek
zespou nie jest cakowicie dokadny. Mwia cigle o omiu lub dziewiciu tygodniach.
Wyrazia t niepewno i nigdy si z niej nie wycofaa. Nigdy nie zasugerowaa, e istniej
jakie rezerwy, nowy plan albo jakakolwiek zmiana zachowa, ktre mogyby zmniejszy
stopie tej niepewnoci.
Trzy tygodnie pniej
Mike: Paula, termin dema ju za trzy tygodnie, a klienci chc zobaczy dziaajc
funkcj przesyania plikw.
Paula: Hola! Tego nie byo na uzgodnionej licie funkcji.
Mike: No wiem, ale klient si tego domaga.
Paula: Dobra, to znaczy jednak, e w demie nie bd dziaay centralne logowanie
albo kopia zapasowa.
Mike: Wykluczone! Te funkcje rwnie chc zobaczy.
Paula: Czyli chc zobaczy dziaajce wszystkie funkcje? To mi chcesz powiedzie?
Przecie ju dawno temu mwiam ci, e nie ma na to najmniejszych szans.
Mike: Przykro mi, Paula, ale klient jest nieugity. Chc zobaczy wszystkie funkcje.
Paula: Ale nie zobacz. Nie ma takiej moliwoci.
Mike: Daj spokj, nie moecie chocia sprbowa?.
Paula: Mike, prbowa to ja mog lewitacji. Mog prbowa zmieni ow w zoto.
Mog prbowa przepyn abk Atlantyk. Jak mylisz, uda mi si?.
58
G RACZ ZESPOOWY
Mike: Gadasz od rzeczy. Przecie nie dam niemoliwego.

Paula: Owszem, dasz.
(Mike umiecha si, krci gow i odchodzi).
Mike: Mimo wszystko wierz w ciebie. Wiem, e mnie nie zawiedziesz.
Paula: (mwi do plecw Mikea) Mike, w jakim wiecie ty yjesz? To nie zapowiada
niczego dobrego.
(Mike tylko macha rk, nawet si nie odwracajc).
Pasywna agresja
Paula musi podj bardzo ciekaw decyzj. Podejrzewa ona, e Mike nie przekazuje Donowi
informacji o jej szacunkach. Moe zatem pozwoli Mikeowi i dalej t drog, a do
przepaci. Moe sprawdzi, czy w dokumentacji znajduj si wszystkie przygotowane przez
ni dokumenty, tak eby w momencie rozptania si awantury moga udowodni, co i kiedy
mwia Mikeowi. Mwic krtko, pozwoli Mikeowi przygotowa wasn szubienic.
Moe te zapobiec katastrofie i porozmawia bezporednio z Donem. Oczywicie to do
ryzykowne posunicie, ale na tym rwnie polega gra zespoowa. Jeeli pocig towarowy
pdzi prosto na was, a tylko ty jeste w stanie go zobaczy, to moesz albo po cichu zej
z torw i popatrze, jak pocig przerabia kolegw na kotlety, albo gono krzycze:
Uwaga! Pocig! Schodzi z torw!.
Dwa dni pniej
Paula: Mike, przekazae ju Donowi moje szacunki? Mam nadziej, e poinformowa
ju klienta, i w demie nie bdzie dziaaa funkcja przesyania plikw.
Mike: Przecie powiedziaa, e to dla mnie zaatwisz.
Paula: Nie, Mike, nic takiego nie powiedziaam. Mwiam, e to niemoliwe. Tutaj masz
kopi wiadomoci, ktr wysaam ci po naszej rozmowie.
Mike: No tak, ale zrozumiaem, e mimo wszystko bdziesz prbowa.
Paula: Ju o tym rozmawialimy. Pamitasz? Ow, zoto
Mike: (wzdycha) Paula, no musisz to zaatwi. Po prostu musisz. Prosz, porusz niebo
i ziemi, ale ta funkcja musi dziaa na czas. Jeste mi to winna.
Paula: Mike, mylisz si. Nic nie jestem ci winna. Jedyne, co musz zrobi, to przekaza
t informacj Donowi, skoro ty nie jeste w stanie.
Mike: To byoby przekroczeniem twoich kompetencji. Nie omielisz si.
Paula: Nie chc tego, ale nie dajesz mi innego wyboru.
Mike: Och, Paula
59
R OZDZIA 2.
K IEDY MWI NIE
Paula: Mike, pogd si z tym, e pewne funkcje nie bd gotowe na dzie

uruchomienia dema. Przyjmij to w kocu do wiadomoci. Przesta namawia
mnie do ciszej pracy. I zapomnij o tym, e w jaki sposb uda si mi wycign
krlika z kapelusza. Nie masz wyboru. Musisz o tym powiedzie Donowi,
i to najlepiej dzisiaj.
Mike: (robi wielkie oczy) Dzisiaj?.
Paula: Tak, Mike. Dzisiaj, poniewa na jutro planuj spotkanie z tob i Donem w celu
omwienia funkcji, ktre maj dziaa w demie. Jeeli to spotkanie nie odbdzie
si jutro, to bd musiaa sama uda si do Dona. A tutaj masz kopi wiadomoci
wyjaniajcej t sytuacj.
Mike: Zabezpieczasz sobie tyy?.
Paula: Mike, prbuj zabezpieczy tyy nam obojgu. Wyobraasz sobie, jakie mielibymy
kopoty, gdyby przyszed tu klient i chcia obejrze demo z niedokoczonymi
funkcjami?.
Co stanie si z Paul i Mikiem? Pozwol Ci wymyli moliwe rozwizania. Wane jest,
e Paula zachowaa si bardzo profesjonalnie. Zawsze we waciwy sposb i we waciwym
momencie odmawiaa Mikeowi. Powiedziaa nie, gdy bya namawiana do zmiany swoich
szacunkw. Odmawiaa mimo rnych manipulacji, pochlebstw i prb. I co najwaniejsze,
konsekwentnie zaprzeczaa zudzeniom i pasywnym dziaaniom Mikea. Paula bya
prawdziwym graczem zespoowym. Mike potrzebowa pomocy, a ona zrobia wszystko,
co w jej mocy, eby mu pomc.
Koszta przytakiwania
Zwykle chcemy po prostu powiedzie tak. I rzeczywicie zdrowo dziaajce zespoy
szukaj jakiejkolwiek moliwoci, eby powiedzie tak. Menederowie i programici
wsppracujcy w ramach takich zespow negocjuj ze sob tak dugo, a ustal plan
dziaa, na ktry obie strony mog si zgodzi.
Jak jednak widzielimy, czasami jedyn metod na uzyskanie zdrowego tak jest brak
oporw przed mwieniem nie.
Zastanwmy si nad ponisz opowieci, ktr John Blanco opublikowa na swoim blogu2.
Prezentuj j tutaj za jego zgod. Czytajc tekst, sprbuj zastanowi si, kiedy i jak powinien
by powiedzie nie.
http://raptureinvenice.com/?p=63.
60
K OSZTA PRZYTAKIWANIA
Czy dobry kod jest nieosigalny?

Po osigniciu wieku lat nastu decydujesz, e chcesz zosta programist. W szkole redniej uczysz
si pisania programw, wykorzystujc zasady programowania obiektowego. Po dostaniu si na
studia wykorzystujesz te wyuczone zasady we wszystkich nowych dziedzinach, takich jak sztuczna
inteligencja lub grafika trjwymiarowa.
I gdy w kocu dostajesz si do rodowiska zawodowcw, rozpoczynasz niekoczc si prb
tworzenia wysokiej jakoci, atwego w obsudze, po prostu perfekcyjnego kodu, ktry przetrwa
prb czasu.
Wysokiej jakoci. He, he! Niezy dowcip.
Uwaam si za szczciarza i uwielbiam wzorce projektowe. Lubi czyta teorie opisujce
perfekcyjny kod. Nie mam adnych problemw z prowadzeniem cigncych si godzinami
dyskusji, dlaczego wybr mojego partnera dotyczcy hierarchii dziedziczenia jest niewaciwy
w kocu konstrukcja MA jest w wielu przypadkach znacznie lepsza od JEST. Ale ostatnio co
nie daje mi spokoju i cay czas si zastanawiam
Czy podczas tworzenia nowoczesnego oprogramowania niemoliwe jest uzyskanie dobrego kodu?
Typowa propozycja projektu

Jako kontraktowy programista pracujcy na peny etat (a czasem te na p etatu) spdzam cae
dnie (oraz noce) na tworzeniu aplikacji mobilnych dla rnych klientw. I przez cae lata takiej
pracy nauczyem si, e wymagania zwizane z prac dla klienta uniemoliwiaj mi przygotowanie
aplikacji o jakoci, jak chciabym osign.
Zanim zaczn, pozwlcie, e wyjani: nie wynika to z tego, e nigdy si odpowiednio nie staraem.
Uwielbiam temat czystego kodu. Nie znam nikogo, kto rwnie mocno jak ja stara si uzyska
doskonay projekt oprogramowania. Niestety, samo wykonanie nie jest ju tak idealne, cho wcale
nie z powodw, ktre mog wam teraz przyj na myl.
Opowiem wam histori.
Pod koniec zeszego roku cakiem znana firma ogosia przetarg na przygotowanie dla niej aplikacji.
To ogromna sie handlowa, ktrej w tej historii nadam fikcyjn nazw Gorilla Mart. Twierdzili,
e chc pojawi si w kocu na iPhonach, i dlatego chcieliby, eby przygotowa dla nich aplikacj
jeszcze przed czarnym pitkiem3. Jaki w tym haczyk? Jest pierwszy listopada. To znaczy, e na
przygotowanie aplikacji pozostay niecae cztery tygodnie. I dodatkowo Apple potrzebuje dwch
tygodni na zatwierdzenie zgoszonego programu (wspomnienie starych dobrych dni). Czyli
zaraz, caa aplikacja ma zosta napisana w DWA TYGODNIE?!?!
Tak. Mamy dwa tygodnie na napisanie aplikacji. Pech chcia, e wygralimy przetarg. (W tym
biznesie wana jest wielko klienta). I teraz musimy si wywiza ze zobowizania.
Bdzie dobrze mwi jeden z dyrektorw Gorilla Martu. Aplikacja ma by prosta.
Musi wywietla tylko kilka produktw z naszego katalogu i pozwala na wyszukiwanie
sklepw. Tak funkcj mamy ju na naszej stronie. Dostarczymy te potrzebn grafik.
Prawdopodobnie moecie wszystko, jak to si mwi zakodowa na twardo!
Czarny pitek potoczna nazwa dnia przypadajcego po wicie Dzikczynienia.

W USA jest to dla sprzedawcw czsto najbardziej dochodowy dzie w cigu caego roku.
61
R OZDZIA 2.
K IEDY MWI NIE
Wtrca si dyrektor numer 2: I jeszcze par kuponw, ktre klient bdzie mg pokaza
przy kasie. Sama aplikacja bdzie do jednorazowego uytku. Za chwil przejdziemy do fazy
drugiej i przygotujemy co wikszego od podstaw.
I wtedy si zaczyna. Mimo lat cigego przypominania sobie, e kada funkcja wymylona przez
klienta bdzie o wiele bardziej skomplikowana w realizacji, ni wynika z opisu, i tak si zgadzasz.
Naprawd wierzysz, e da si to zrobi w dwa tygodnie. Tak! Zrobimy to! Tym razem bdzie
inaczej! To tylko par obrazkw i wywoanie usugi, eby pobra pozycj sklepu. XML! Buka
z masem. Zrobimy! Ale si nakrciem! Do roboty!
A wystarcza tylko jeden dzie, eby rzeczywisto sprowadzia ci z powrotem na ziemi.
Ja: Moesz powiedzie mi, jak wywoa t usug sieciow, eby dosta pozycj sklepu?.
Klient: Jak usug sieciow?.
Ja: .
To si naprawd wydarzyo. Ich usuga wyznaczania pozycji sklepu, dostpna w prawym grnym
rogu ich strony internetowej, nie bya usug sieciow. Bya generowana przez kod napisany
w Javie. Zapomnij o jakim API. Niet. A eby byo gorzej, kod jest serwowany przez strategicznego
partnera Gorilla Martu.
Witamy w strasznym wiecie stron trzecich.
Z punktu widzenia klienta strona trzecia jest podobna do Angeliny Jolie. Mimo obietnic,
e bdziesz mg poprowadzi z ni wiat konwersacj przy wystawnej kolacji, z cieniem nadziei
na co ciekawszego pniej przykro mi, nic z tego. Pozostaje ci fantazjowanie w czasie, gdy sam
musisz zaj si sprawami.
W moim przypadku jedyne, co udao mi si wydusi z Gorilla Martu, to bya aktualna lista
sklepw w postaci pliku Excela. Musiaem od zera pisa kod wyznaczajcy pozycje sklepw.
A po poudniu tego samego dnia zaoyli nam podwjnego nelsona. Chcieli, eby produkty
i dane do kuponw byy dostpne online, tak eby mogli je co tydzie zmienia. Tyle widzielimy
z kodowania na twardo! Dwa tygodnie na napisanie aplikacji dla iPhonea zmieniy si w dwa
tygodnie na napisanie aplikacji dla iPhonea, aplikacji serwera w PHP i wykonanie integracji.
e co? Chc, ebym jeszcze przej na siebie zadania QA?
eby zrekompensowa tak krtki czas, musimy zatem szybciej tworzy kod. Zapomnij o fabryce
abstrakcyjnej. Zamiast kompozycji uyj wielkiej, ohydnej ptli. Nie ma czasu!
Dobry kod jest w tych warunkach nieosigalny.
Dwa tygodnie do celu

Mwi wam, te dwa tygodnie byy naprawd paskudne. Dodatkowo dwa dni mona byo skreli
z powodu caodniowych spotka dotyczcych mojego nastpnego projektu. (To jeszcze bardziej
podkrela, jak krtki mielimy termin realizacji). Ostatecznie miaem zaledwie osiem dni na
wszystkie prace. W pierwszym tygodniu pracowaem 74 godziny, a w drugim O Boe! Nawet
nie pamitam, po prostu wypalio mi te synapsy, ale to chyba akurat jest w porzdku.
62
K OSZTA PRZYTAKIWANIA
Tych osiem dni spdziem na tworzeniu kodu w przyspieszonym tempie. Wykorzystaem wszystkie
dostpne mi narzdzia, pozwalajce szybciej zakoczy prace: kopiuj i wklej (czyli ponowne
wykorzystanie kodu), magiczne liczby (unikaem pracy zwizanej z definiowaniem staych i potem
cigym ich wpisywaniem) i absolutnie adnych testw jednostkowych! (Komu s w takim
momencie potrzebne czerwone kropki? To tylko demotywuje!)
Powstay kod by naprawd paskudny i nigdy nie miaem czasu, eby go poprawi. Jeeli jednak
wzi pod uwag czas wykonania, to wyszed cakiem sprawnie, a poza tym i tak mia zosta zaraz
wyrzucony. Co wam to przypomina? Tylko czekajcie, bdzie jeszcze lepiej.
Kiedy wprowadzaem w aplikacji ostatnie poprawki (te dotyczyy wycznie kodu serwerowego),
zaczem przeglda cao powstaego kodu i pomylaem sobie, e moe jednak byo warto.
Mimo wszystko aplikacja bya gotowa, a mnie udao si przey!
Cze, wanie zatrudnilimy Boba. Jest bardzo zajty i nie moe sam do ciebie zadzwoni,
ale twierdzi, e powinnimy da od uytkownikw podania adresu e-mail w zamian za
kupon. Nie widzia jeszcze aplikacji, ale uwaa, e to byby wietny pomys. Chcemy te
mie system raportw, eby te adresy pobiera z serwera. Taki adny i niezbyt kosztowny.
(Zaraz, ten ostatni tekst by z Monty Pythona). A skoro mwimy o kuponach, to powinny
si przedawnia po zdefiniowanej przez nas liczbie dni. I jeszcze
Wrmy jeszcze do podstaw. Co wiemy na temat tego, jak powinien wyglda dobry kod?
Dobry kod powinien atwo si rozbudowywa i by atwy w konserwacji. Powinien a prosi
si o wprowadzanie zmian. Powinno si go czyta jak proz. C, to niestety nie by dobry kod.
Inna rzecz. Jeeli chcesz by lepszym programist, wci musisz o tym pamita: klienci zawsze
bd przesuwa termin. Zawsze bd chcieli mie wicej funkcji. Zawsze bd chcieli wprowadza
zmiany, ale ju w pnej fazie prac. A oto formua opisujca to, czego mona si spodziewa:
(liczba dyrektorw)2
+ 2 * liczba nowych dyrektorw
+ liczba dzieci Boba
= DNI DODANE W OSTATNIEJ CHWILI
Trzeba jednak przyzna, e dyrektorzy to cakiem porzdni ludzie. Tak sdz. Musz dba o swoje
rodziny (zakadajc, e szatan pozwoli im je zaoy). Chc, eby aplikacja okazaa si sukcesem
(czas na awans). Problem polega na tym, e wszyscy oni chc by bezporednio odpowiedzialni
za ten sukces. Gdy ju wszystko zostanie powiedziane i zrobione, chc wskaza okrelon funkcj
lub decyzj projektow, ktr mogliby nazwa swoj.
A wracajc do opowieci, dodalimy do projektu jeszcze dwa dni i wprowadzilimy funkcj
pobierania adresw e-mail. Zaraz potem padem z wyczerpania.
Klient nigdy nie przejmuje si tak jak Ty

Klienci, mimo tego, jak si zachowuj, mimo pozornego popiechu, tak naprawd nie przejmuj
si, czy aplikacja powstanie na czas. Tego popoudnia, kiedy ponownie zakoczyem prace nad
aplikacj, wysaem e-mail z kocow wersj programu do wszystkich udziaowcw, dyrektorw
63
R OZDZIA 2.
K IEDY MWI NIE
(grrr!), menederw itd. GOTOWE! OTO WERSJA 1.0! CHWALCIE ME IMI! Kliknem
przycisk Wylij i z umiechem opadem na krzeso. Zaczem fantazjowa, jak to caa firma poniesie
mnie na rkach w kierunku 42 Ulicy, gdzie zostan koronowany na Najlepszego Programist
Wszech Czasw. A przynajmniej moj podobizn umieszcz na wszystkich swoich reklamach.
Zadziwiajce, e nie podzielali mojej wizji. Tak naprawd to nie wiem, o czym myleli, bo nie
dostaem adnej odpowiedzi. Absolutnie adnej. Okazao si, e wszyscy w Gorilla Marcie byli
tak zabiegani, e zajmowali si ju nastpnym projektem.
Mylicie, e kami? No to jedziemy dalej. Wysaem podanie do sklepu Apple bez podawania
opisu aplikacji. Prosiem Gorilla Mart o przygotowanie takiego, ale si do mnie nie odezwali,
a ja nie mogem ju duej czeka. (Czytalicie akapity powyej?) Prosiem raz jeszcze. I jeszcze
raz. Wspierao mnie w tym nasze wasne kierownictwo. Dwa razy dostaem odpowied o treci:
Czego waciwie potrzebujesz?. MUSZ MIE OPIS APLIKACJI!
Tydzie pniej Apple zaczo testowa aplikacj. Zwykle jest to czas wielkiej radoci, ale tym
razem czuem tylko miertelny strach. Tak jak oczekiwaem, pniej tego dnia aplikacja zostaa
odrzucona. By to najsmutniejszy i najgorszy z moliwych powodw odrzucenia aplikacji, jaki
mog sobie wyobrazi: Aplikacja nie ma opisu. Dziaa doskonale, ale nie ma opisu. I z tego
powodu Gorilla Mart nie mia aplikacji gotowej na czarny pitek. Byem troszeczk wcieky.
Opuciem swoj rodzin, pracujc w dwutygodniowym supersprincie, ale w Gorilla Marcie
nikt nie mia czasu na napisanie opisu, mimo tygodnia nagabywa. Przesali nam go godzin
po odrzuceniu aplikacji. Najwyraniej to by sygna, eby wzi si do pracy.
Jeeli wtedy byem wcieky, to ptora tygodnia pniej zagotowaem si. Wyobraacie sobie,
e nadal nie dostarczyli nam rzeczywistych danych? Produkty i kupony na serwerze byy
faszywkami. Wymylone. Kod kuponu to byo 1234567890. No wiecie, dmuchawce, latawce.
I tego doniosego dnia o poranku sprawdziem portal, a na nim DOSTPNA BYA TA
APLIKACJA! Z wszystkimi faszywymi danymi itp.! Zawyem w najwyszym przeraeniu,
zaczem dzwoni, do kogo tylko si dao, i krzycze: POTRZEBUJ DANYCH!. Kobieta
po drugiej stronie linii spytaa, czy potrzeba mi policji, czy straakw, wic rozczyem si
z numerem 911. Nastpnie jednak zadzwoniem do Gorilla Martu i ponownie krzyczaem:
POTRZEBUJ DANYCH!. Nigdy nie zapomn ich odpowiedzi:
O, cze, John! Mamy teraz nowego wiceprezesa i zdecydowalimy si nie publikowa
tej aplikacji. Jeeli mgby, to wycofaj j z AppStore.
Ostatecznie okazao si, e przynajmniej 11 osb zarejestrowao swoje adresy e-mail w bazie
danych, co znaczyo, e jakie 11 osb mogo wej do Gorilla Martu z faszywym kuponem na
iPhonie. Oj, mogo si to le skoczy.
Po tym wszystkim mogem stwierdzi, e klient w jednym nie kama. Kod by do wyrzucenia.
Problem polega na tym, e nigdy nie zosta wykorzystany.
Wyniki? Popiech w realizacji, powolna publikacja

Lekcja wynikajca z tej opowieci jest taka, e udziaowcy, niezalenie od tego, czy w postaci
zewntrznego klienta, czy te wewntrznej kadry zarzdzajcej, wymylili, jak mona zmusi
64
K OD NIEMOLIWY
programist do szybkiego tworzenia kodu. Skutecznego? Nie. Szybkiego. Oj, tak! A cao dziaa
nastpujco:
Powiedz programicie, e aplikacja bdzie prosta. W ten sposb wpuszczasz zesp
w faszywe nastawienie. Poza tym programici zaczn te wczeniej pracowa, a wtedy
Dodawaj funkcje, twierdzc, e to zesp nie przewidzia ich niezbdnoci. W tym
przypadku treci zakodowane na twardo wymagayby cigego aktualizowania aplikacji,
przy kadej ich zmianie. Jak mogem tego nie zauway? Zauwayem, ale wczeniej dostaem
faszyw obietnic. Na tym to polega. Albo klient zatrudni kogo nowego, kto zauway,
e w aplikacji brakuje czego oczywistego. Czy jak pewnego dnia klient powie, e zatrudnili
wanie Stevea Jobsa, to do aplikacji trzeba bdzie doda troch alchemii? A potem
Przesuwaj termin. I jeszcze raz, i jeszcze. Programici pracuj najszybciej i najskuteczniej
(ale te s najbardziej podatni na robienie bdw, ale kto si tym przejmuje?), gdy do
terminu oddania projektu zostaje ju tylko kilka dni. No to po co mwi im, e mona
przesun termin, skoro s a tak produktywni? Wykorzystaj to! I w ten sposb dodaje si
jeszcze par dni, a potem tydzie, a ty cay czas pracujesz w 20-godzinnych zmianach, eby
zdy na czas. To jak z osem i marchewk, tylko e osio jest znacznie lepiej traktowany.
To rozwizanie doskonae. Czy mona ich wini za to, e wierz w jego skuteczno? Oni nie widz
tego ohydnie paskudnego kodu. I tak dzieje si za kadym razem, pomimo tego, jakie s wyniki
tych praktyk.
W ekonomii globalnej, w ktrej korporacje sprawuj wadz nad wszechmocnym dolarem,
a podniesienie ceny akcji wymaga zwolnienia czci pracownikw, zmuszenia pozostaych do
nadgodzin i zlecenia prac za granic, taka metoda minimalizowania kosztw pracy programistw
sprawia, e dobry kod jest niepotrzebny. Jeeli nie bdziemy ostroni, to zostaniemy poproszeni/
zmuszeni/wmanewrowani w pisanie kodu o dwa razy wikszej objtoci w czasie o poow krtszym.
Kod niemoliwy
W przytoczonej opowieci John pyta: Czy dobry kod jest niemoliwy do osignicia?.
Ale tak naprawd pytanie brzmi: Czy profesjonalizm jest niemoliwy do osignicia?.
W kocu w tej opowieci o wszelkich dysfunkcjach ucierpia nie tylko kod. W tej caej
przygodzie stracili te rodzina Johna, jego pracodawca, klient oraz uytkownicy. Tutaj
straty ponieli wszyscy4. A ponieli je z powodu braku profesjonalizmu.
Kto zatem zachowywa si nieprofesjonalnie? John jasno stwierdza, e win ponosz
dyrektorzy Gorilla Martu. W caej jego opowieci cakiem jasno przedstawia ich niewaciwe
zachowania. Ale czy to zachowanie rzeczywicie byo ze? Osobicie sdz inaczej.
Zarzd Gorilla Martu chcia mie moliwo udostpnienia aplikacji dla iPhone na czarny
pitek. Zdecydowali si zapaci za tak aplikacj. Znaleli kogo, kto podj si tego zadania.
Dlaczego wic zrzuca win na nich?
4
By moe wyjtkiem jest bezporedni pracodawca Johna, ale myl, e i on ponis tu strat.
65
R OZDZIA 2.
K IEDY MWI NIE
Owszem, wystpio kilka niewypaw w komunikacji. Najwyraniej kadra zarzdzajca nie

miaa pojcia, czym jest usuga sieciowa. Poza tym pojawiy si standardowe problemy
wynikajce z faktu, e jedna cz wielkiej korporacji nie wie, co robi inna cz. Ale tego
wszystkiego mona byo oczekiwa. Nawet John przyznaje to, mwic: Mimo lat cigego
przypominania sobie, e kada funkcja wymylona przez klienta bdzie o wiele bardziej
skomplikowana w realizacji, ni wynika z opisu.
Skoro zatem winna caej tej sytuacji nie jest firma Gorilla Mart, to kto jest winny?
By moe win naley obarczy pracodawc Johna? Co prawda, John nie powiedzia tego
jasno, ale ze stwierdzenia: W tym biznesie wana jest wielko klienta mona wiele
wyczyta. Czy zatem pracodawca Johna zoy firmie Gorilla Mart obietnic, ktrej nie
mg dotrzyma? Czy naciskali na Johna (porednio lub bezporednio), eby tej obietnicy
jednak dotrzyma? John nic o tym nie mwi, wic zostaj nam tylko domysy.
Biorc to wszystko pod uwag, jak w tym wszystkim odpowiedzialno mia John? Uwaam,
e w tym przypadku win za ca t sytuacj ponosi wanie on. To on zaakceptowa
pierwotny dwutygodniowy termin, cho doskonale wiedzia, e projekty zwykle s znacznie
bardziej zoone, ni pocztkowo si wydaje. To on zgodzi si na danie dopisania jeszcze
serwera PHP. To on zaakceptowa funkcje rejestracji adresw e-mail oraz terminu wanoci
kuponw. To John pracowa po 20 godzin dziennie i 90 godzin tygodniowo. To on opuci
na ten czas swoj rodzin i porzuci normalne ycie, tylko po to, eby zdy na czas.
Dlaczego zatem podj si tego zadania? Mwi nam o tym bez adnego skrpowania:
Kliknem przycisk Wylij i z umiechem opadem na krzeso. Zaczem fantazjowa,
jak to caa firma poniesie mnie na rkach w kierunku 42 Ulicy, gdzie zostan koronowany
na Najlepszego Programist Wszech Czasw. John chcia po prostu zosta bohaterem.
Zauway swoj szans na wielk nagrod i postanowi z niej skorzysta. Pochyli si, eby
podnie t zot monet.
Profesjonalici czsto staj si bohaterami, ale nie dlatego, e bardzo si o to staraj. Staj
si bohaterami, poniewa dobrze wywizuj si ze swoich obowizkw, wykonujc zadania
na czas i w ramach budetu. Prbujc zyska saw zbawiciela, John nie zachowywa si
profesjonalnie.
John nie powinien by si zgadza na pierwotny termin dwch tygodni. A jeeli ju by
si na to zgodzi, to powinien by protestowa, gdy tylko dowiedzia si, e nie ma adnej
usugi sieciowej. Powinien nie zgadza si na dania dodania funkcji rejestracji adresw
e-mail i przedawniania kuponw. Powinien by blokowa wszystko to, co wymagaoby
tak straszliwych nadgodzin i innych powice.
Przede wszystkim jednak John powinien by zaprzeczy swojej wasnej decyzji, e jedyn
metod zrealizowania projektu na czas jest wytworzenie baaganiarskiego kodu. Zauwa,
co John powiedzia o dobrym kodzie i testach jednostkowych: eby zrekompensowa
66
K OD NIEMOLIWY
tak krtki czas, musimy zatem szybciej tworzy kod. Zapomnij o fabryce abstrakcyjnej.
Zamiast kompozycji uyj wielkiej, ohydnej ptli. Nie ma czasu!.
I jeszcze to:
Tych osiem dni spdziem na tworzeniu kodu w przyspieszonym tempie. Wykorzystaem
wszystkie dostpne mi narzdzia, pozwalajce szybciej zakoczy prace: kopiuj i wklej
(czyli ponowne wykorzystanie kodu), magiczne liczby (unikaem pracy zwizanej
z definiowaniem staych i potem cigym ich wpisywaniem) i absolutnie adnych testw
jednostkowych! (Komu s w takim momencie potrzebne czerwone kropki? To tylko
demotywuje!).
Zatwierdzenie tych wszystkich decyzji byo prawdziwym powodem caej katastrofy. John
zaoy, e jedynym sposobem na sukces jest w tym przypadku nieprofesjonalne zachowanie,
dlatego zasuy sobie na odpowiedni nagrod.
To wszystko moe brzmie bardzo okrutnie, ale wcale nie o to mi chodzi. W poprzednim
rozdziale opowiadaem ju, e podobne bdy popeniaem rwnie w swojej karierze.
Pokusa bohaterskiego rozwizania problemu jest po prostu ogromna. Trzeba sobie
jednak uwiadomi, e celowe porzucanie naszej profesjonalnej dyscypliny nie jest
waciw metod rozwizywania problemw. Porzucenie tej dyscypliny jest pierwszym
krokiem do popadnicia w nowe kopoty.
W ten sposb mog ostatecznie odpowiedzie na gwne pytania postawione przez Johna.
Czy dobry kod jest nieosigalny? Czy profesjonalizm jest niemoliwy?
Odpowied: Uwaam, e nie.
67
R OZDZIA 2.
K IEDY MWI NIE
68
K IEDY MWI TAK
Czy wiesz, e to ja wynalazem poczt gosow? To prawda! Waciwie to patent na poczt

gosow otrzymay trzy osoby: Ken Finder, Jerry Fitzpatrick i ja. Byo to na pocztku lat 80.,
w czasie gdy pracowalimy dla firmy o nazwie Teradyne. Nasz prezes przydzieli nam
zadanie wymylenia zupenie nowego produktu, a my wymylilimy elektronicznego
recepcjonist, w skrcie ER.
Dzisiaj chyba kady ju wie, czym jest ER. To jedna z tych straszliwych maszyn
odbierajcych telefony w firmach i zadajcych te wszystkie gupie pytania, na ktre
musisz odpowiada, naciskajc klawisze telefonu (For English, press 1).
69
R OZDZIA 3.
K IEDY MWI TAK
Nasz recepcjonista odbiera telefon i prosi o wprowadzenie nazwiska osoby, z ktr chcesz
rozmawia. Prosi te o podanie swojego nazwiska i przystpowa do realizacji poczenia.
Najpierw jednak zapowiada w firmie dane poczenie i pyta, czy ma ono zosta odebrane.
Jeeli otrzyma potwierdzenie, to posusznie czy i si wycofywa.
Naszemu recepcjonicie mona byo powiedzie, gdzie si jest. Mona mu byo poda kilka
numerw, z ktrymi ma prbowa si czy. Dziki temu nawet jeeli byo si w innym
biurze, to recepcjonista i tak mg ci znale. Podobnie jeeli byo si w domu albo w innym
miecie. Jeeli jednak mimo tych wszystkich zabiegw ER nie mg ci dopa, to pozwala
na pozostawienie wiadomoci. To wanie tutaj pojawia si poczta gosowa.
Co ciekawe, firma Teradyne nie bya w stanie wymyli sposobu na skuteczn sprzeda ER.
Projekt przekroczy budet i zosta wczony do czego, co umielimy dobrze sprzedawa
CDS, czyli Craft Dispatch System, ktry suy do przydzielania zada serwisantom linii
telefonicznych. Poza tym Teradyne wycofaa wniosek patentowy, nawet nas o tym nie
informujc (!). Aktualny waciciel patentu zoy wniosek trzy miesice po nas (!!)1.
Dugo po tym, jak system ER zosta wczony do CDS, ale te na dugo, zanim dowiedziaem
si o wycofaniu wniosku patentowego, czekaem na naszego prezesa, siedzc na drzewie.
Przed budynkiem firmy rs ogromny stary db, na ktry si wspiem, i czekaem na
przyjazd jaguara. Prezesa w kocu spotkaem przed drzwiami firmy i zapytaem, czy ma
dla mnie kilka minut. Zaprosi mnie do biura.
Powiedziaem mu, e naprawd musimy ponownie uruchomi projekt ER, poniewa
jestem pewien, e przyniesie on nam spore pienidze. Zaskoczy mnie, mwic: Dobrze,
Bob. Przygotuj jaki plan i poka mi, jak na tym zarobi. Jeeli zdoasz mnie przekona,
to ponownie uruchomi projekt.
Tego si zupenie nie spodziewaem. Zakadaem, e usysz co w rodzaju: Masz racj,
Bob. Zaraz zreanimuj cay projekt i postaram si wykombinowa, jak na tym zarobi.
Ale nie. Cay ten ciar zrzuci na moje barki. Na dodatek miaem do tego wszystkiego
do ambiwalentny stosunek. W kocu byem tylko programist, a nie marketingowcem.
Chciaem pracowa nad projektem ER, a nie przejmowa odpowiedzialno za zyski lub
straty. Nie chciaem jednak okazywa swoich uczu. Podzikowaem mu zatem i wyszedem
z biura, mwic:
Dziki, Russ. Chyba si tego podejm.
W tym momencie pozwl, e zapoznam Ci z Royem Osherovem, ktry powie Ci,
jak aosna bya moja odpowied.
Nie chodzi o to, e ten patent mia dla mnie znaczenie finansowe. Zgodnie z umow o prac
sprzedaem go firmie Teradyne za jednego dolara (ale go nie dostaem).
70
J ZYK ZOBOWIZA
Jzyk zobowiza
Autor: Roy Osherove.
Powiedz. Zamierzaj. Zrb.

Oto trzy elementy niezbdne do podjcia zobowizania:
1. Mwisz, e to zrobisz.
2. Zamierzasz to zrobi.
3. Faktycznie to robisz.
Jednak czsto spotykamy ludzi (to oczywicie nie my), ktrzy nigdy nie s w stanie przej
przez wszystkie trzy etapy.
Zapytaj gocia od IT, dlaczego sie dziaa tak wolno, a odpowie: No tak, zdecydowanie
potrzeba nam nowych routerw. I ju wiesz, e w tej materii nic si nigdy nie zmieni.
Zapytaj czonka swojego zespou, czy przeprowadzi rcznie testy, zanim wprowadzi
kod do repozytorium, a odpowie: No pewnie. Mam nadziej, e skocz to jeszcze

dzisiaj. I jako tak czujesz, e jutro trzeba bdzie spyta, czy przed wrzuceniem kodu
do repozytorium wykona jakiekolwiek testy.
Twj szef wchodzi do pokoju i mamrocze: Musimy dziaa szybciej. A Ty wiesz, e tak
naprawd chodzi mu o to, e to TY masz dziaa szybciej. On nie ma zamiaru si z tego

powodu przemcza.
Jest niewiele osb, ktre mwic o czym, zamierzaj to zrobi, a potem rzeczywicie
zabieraj si do roboty. S te tacy ludzie, ktrzy mwic o czym, rzeczywicie zamierzaj
si tym zaj, ale w kocu i tak nic nie robi. Ale najwicej jest osb obiecujcych rne
rzeczy, ktre tak naprawd nawet nie zamierzaj si nimi zaj. Zdarzyo Ci si sysze:
Rany, naprawd musz zacz si odchudza i wiedzie, e ta osoba nigdy nic z tym nie
zrobi? Takie rzeczy dziej si cay czas.
Dlaczego cigle towarzyszy nam to dziwne uczucie, e ludzie raczej nie s zaangaowani
w realizacj swoich planw?
Co gorsza, czsto moe nas zawodzi nasza wasna intuicja. Czasami chcemy uwierzy,
e kto naprawd zamierza zrobi to, o czym opowiada, mimo e tak naprawd tylko
opowiada. Chcemy wierzy programicie, ktry zapdzony w kozi rg, twierdzi, e zadanie
zaplanowane na dwa tygodnie skoczy w cigu jednego tygodnia. Mimo wszystko nie
powinnimy dawa takim zapewnieniom wiary.
Zamiast ufa instynktom, powinnimy stosowa pewne sztuczki jzykowe, aby sprawdzi,
czy rozmwca rzeczywicie zamierza zrobi to, o czym opowiada. A zmieniajc sposb
71
R OZDZIA 3.
K IEDY MWI TAK
mwienia, moemy zaj si 1. i 2. punktem z powyszej listy. Kiedy mwimy, e si czego

podejmiemy, i rzeczywicie zamierzamy to zrobi.
Rozpoznawanie braku zaangaowania

Naley zwraca uwag na jzyk uywany podczas podejmowania si jakiego zadania,
poniewa moe on zdradza zakoczenie tej historii. Szczeglnie chodzi tu o szukanie
okrelonych sw, ktre s wypowiadane. Jeeli nie jestemy w stanie znale tych maych
magicznych swek, to jest cakiem moliwe, e nie angaujemy si w to, o czym mwimy,
albo nie wierzymy, e realizacja jest moliwa.
Oto kilka przykadw sw i wyrae, na ktre trzeba zwraca uwag, poniewa mog
by zwiastunami braku zaangaowania:
Trzeba by / Musiaby. Trzeba by si tym zaj. Musiabym zrzuci par kilo.
Kto musiaby si tym zaj.

Mam nadziej / Dobrze by byo. Mam nadziej zrobi to na jutro. Mam nadziej,
e si jeszcze spotkamy. Dobrze by byo znale na to czas. Dobrze by byo mie

szybszy komputer.
Powinnimy (bez cigu dalszego zawierajcego ja). Powinnimy si od czasu
do czasu spotyka. Powinnimy to skoczy.

Wystarczy zacz szuka tych sw, a okae si, e znajdujesz je w niemal wszystkich
wysuchanych wypowiedziach, a nawet w tym, co mwisz innym.
Zauwaysz, e bardzo si staramy, aby nie przyj na siebie odpowiedzialnoci za cokolwiek.
A to nie jest w porzdku, jeeli Ty lub ktokolwiek inny jestecie uzalenieni w swojej
pracy od takich obietnic. Pierwszy krok zosta ju zrobiony. Umiesz ju wykrywa brak
zobowizania w otoczeniu i w sobie.
Wiemy ju, jak brzmi brak zaangaowania. Jak jednak rozpozna prawdziwe zaangaowanie?
Jak brzmi zaangaowanie?

Elementem wsplnym wszystkich wyrae przedstawionych powyej jest zaoenie, e te
sprawy nie le w mojej gestii albo odpowiedzialno za nie nie dotyczy mnie osobicie.
W kadym z tych przypadkw ludzie zachowuj si tak, jakby byli ofiarami danej sytuacji,
a nie jej panami.
Prawda jest jednak taka, e Ty osobicie ZAWSZE masz co pod swoim panowaniem,
a zatem zawsze bdzie co, do czego moesz si cakowicie zobowiza.
72
J ZYK ZOBOWIZA
Skadnikami pozwalajcymi na rozpoznanie prawdziwego zaangaowania s zdania

brzmice mniej wicej tak: Ja () do (), na przykad: Ja to zrobi do wtorku.
Co jest takiego wanego w tym zdaniu? To, e podajesz w nim informacj o czym, co TY
zrobisz w okrelonym przez Ciebie czasie. Nie mwisz tu o nikim innym, tylko o sobie.
Mwisz tu o konkretnym dziaaniu, ktrego si podejmujesz. Nie chyba to zrobisz albo
moe si tym zajmiesz. Ty to na pewno zrobisz.
Nie istnieje adna metoda wykrcenia si z takiego zobowizania. Mwisz, e to zrobisz,
i teraz moliwy jest jeden z dwch wynikw albo to zrobisz, albo nie. Jeeli nie osigniesz
zamierzonego celu, to ludzie mog pocign Ci do odpowiedzialnoci. Nie bdziesz si
z tego powodu dobrze czu. Poczujesz si niezrcznie, mwic komu, e nie udao Ci si
tego zrobi (jeeli ten kto sysza wczeniej Twoj obietnic).
Przeraajce.
Przyjmujesz na siebie pen odpowiedzialno za co i robisz to przed pewn grup ludzi,
a przynajmniej przed jedn osob. To nie to samo co gadanie do siebie przed lustrem
albo przed ekranem komputera. Tym razem to Ty stoisz przed inn osob i twierdzisz,
e wykonasz to zadanie. To si nazywa pocztek zobowizania. Stawiasz si w sytuacji,
ktra zmusza Ci do podjcia dziaania.
Zmieniasz stosowany przez siebie jzyk na jzyk zobowiza, co pomaga w przejciu
kolejnych dwch etapw: zamierze i realizacji.
Istnieje jednak wiele powodw, dla ktrych moesz tak naprawd nie zamierza nic robi
albo cakiem pomin realizacj, ale i na to mona znale rozwizanie.
Nie udao si, poniewa osoba X nie wywizaa si ze swoich zobowiza

Zobowiza mona si jedynie do tych rzeczy, ktre ma si pod cakowit kontrol.
Na przykad jeeli Twoim celem jest zakoczenie prac nad moduem, ktre uzalenione
s od wsppracy z innym zespoem, to nie moesz zobowiza si do ukoczenia moduu
i integracji z tym innym zespoem. Moesz jednak zobowiza si do wykonania okrelonych
dziaa, ktre przybli Ci do tego celu. Moesz:
Posiedzie godzin z Grzegorzem z zespou infrastruktury, eby pozna wszystkie
zalenoci.
Przygotowa interfejs odzwierciedlajcy zalenoci Twojego moduu od infrastruktury
innego zespou.
Spotyka si przynajmniej trzy razy w tygodniu z nadzorc kompilacji, aby si upewni,
e Twoje zmiany dobrze komponuj si w firmowym systemie kompilacji.

Przygotowa swoj osobist kompilacj, ktra bdzie uruchamiaa testy integracyjne
tworzonego moduu.
73
R OZDZIA 3.
K IEDY MWI TAK
Widzisz rnic?
Jeeli rezultat jest uzaleniony od kogo innego, to lepiej zobowizywa si do konkretnych
dziaa, ktre przybliaj Ci do ostatecznego celu.
Nie udao si, poniewa wcale nie byo pewne, e to si da zrobi

Jeeli czego nie da si zrobi, to mimo wszystko moesz zobowiza si do wykonania
dziaa przybliajcych Ci do celu. Jednym z tych dziaa moe by nawet sprawdzenie,
czy dana operacja jest w ogle wykonalna.
Zamiast zobowizywa si do poprawienia wszystkich 25 bdw przed oficjalnym wydaniem
oprogramowania (co moe nie by moliwe), moesz zobowiza si do poniszych dziaa,
ktre z pewnoci przybli Ci do ostatecznego celu:
Przejrze wszystkie 25 bdw i sprbowa je odtworzy.
Posiedzie z testerami, ktrzy znaleli te bdy, eby zobaczy, jak udao im si je wywoa.
Powici w tym tygodniu cay dostpny czas na prby naprawienia poszczeglnych
bdw.
Nie dao si tego zrobi, bo czasami po prostu nie nadam

To te si zdarza. Czasami dziej si rzeczy nieoczekiwane; takie jest ycie. Ale mimo to
chcemy sprosta oczekiwaniom. W takim wypadku naley zmienia te oczekiwania tak
wczenie, jak tylko jest to moliwe.
Jeeli nie jeste w stanie dotrzyma zobowizania, to najwaniejsze jest jak najwczeniejsze
podniesienie czerwonej flagi.
Im wczeniej wskaesz problem udziaowcom, tym wicej czasu bdzie mia zesp na to,
eby zatrzyma si i ponownie oceni wszystkie podejmowane dziaania, a nastpnie
zdecydowa, czy cokolwiek mona zrobi lub zmieni (na przykad priorytety). W ten
sposb moesz jeszcze dotrzyma swojego zobowizania albo je zmieni, dopasowujc
do nowych warunkw.
Oto kilka przykadw:
Jeeli zaplanujesz poudniowe spotkanie z koleg w kawiarni w centrum miasta, ale utkniesz
w korku, to moesz przypuszcza, e nie uda Ci si dotrze do kawiarni na czas. Moesz

zatem zadzwoni do kolegi odpowiednio wczeniej i poinformowa go o zaistniaej
sytuacji. By moe uda si Wam znale blisze miejsce na spotkanie albo po prostu
je przesuniecie.
Jeeli zobowiesz si do poprawienia bdu, ktry pocztkowo wyglda cakiem
niegronie, ale potem okazuje si, e jest znacznie bardziej zoony i kopotliwy, to moesz
74
N AUCZ SI , JAK MWI TAK
od razu podnie czerwon flag. Zesp moe wtedy podj decyzj o dziaaniach
koniecznych do wykonania tego zobowizania (dziaanie w parze, burza mzgw lub
inne) albo po prostu zmieni priorytety i przenie Ci do prac nad innym bdem.
W tym wszystkim wane jest to, e jeeli nie powiesz nikomu o zaistniaym problemie,
to nie dasz nikomu szansy na udzielenie Ci pomocy niezbdnej do wywizania si ze
zobowizania.
Podsumowanie
Wytworzenie jzyka zobowiza moe wydawa si przeraajce, ale pomaga to
rozwizywa wiele problemw z komunikacj, z ktrymi programici stykaj si kadego
dnia niewaciwymi szacunkami, niedopasowanymi terminami i nieporozumieniami
w bezporedniej komunikacji. Dziki temu jzykowi bd Ci traktowa jak powanego
zawodowca, ktry zawsze dotrzymuje danego sowa. A to chyba najlepsza reputacja,
jak mona mie.
~~~
Naucz si, jak mwi tak

Poprosiem Roya o pozwolenie na opublikowanie tego artykuu, poniewa udao mu si we
mnie co poruszy. Cay czas nauczaem o tym, w jaki sposb naley odmawia. Ale rwnie
wane jest to, eby nauczy si mwi tak.
Druga strona prbowania

Wyobramy sobie, e Peter jest odpowiedzialny za pewne modyfikacje w systemie ocen.
Oszacowa on, e niezbdne poprawki zajm mu pi do szeciu dni. Oprcz tego twierdzi,
e na napisanie dokumentacji wszystkich tych zmian bdzie potrzebowa kilku godzin.
W poniedziaek rano jego meneder Marge pyta o stan prac.
Marge: Peter, uda ci si skoczy poprawki w systemie ocen do pitku?.
Peter: To si chyba da zrobi.
Marge: Same poprawki kodu czy ju z dokumentacj?.
Peter: Mog sprbowa zdy z dokumentacj.
By moe Marge nie syszy niezdecydowania w potwierdzeniach Petera, ale on na pewno
nie definiuje tu twardych zobowiza. Marge oczekuje na swoje pytania potwierdzenia lub
zaprzeczenia, podczas gdy wypowiedzi Petera s raczej niejasne.
75
R OZDZIA 3.
K IEDY MWI TAK
Zauwa naduycie sowa prbowa. W poprzednim rozdziale podaem definicj tego

sowa oznaczajc dodatkowy nakad pracy. W tym przypadku Peter stosuje definicj
moe, a moe nie.
Zdecydowanie lepiej byoby, gdyby Peter odpowiada tak:
Marge: Peter, uda ci si skoczy poprawki w systemie ocen do pitku?.
Peter: Prawdopodobnie, ale moe si to przecign do poniedziaku.
Marge: Same poprawki kodu czy ju z dokumentacj?.
Peter: Na dokumentacj potrzebuj dodatkowych kilku godzin, dlatego jest szansa,
e bdzie gotowa w poniedziaek, ale nie wykluczam, e prace przecign si
do wtorku.
W tym przypadku wypowiedzi Petera s bardziej szczere. Opisuje przed Marge swoj
niepewno. Dziki temu Marge moe t niepewno uwzgldni w swoich planach.
Cho wcale nie musi.
Dyscyplina zobowiza
Marge: Peter, potrzebuj tutaj jasnej odpowiedzi. Czy do pitku uda ci si wprowadzi
wszystkie zmiany do systemu ocen i napisa do nich dokumentacj?.
Nic nie stoi na przeszkodzie, eby Marge swoje pytanie sformuowaa w ten sposb. Musi
pilnowa planu, dlatego potrzebuje jasnej odpowiedzi na temat zakoczenia prac w pitek.
Jak powinien odpowiedzie Peter?
Peter: W takiej sytuacji musz odpowiedzie: nie. Jestem pewien, e zmiany
i dokumentacj bd mia gotowe najpniej we wtorek.
Marge: Czyli mog zapisa wtorek jako koniec prac?.
Peter: Owszem, na wtorek wszystko bdzie gotowe.
Co jednak, jeeli Marge bdzie potrzebowaa wprowadzenia zmian i dokumentacji ju
w pitek?
Marge: Peter, ten wtorek to dla mnie prawdziwy problem. Willy z dokumentacji
technicznej bdzie wolny ju w poniedziaek. Zaplanowa ju pi dni na
przygotowanie instrukcji dla uytkownika. Jeeli w poniedziaek nie bd
miaa gotowej dokumentacji systemu ocen, to nie uda mu si na czas napisa
instrukcji. Czy moesz najpierw napisa dokumentacj?.
Peter: Nie bardzo. Najpierw musz wprowadzi modyfikacje w systemie, poniewa
dokumentacja jest generowana na podstawie wynikw naszych testw.
76
N AUCZ SI , JAK MWI TAK
Marge: Nie ma jakiego sposobu, eby udao ci si skoczy modyfikacje i dokumentacj

przed poniedziakiem rano?.
Teraz to Peter musi podj decyzj. Istnieje pewna szansa, e zdy wprowadzi zmiany do
systemu ocen ju w pitek, a przed pjciem do domu na weekend moe nawet uda mu si
przygotowa dokumentacj. Mgby te popracowa kilka godzin w sobot, jeeli cao
zajaby wicej czasu, ni zakada. Co zatem powiedzie Marge?
Peter: Noooo, jest szansa, e zd wszystko przygotowa na poniedziaek rano,
jeeli zrobibym kilka nadgodzin w sobot.
Czy to rozwizuje problem Marge? Nie, to tylko zwiksza prawdopodobiestwo sukcesu,
i to wanie powinien powiedzie jej Peter.
Marge: Czy mog zatem liczy na poniedziaek rano?.
Peter: Moliwe, cho nie mam cakowitej pewnoci.
Dla Marge to moe by za mao.
Marge: Peter, naprawd potrzebuj tu konkretw. Czy istnieje jakikolwiek sposb
na to, eby ze wszystkim zdy na poniedziaek rano?.
Petera moe kusi, eby w tym miejscu porzuci swoj dyscyplin. By moe udaoby si
mu przygotowa wszystko szybciej, jeeli pominby pisanie testw. By moe udaoby
si mu wykona zadania wczeniej, jeeli zapomniaby o refaktoryzacji kodu. By moe
wszystko poszoby szybciej, jeeli nie przeprowadziby wszystkich testw regresyjnych.
To wanie w tym miejscu zawodowcy krel grub kresk. Po pierwsze Peter myli si we
wszystkich tych przypuszczeniach. Nie zrobi nic szybciej, jeeli pominie pisanie testw.
Pominicie refaktoryzacji kodu nie przyspieszy prac. Nie skrci czasu pracy, jeeli odpuci
sobie pene testy regresyjne. Lata dowiadcze nauczyy go tego, e porzucenie normalnej
dyscypliny tylko nas spowalnia.
Po drugie jako profesjonalista jest zobowizany do zachowania pewnych standardw.
Jego kod musi by przetestowany, czyli musi mie napisane testy. Jego kod musi by czysty.
A na dodatek Peter musi mie pewno, e nie zepsu niczego w istniejcym systemie.
Peter jako zawodowiec ju wczeniej zobowiza si do zachowania tych standardw.
Wszystkie pozostae zobowizania musz si zatem do tych standardw dopasowywa.
Dlatego wanie caa ta linia rozumowania musi zosta w tym miejscu przerwana.
Peter: Przykro mi, ale nie ma sposobu na to, ebym z ca pewnoci mg zakoczy
w terminie krtszym ni do wtorku. Przykro mi, e to psuje twj plan, ale taka
jest rzeczywisto. Nic na to nie poradz.
77
R OZDZIA 3.
K IEDY MWI TAK
Marge: Cholera. A tak chciaam wczeniej skreli ten punkt z listy. Jeste pewny?.
Peter: Jestem absolutnie pewny, e cao moe si przecign do wtorkowego
popoudnia.
Marge: OK, chyba musz pogada z Willym, czy nie przestawi swojego planu.
W tym przypadku Marge zaakceptowaa odpowied Petera i zacza szuka innych rozwiza.
Ale co bdzie, jeeli Marge nie ma ju adnego asa w rkawie? Co zrobi, jeeli Peter jest jej
ostatni nadziej?
Marge: Peter, prosz. Wiem, e to spora proba, ale naprawd te prace musz by
zakoczone przed poniedziakiem rano. Mam n na gardle. Na pewno nie
da si nic poradzi?.
Teraz Peter zaczyna myle o zrobieniu caej grki nadgodzin i powiceniu na to zadanie
sporej czci weekendu. Musi jednak zdawa sobie spraw z wasnej wytrzymaoci
i rezerw energii. atwo mona powiedzie, e wszystko zostanie zrobione w cigu
weekendu, ale realizacja tych prac jest znacznie trudniejsza i wymaga dodatkowych
nakadw, aby zachowana bya odpowiednia jako pracy.
Profesjonalici znaj granice swoich moliwoci. Wiedz, ile nadgodzin mog skutecznie
przepracowa, i zdaj sobie spraw, jakie bd ich koszta.
W tym przypadku Peter czuje si na tyle pewnie, e kilka dodatkowych godzin w cigu
tygodnia i jeszcze par w trakcie weekendu wystarczy do zakoczenia prac.
Peter: Dobra, powiem ci co. Zadzwoni do domu i zapytam, czy znios troch moich
nadgodzin. Jeeli nie bdzie protestw, to zrobi te poprawki do poniedziaku
rano. Nawet w poniedziaek przyjd wczeniej, by si upewni, e Willy nie
bdzie mia problemw. Ale potem wrc do domu i nie pojawi si a do rody.
Zgoda?.
Bardzo rozsdna propozycja. Peter wie, e bdzie w stanie wprowadzi wszystkie zmiany
i napisa ich dokumentacj, jeeli zrobi kilka nadgodzin. Wie te, e po tym wszystkim
przez par dni nie bdzie si do niczego nadawa.
Wnioski
Zawodowcy wcale nie musz si zgadza na wszystko, co si im proponuje. Powinni jednak
bardzo si stara, szukajc wszelkich moliwoci znalezienia zadowalajcego wszystkich
rozwizania. Jeeli jednak profesjonalista mwi tak, to uywa przy tym jzyka zobowiza,
tak eby nie byo adnych wtpliwoci co do zakresu danej obietnicy.
78
K ODOWANIE
W poprzedniej ksice1 napisaem cakiem sporo o strukturze i naturze czystego kodu.

W tym rozdziale bd omawia sam akt tworzenia kodu oraz kontekst otaczajcy ten akt.
Gdy miaem 18 lat, cakiem niele szo mi pisanie na klawiaturze, ale nadal musiaem
patrze na klawisze. Nie byem w stanie pisa bezwzrokowo. Ktrego wieczoru spdziem
kilka godzin nad klawiatur komputera IBM 029, starajc si nie patrze na swoje palce
w czasie, gdy wpisywaem program, ktry zapisaem na kilku formularzach. Po zakoczeniu
wprowadzania sprawdziem kad kart z osobna i wyrzuciem te, ktre zawieray bdy.
1
[Martin09].
79
R OZDZIA 4.
K ODOWANIE
Pocztkowo zdarzao mi si cakiem sporo bdw, ale pod wieczr mogem zapisywa
karty niemal perfekcyjnie. W cigu dugiej nocy przekonaem si, e pisanie bezwzrokowe
wymaga przede wszystkim pewnoci siebie. Moje palce wiedziay, gdzie s poszczeglne
klawisze, i musiaem tylko zyska pewno, e nie popeniam bdw. Jedn z rzeczy, ktre
mi bardzo przy tym pomogy, byo to, e dokadnie czuem, kiedy popeniam bd. Pod
wieczr od razu wiedziaem, kiedy popeniem bd, i mogem zaraz wyrzuci kart bez
patrzenia na ni.
Umiejtno wyczuwania wasnych bdw jest niezwykle wana. Nie tylko podczas pisania
na klawiaturze, ale w kadym elemencie. Ten dodatkowy zmys oznacza, e bardzo szybko
zamykasz ptl sprzenia zwrotnego i jeszcze szybciej jeste w stanie uczy si na swoich
bdach. Od czasu tego dnia spdzonego nad klawiatur dwudziestki dziewitki wiele si
nauczyem i pogbiem swoj wiedz. Za kadym razem przekonywaem si, e kluczem
do sukcesu s pewno siebie i umiejtno wyczuwania bdw.
W tym rozdziale opisz mj osobisty zbir zasad i regu dotyczcych tworzenia kodu.
Te reguy i zasady nie odnosz si do samego kodu, ale raczej do mojego zachowania,
nastawienia i humoru podczas jego pisania. Opisuj mj mentalny, moralny i emocjonalny
kontekst pisania kodu. To wanie one s podstaw mojej pewnoci siebie i umiejtnoci
wyczuwania bdw.
Z pewnoci nie zgodzisz si ze wszystkim, co tutaj napisz, to w kocu sprawy bardzo
osobiste. Co wicej, cakiem prawdopodobne jest, e gwatownie zaoponujesz przeciwko
niektrym moim zasadom. To zupenie normalne. Nie maj by one prawdami absolutnymi
dla nikogo poza mn. S tylko moj wasn metod profesjonalnego tworzenia kodu.
By moe analizujc moje rodowisko tworzenia kodu, bdziesz w stanie lepiej zrozumie
ca zawarto tej ksiki.
Przygotowanie
Tworzenie kodu jest bardzo wyczerpujc czynnoci i ogromnym wyzwaniem
intelektualnym. Wymaga ono osignicia pewnego poziomu koncentracji i skupienia,
niezbdnego tylko w kilku innych dziedzinach. Wynika to z tego, e tworzenie kodu
wymaga od programisty onglowania wieloma sprzecznymi zasadami.
1. Twj kod musi dziaa. Musisz pozna problem, ktry masz rozwiza, i zdefiniowa
sposb jego rozwizania. Musisz mie pewno, e napisany przez Ciebie kod bdzie
wiernym odwzorowaniem tego rozwizania. Musisz zadba o kady szczeg tego
rozwizania, pozostajc w zgodzie z jzykiem programowania, platform, uywan
architektur oraz kruczkami systemu.
2. Kod musi rozwizywa problem zdefiniowany przez klienta. Czsto jest tak,
e wymagania okrelone przez klienta wcale nie rozwizuj jego problemw.
80
P RZYGOTOWANIE
Twoim zadaniem jest wychwycenie tych rozbienoci i takie prowadzenie

negocjacji z klientem, eby zostay zaspokojone jego rzeczywiste potrzeby.
3. Twj kod musi dopasowa si do istniejcego systemu. Nie powinien zwiksza jego
sztywnoci, delikatnoci ani nieprzejrzystoci. Wszystkie zalenoci musz pozosta
pod kontrol. W skrcie: Twj kod musi by zgodny z podstawowymi zasadami
inynierii2.
4. Twj kod musi by czytelny dla pozostaych programistw. I nie chodzi tu tylko
o pisanie odpowiednich komentarzy, a raczej o takie uksztatowanie kodu, eby sam
ujawnia Twoje zamiary. To jest najtrudniejsze. Wydaje si, e dla programisty wanie
to moe by najtrudniejsze do opanowania.
onglowanie tymi wszystkimi zasadami moe by naprawd trudne. Ju samo fizjologiczne
utrzymywanie niezbdnego skupienia przez duszy czas jest nieatwe. Dodaj do tego cay
zbir problemw i elementw rozpraszajcych wynikajcych z pracy w zespole, w wikszej
organizacji, nie wspominajc nawet o typowych rozterkach codziennego ycia. Chodzi o to,
e na kadym rogu czai si co, co moe zmniejszy Twoje skupienie.
Jeeli nie moesz si odpowiednio skoncentrowa i skupi, to z pewnoci napisany przez
Ciebie kod bdzie nieprawidowy. Bdzie zawiera bdy. Bdzie mia nieodpowiedni
struktur. Bdzie nieprzejrzysty i zagmatwany. Nie bdzie rozwizywa problemw klienta.
Oznacza to, e bdzie musia zosta przebudowany i napisany na nowo. Praca bez skupienia
tworzy tylko mieci.
Jeeli jeste zmczony lub brakuje Ci skupienia, to nie twrz kodu. Ostatecznie staniesz
przed koniecznoci ponownego wykonania tej samej pracy. Lepiej bdzie od razu
wyeliminowa elementy rozpraszajce i uspokoi swj umys.
Kod z godziny 3 nad ranem

Najgorszy kod w yciu napisaem o godzinie 3 nad ranem. Byo to w roku 1988, kiedy
to pracowaem dla modej firmy telekomunikacyjnej o nazwie Clear Communications.
Wszyscy w firmie pracowalimy przez dugie godziny, eby wytworzy kapita
(ang. sweat equity). Oczywicie wszyscy marzylimy o bogactwie.
Pewnego bardzo pnego wieczoru (a moe raczej bardzo wczesnego ranka) w ramach
rozwizywania problemu czasowego nakazaem swojemu kodowi wysya do samego siebie
komunikat poprzez system rozprowadzania zdarze (nazywalimy to wysyaniem poczty).
To byo bardzo niewaciwe rozwizanie, ale o 3 nad ranem wygldao bardzo obiecujco.
Co wicej, po 18 godzinach tworzenia kodu (nie wspominajc o 60 70 godzinach pracy
w tygodniu) na nic wicej nie byo mnie sta.
[PPP2002].
81
R OZDZIA 4.
K ODOWANIE
Pamitam, e byem dumny z tego, e tak dugo pracowaem. Pamitam, e czuem swoje
powicenie. Pamitam te, e sdziem, i zawodowcy zawsze pracuj do 3 nad ranem.
Oj, jak bardzo si myliem!
Tamten kod kopn nas jeszcze wielokrotnie. Zdefiniowaem wadliw struktur, z ktrej
korzystali wszyscy, ale jednoczenie zmuszeni byli tworzy cige obejcia. Wytworzya ona
najdziwniejsze problemy czasowe i niezwyke ptle sprzenia zwrotnego. Wpadalimy
w nieskoczone ptle wiadomoci, gdy jeden komunikat powodowa wysanie innego
i jeszcze kolejnego, ad infinitum. Nigdy nie mielimy czasu na napisanie na nowo fragmentw
powodujcych te problemy (a przynajmniej tak si nam wydawao), ale zawsze znajdowalimy
czas na utworzenie kolejnej atki i poprawki obchodzcych wykrywane problemy. Cao
cigle rosa, opakowujc ten kod napisany o 3 nad ranem w coraz wikszy baga efektw
ubocznych. Pniej stao si to podstaw artw w zespole. Za kadym razem, gdy byem
zmczony lub sfrustrowany, mwili do siebie: Patrzcie! Bob zaraz wyle do siebie maila!.
Mora tej historii jest taki: nie pisz kodu, jeeli jeste zmczony. Powicenie i profesjonalizm
s bardziej zwizane z odpowiedni dyscyplin, a nie z godzinami pracy. Upewnij si, e Twj
styl ycia, zdrowie i dawka snu s wystarczajce, eby pracy powici osiem dobrych godzin.
Kod ze zmartwieniami
Czy kiedykolwiek zdarzyo Ci si ostro pokci ze wspmaonkiem lub przyjacielem,
a zaraz potem przystpi do pisania kodu? Pamitasz zapewne, e gdzie z tyu Twojej gowy
trwa may proces, ktry stara si ponownie analizowa przebieg ktni. Stres generowany
przez ten may proces mona czasami poczu w klatce piersiowej lub w odku. Sprawia to,
e czujesz niepokj jak po wypiciu zbyt wielu kaw lub coli. To bardzo rozprasza.
Jeeli martwi si ktni ze swoj on albo problemami z klientem albo chorym dzieckiem,
to nie jestem w stanie si odpowiednio skupi. Moja koncentracja cay czas odpywa.
Okazuje si, e mimo oczu skierowanych na ekran, a palcw lecych na klawiaturze nie
jestem w stanie nic zrobi. Katatonia. Parali. Jestem tysic kilometrw std, analizujc
palcy mnie problem, a nie zastanawiajc si nad tworzonym kodem.
Czasami zmuszam si do mylenia na temat kodu. W ten sposb jestem w stanie dopisa
wiersz lub dwa. Mog zmusi si do napisania jednego testu lub dwch, ale nie jestem w stanie
duej koncentrowa si na pracy. Ostatecznie zawsze popadam w to niezwyke odrtwienie,
w ktrym nie widz nic mimo otwartych oczu i przetwarzam moje najrniejsze troski.
Nauczyem si ju, e nie jest to dobry czas na tworzenie kodu. Kady kod, ktry w tym
czasie napisz, bd mg wyrzuci do kosza. Dlatego wanie zamiast pisa, staram si
rozwizywa problemy powodujce zmartwienia.
Oczywicie istnieje wiele trosk, ktrych nie da si usun z godziny na godzin. Co wicej,
nasz pracodawca raczej nie bdzie chtnie tolerowa naszej bezczynnoci, w czasie gdy
82
S TREFA
bdziemy stara si rozwizywa prywatne problemy. Sztuczka polega zatem na tym, eby
nauczy si zamyka ten dziaajcy w tle proces, a przynajmniej zmniejsza jego priorytet,
tak aby nie stawa si on nieustajcym elementem rozpraszajcym.
Sam robi to, odpowiednio dzielc swj czas. Zamiast zmusza si do pisania kodu z cigle
atakujcymi mnie mylami, powicam im pewien wybrany wycinek czasu moe nawet
godzin starajc si pracowa nad powodem mojego niepokoju. Jeeli moje dziecko
jest chore, to dzwoni do domu, aby dowiedzie si, czy wszystko jest w porzdku. Jeeli
pokciem si z on, to dzwoni do niej i staram si obgada powd tej ktni. Jeeli
mam problemy finansowe, to myl nad tym, jak sobie z nimi poradzi. Wiem, e
najprawdopodobniej nie uda mi si rozwiza problemu w czasie tej godziny, ale jest
bardzo moliwe, e zmniejsz w ten sposb swoje napicie i ucisz dziaajcy w tle proces.
Najlepiej byoby, gdyby czas powicony na walk z osobistymi problemami by Twoim
czasem prywatnym. Spdzenie w ten sposb godziny w pracy byoby niewaciwe. Zawodowi
programici wykorzystuj swj prywatny czas tak, eby czas spdzony w biurze by jak
najbardziej produktywny. Oznacza to, e jeszcze w domu naley powici troch czasu
na zmniejszenie wewntrznych niepokojw, tak aby nie przynosi ich ze sob do biura.
Jednak jeeli jeste ju w pracy, a wewntrzne niepokoje nie pozwalaj pracowa z pen
skutecznoci, to moe lepiej powici godzin na ich uspokojenie, ni zmusza si do pisania
kodu, ktry pniej i tak bdzie trzeba napisa od nowa. Albo co gorsza dalej z nim y.
Strefa
Wiele ju napisano o tym stanie hiperproduktywnoci nazywanym przepywem (ang. flow).
Niektrzy programici nazywaj ten stan stref (ang. zone). Niezalenie od nazwy kady
z nas z pewnoci si ju z tym stanem zetkn. To stan wiadomoci z duym skupieniem
i widzeniem tunelowym, w ktry mog wej programici tworzcy kod. Wwczas czuj si
naprawd produktywni. To wanie wtedy czuj si cakowicie nieomylni. W efekcie staraj
si jak najduej pozostawa w tym stanie, a miar ich wartoci staje si spdzony w nim czas.
Oto maa rada od kogo, kto dokadnie przerobi ju ten temat: unikaj strefy. W tym stanie
wiadomoci tak naprawd nie jest si hiperproduktywnym, a ju na pewno nie jest si
nieomylnym. Tak naprawd jest to tylko pewien stan medytacyjny, w ktrym niektre
czynniki racjonalne zostaj umniejszone w celu uzyskania wikszej prdkoci pracy.
Musz tu wyrazi si jasno. Bdc w strefie, na pewno napiszesz wicej kodu. Jeeli stosujesz
praktyki TDD, to na pewno szybciej przejdziesz ptl czerwone zielone refaktoryzacja.
I dodatkowo poczujesz lekk eufori. Problem polega na tym, e bdc w strefie, stracisz
szerszy pogld na sprawy, przez co moesz podejmowa decyzje, ktre pniej bdzie
trzeba zmienia. Kod napisany w strefie na pewno powstaje szybciej, ale pniej trzeba
go czciej poprawia.
83
R OZDZIA 4.
K ODOWANIE
Aktualnie, gdy czuj, e sam zaczynam wpada w stref, na kilka minut odchodz od
komputera. Oczyszczam umys, odpisujc na kilka e-maili i czytajc kilka wiadomoci na
Tweeterze. Jeeli jest tu przed poudniem, to id na obiad. Jeeli pracuj w zespole, to id
poszuka sobie partnera.
Jedn z zalet programowania w parach jest to, e dla pary praktycznie niemoliwe jest
wejcie w stref. Jest to stan niekomunikatywny, podczas gdy programowanie w parach
wymaga cigej i intensywnej komunikacji. Co ciekawe, czsto sysz, e jedn z wad
programowania w parach jest to, e nie pozwala ono na wejcie w stref. O rany! Przecie
nikt nie powinien dy do tego, eby znale si w strefie.
To jednak nie do koca prawda. Czasami strefa jest miejscem, w ktrym chciaoby si
znale. Ale zdarza si to tylko podczas wicze. O tym opowiem jednak w innym rozdziale.
Muzyka
W latach 70. w firmie Teradyne miaem prywatne biuro. Byem wtedy administratorem
systemu na naszym PDP 11/60 i jako jeden z niewielu programistw dostaem swj wasny
terminal. Terminalem tym by VT100 podczony do PDP-11 za pomoc 25 metrw kabla
RS-232 dziaajcego z prdkoci 9600 bodw, ktry przypiem do sufitu swojego biura
i w ten sposb poprowadziem do pokoju komputerowego.
W biurze miaem zestaw stereo. Skada si ze starego gramofonu, wzmacniacza i sporych
gonikw. Miaem te du kolekcj pyt winylowych, w tym Led Zeppelin, Pink Floyd i
chyba ju wiesz, o co chodzi.
Czsto korzystaem z tego zestawu w czasie pisania kodu. Sdziem, e muzyka uatwiaa
mi koncentracj. Niestety, byem w bdzie.
Pewnego dnia musiaem wrci do moduu, ktry pisaem, suchajc sekwencji otwierajcej
The Wall. W komentarzach do kodu zobaczyem kawaki tekstu tego utworu, a take
wzmianki o bombowcach nurkujcych i paczcych dzieciach.
To wtedy zrozumiaem, e czytelnik mojego kodu dowie si z niego wicej o moich gustach
muzycznych ni o problemie, ktry ten kod ma rozwizywa.
Okazao si, e suchajc muzyki, wcale nie pisz lepszego kodu. Muzyka wcale nie pomaga
mi si skoncentrowa. Co wicej, suchanie muzyki zdaje si pochania cakiem spor
cz zasobw mojego umysu, ktrych potrzebuj do tworzenia czystego i dobrze
zaprojektowanego kodu.
By moe w Twoim przypadku dziaa to inaczej. By moe Tobie muzyka uatwia pisanie
kodu. Znam w kocu wiele osb, ktre pisz kod ze suchawkami na gowie. Jestem w stanie
zaakceptowa fakt, e muzyka uatwia im prac, ale mam dziwne podejrzenia, e tak naprawd
pomaga im ona wej do strefy.
84
B LOKADA TWRCZA
Przerwy
Wyobra sobie, e wanie tworzysz kod na swojej stacji roboczej. Jak odpowiadasz, gdy
kto zadaje Ci pytanie? Odpowiadasz niemio? Patrzysz gniewnie? Czy jzyk Twojego
ciaa informuje rozmwc, e ma si szybko oddali, bo masz inne zajcie? W skrcie:
czy zachowujesz si niegrzecznie? A moe przerywasz swoj prac i chtnie pomagasz
komu, kto wanie ma jaki problem? Czy traktujesz intruza tak jak w Twoim wyobraeniu
on powinien potraktowa Ciebie, gdy przyjdziesz z jakim problemem?
Takie niegrzeczne zachowania czsto wi si ze stref. Mog wynika z rozgoryczenia
powodowanego wycigniciem ze strefy albo przerwaniem prb wejcia do niej. W obu
przypadkach niegrzeczne zachowania s powizane ze stref.
Czasami jednak powodem wcale nie jest strefa, ale prosty fakt, e prbujesz zrozumie
co zoonego, co wymaga sporej koncentracji. W takim przypadku masz do wyboru kilka
rozwiza.
Dobr metod radzenia sobie z takimi przerwami moe by praca w parach. Twj partner
moe nadal pamita kontekst Waszych prac, podczas gdy Ty odbierasz telefon albo
odpowiadasz na pytania innego kolegi. Po powrocie partner szybko pomoe Ci odtworzy
stan umysu sprzed tej przerwy.
Doskona pomoc moe by te technika TDD. Jeeli masz niedziaajcy test, to z pewnoci
przechowuje on cay kontekst zadania, nad ktrym pracujesz. Po przerwie moesz atwo
wrci do pracy i sprawi, eby test zacz dziaa.
Oczywicie zawsze bd zdarzay si przerwy, ktre bd Ci rozpraszay i powodoway
straty czasu. Gdy co takiego si zdarzy, pamitaj, e nastpnym razem to Ty moesz
potrzebowa pomocy i bdziesz komu przerywa prac. Oznacza to, e do profesjonalnego
zachowania naley uprzejmo i ch udzielania pomocy.
Blokada twrcza
Czasami kod po prostu nie chce powsta. Zdarzyo mi si to kilka razy i wiele razy widziaem
taki stan u innych. Siedzi si wtedy przed komputerem i zupenie nic si nie dzieje.
Czsto znajdujesz wtedy jakie inne zajcie. Czytasz e-maile albo wiadomoci z Tweetera.
Przegldasz rne ksiki, dokumenty lub kalendarze. Zwoujesz zebranie albo zajmujesz
si rozmow ze wsppracownikami. Robisz wtedy cokolwiek, byle tylko nie siedzie przed
komputerem i nie patrze, jak kod uparcie nie chce si urodzi.
Co powoduje tak blokad? O wielu czynnikach wspominaem ju wczeniej. Dla mnie
jedn z najwaniejszych rzeczy jest sen. Jeeli si dobrze nie wypi, to najzwyczajniej
85
R OZDZIA 4.
K ODOWANIE
w wiecie nie jestem w stanie pisa kodu. Innymi podobnie dziaajcymi czynnikami mog
by strach, zmartwienia lub depresja.
Najdziwniejsze jest to, e istnieje dla tego problemu bardzo proste rozwizanie, ktre
sprawdza si niemal za kadym razem. Jest naprawd proste, a moe da Ci rozpd
wystarczajcy do napisania cakiem sporych iloci kodu.
Rozwizanie jest takie: znajd sobie partnera do programowania w parze.
To niesamowite, jak dobrze sprawdza si ta metoda. Gdy tylko usidziesz przy kim innym,
wszystkie problemy powodujce blokad same znikaj. Podczas pracy z inn osob nastpuje
zmiana fizjologiczna. Nie mam pojcia, na czym ona polega, ale za kadym razem czuj j
doskonale. W moim mzgu lub w moim ciele nastpuje zmiana chemiczna, ktra pozwala
mi si przebi przez blokad i wrci do normalnej pracy.
Nie jest to niestety rozwizanie doskonae. Czasami na zmian trzeba czeka godzin lub
dwie, po ktrych nastpuje tak powane zmczenie, e musz opuci swojego partnera
i znale jaki kcik, aby odpocz. Czasami nawet siedzc z kim przy komputerze, nie
jestem w stanie zrobi nic poza przytakiwaniem. Najczciej jednak moj typow reakcj
w takiej sytuacji jest odzyskanie swojego typowego rytmu.
Kreatywne wejcie
Istnieje jeszcze kilka innych rzeczy, ktre robi, eby zapobiega takim blokadom. Ju dawno
temu przekonaem si, e kreatywne wyjcie zaley od kreatywnego wejcia.
Sporo czytam, i to na wiele rnych tematw. Czytam teksty powicone oprogramowaniu,
polityce, biologii, astronomii, fizyce, chemii, matematyce i wielu innym zagadnieniom. Co
wicej, uwaam, e literatura science fiction najlepiej pobudza we mnie kreatywne wyjcie.
W Twoim przypadku elementem pobudzajcym moe by co cakiem innego. By moe
dobra powie detektywistyczna, poezja albo nawet romans. Jak sdz, chodzi tu o to, e
kreatywno tworzy kreatywno. Moe te chodzi o swego rodzaju ucieczk, eskapizm.
Godziny, ktre spdzam z dala od moich normalnych problemw, stymulujc si i wchaniajc
rne kreatywne idee, wywouj niemal nieodpart potrzeb samodzielnego tworzenia.
Nie dziaaj na mnie jednak wszystkie rodzaje kreatywnego wejcia. Na przykad zupenie
nie pomaga mi ogldanie telewizji. Wypad do kina dziaa lepiej, ale tylko troszk lepiej.
Suchanie muzyki nie pomaga mi w tworzeniu kodu, ale bardzo uatwia tworzenie prezentacji,
przemwie i filmw. Jednak ze wszystkich rodzajw kreatywnego wejcia nic nie dziaa
na mnie lepiej ni stara dobra space opera.
86
D EBUGOWANIE
Debugowanie
Jedna z najgorszych sesji debugowania w mojej karierze przytrafia mi si w 1972 roku.
Terminale podczone do systemu ksigowego firmy Teamsters zawieszay si raz lub
dwa razy na dzie. Nie dao si jednak w aden sposb wymusi tego stanu. Bd nie by
zwizany z konkretnym rodzajem terminala ani z okrelonymi aplikacjami. Nie miao te
znaczenia, co uytkownik robi tu przed zawieszeniem. W jednej chwili terminal dziaa
doskonale, a w nastpnej nie reagowa ju na nic.
Zdiagnozowanie tego problemu zajo nam cae tygodnie, w czasie ktrych firma Teamsters
stawaa si coraz bardziej nerwowa. Za kadym razem osoba, ktrej terminal si zawiesi,
musiaa skoordynowa si z innymi uytkownikami, tak eby zakoczyli oni prac, a nastpnie
zadzwoni do nas z prob o restart. To by prawdziwy koszmar.
Pierwsze dwa tygodnie spdzilimy, zbierajc dane z wywiadw prowadzonych z osobami,
ktrym przytrafia si blokada. Pytalimy, co robiy w czasie wystpienia blokady i wczeniej.
Pytalimy, czy zauwayy cokolwiek na swoich zawieszonych terminalach. Wszystkie te
pytania zadawalimy przez telefon, poniewa wszystkie terminale byy umiejscowione
w centrum Chicago, a my pracowalimy 50 kilometrw na pnoc od miasta, w rodku
pola kukurydzy.
Nie mielimy adnych protokow, adnych licznikw, adnych debuggerw. Jedynym
dostpem, jaki mielimy do systemu, byy wiateka i przeczniki na przednim panelu.
Moglimy zatrzyma komputer i przeglda jego pami po jednym sowie. Nie moglimy
tego jednak robi duej ni pi minut, poniewa firma Teamsters musiaa korzysta ze
swojego systemu.
Kilka dni powicilimy na napisanie prostego inspektora dziaajcego w czasie rzeczywistym,
ktrym moglimy sterowa z teletekstu ASR-33 sucego nam za konsol. W ten sposb
moglimy zaglda do pamici komputera w czasie pracy systemu. Dodalimy komunikaty
protokou, ktre w krytycznych momentach byy wypisywane na teletekcie. Przygotowalimy
liczniki zliczajce zdarzenia i zapamitujce histori stanw, ktr moglimy sprawdza za
pomoc inspektora. Oczywicie to wszystko zostao napisane od zera w asemblerze i byo
testowane wieczorami, gdy system nie by uywany.
Terminale byy sterowane przerwaniami, natomiast znaki przesyane do nich byy
umieszczane w cyklicznych buforach. Za kadym razem, gdy port szeregowy koczy
wysyanie znaku, uruchamiane byo przerwanie, w ktrym do wysania by przygotowywany
kolejny znak z cyklicznego bufora.
Ostatecznie okazao si, e terminale zawieszay si wtedy, gdy rozsynchronizoway si trzy
zmienne zarzdzajce stanem cyklicznego bufora. Nie mielimy pojcia, dlaczego tak si
dziao, ale to bya ju jaka wskazwka. Gdzie w 5 000 wierszy kodu superwizora znajdowa
si bd powodujcy nieprawidowe dziaanie tych wskanikw.
87
R OZDZIA 4.
K ODOWANIE
Ta wiedza pozwalaa nam te rcznie odblokowa terminale! Moglimy wpisa do tych

trzech zmiennych domylne wartoci za pomoc inspektora, a terminale zaczynay znowu
dziaa. W kocu napisalimy may programik, ktry kontrolowa warto tych licznikw
i w razie stwierdzenia nieprawidowoci przywraca im wartoci domylne. Pocztkowo
program ten by wywoywany przez nacinicie specjalnego przecznika na panelu
komputera za kadym razem, gdy kto z firmy Teamsters zgasza zawieszenie terminala.
Pniej uruchamialimy go automatycznie co sekund.
Po mniej wicej miesicu z punktu widzenia firmy Teamsters sprawa zawieszajcych si
terminali zostaa zamknita. Czasami jaki terminal zatrzymywa si na mniej wicej p
sekundy, ale przy prdkoci 30 znakw na sekund nikt tego nawet nie zauwaa.
Ale dlaczego te liczniki si rozsynchronizowyway? Miaem wtedy 19 lat i byem
zdeterminowany, eby znale przyczyn.
Kod superwizora zosta napisany przez Richarda, ktry teraz by ju na studiach. Nikt
z pozostaych czonkw zespou nie zna tego kodu zbyt dobrze, poniewa Richard by
w tym wzgldzie do zaborczy. Ten kod by jego, a my mielimy si od niego trzyma
z daleka. Teraz jednak Richarda nie byo ju w firmie, dlatego wycignem gruby wydruk
programu i zaczem przeglda go strona po stronie.
Cykliczne kolejki w tym systemie byy po prostu strukturami typu FIFO, czyli najzwyklejszymi
kolejkami. Programy umieszczay znaki na jednym kocu kolejki, a zostaa ona zapeniona.
Przerwania zdejmoway z kolei znaki z drugiego koca kolejki, za kadym razem gdy
drukarka bya gotowa na ich przyjcie. Jeeli kolejka bya pusta, to drukarka si zatrzymywaa.
Drobny bd sprawia, e aplikacje byy przekonane o tym, i kolejka jest pena, natomiast
przerwania stwierdzay, e kolejka jest pusta.
Przerwania byy wykonywane w innym wtku ni pozostay kod programu. Oznaczao
to, e liczniki i inne zmienne aktualizowane zarwno przez przerwania, jak i pozostay
kod musiay by odpowiednio zabezpieczone przed jednoczesnym zapisem. W naszym
przypadku oznaczao to wyczanie przerwa w pobliu kodu manipulujcego tymi
zmiennymi. W tym momencie wiedziaem ju, e musz znale w kodzie miejsce, ktre
zmienia zawarto feralnych zmiennych, nie wyczajc uprzednio przerwa.
Dzisiaj mamy do dyspozycji ca palet rnych narzdzi pozwalajcych wyszuka te
miejsca w kodzie, ktre interesuj si okrelon zmienn. W cigu kilku sekund mona
wywietli wszystkie podejrzane wiersze kodu. Znalezienie wycinka, w ktrym zapomniano
o wyczeniu przerwa, zajoby zaledwie minut. Jednak w roku 1972 nie istniay takie
narzdzia, a do dyspozycji miaem wycznie swoje oczy.
Dokadnie przegldaem kod zapisany na kadej stronie, poszukujc feralnych zmiennych.
Niestety, byy one uywane waciwie wszdzie. Niemal na kadej stronie byy w ten lub
inny sposb modyfikowane. W wielu przypadkach przerwania nie byy wyczane, poniewa
88
D EBUGOWANIE
zmienne byy tylko odczytywane, a przez to caa operacja bya niegrona. Problem polega
na tym, e w tym szczeglnym asemblerze nie dao si stwierdzi, czy referencja zmiennej
bya niegronym odczytem, bez dokadniejszego sprawdzenia kodu. Po kadym odczycie
zmiennej mogy nastpi jej aktualizacja i zapisanie. Jeeli zdarzyo si to w czasie, gdy
przerwania byy wczone, to zawarto zmiennej moga zosta uszkodzona.
Dokadne sprawdzenie kodu zajo mi kilka dni, ale w kocu znalazem przyczyn. W samym
rodku kodu ukryo si jedno miejsce, w ktrym aktualizowana bya jedna z trzech zmiennych
bez uprzedniego wyczenia przerwa.
Dokonaem wtedy pewnych oblicze. Czas trwania podatnoci to mniej wicej dwie
mikrosekundy. W firmie dziaao jakie 12 terminali pobierajcych dane z prdkoci
30 znakw na sekund, czyli jedno przerwanie pojawiao si mniej wicej co 3 milisekundy.
Biorc pod uwag wielko superwizora, czstotliwo zegara procesora, mona byo si
spodziewa, e terminal zostanie zablokowany jeden raz lub dwa razy dziennie. Bingo!
Usunem ten bd, ale nigdy nie miaem odwagi wyczy automatu sprawdzajcego
i korygujcego liczniki. Do dzisiaj nie mam pewnoci, czy w programie nie ukrywa si
jeszcze inny bd.
Czas debugowania
Z nieznanych mi powodw cz programistw nie uznaje czasu powiconego na
debugowanie za czas tworzenia kodu. Twierdz, e czas debugowania jest po prostu
wymogiem natury, czyli czym, co trzeba zrobi. Jednak z punktu widzenia firmy czas
debugowania jest tak samo kosztowny jak czas tworzenia kodu, dlatego wszystko, co zrobimy,
eby unikn debugowania albo przynajmniej skrci jego czas, bdzie pozytywnym
dziaaniem.
Dzisiaj spdzam na debugowaniu znacznie mniej czasu ni jeszcze 10 lat temu. Oczywicie
nie mierzyem rnicy, ale sdz, e jest to mniej wicej jeden rzd wielkoci. T radykaln
redukcj czasu debugowania uzyskaem przez przyjcie praktyki TDD (Test Driven
Development), o ktrej bd mwi w innym rozdziale.
Niezalenie od tego, czy stosujemy praktyk TDD, czy inne rozwizania o podobnej
skutecznoci3, na kadym zawodowym programicie ciy zadanie denia do jak
najskuteczniejszego redukowania czasu spdzanego na debugowaniu. Zerowy czas
jest tutaj celem asymptotycznym, ale mimo to zawsze powinien by naszym celem.
Chirurdzy nie lubi ponownie otwiera swoich pacjentw, eby poprawi co, co zrobili le.
Prawnicy nie lubi powtarza pozww tylko dlatego, e przy poprzednim palnli gupot.
Nie znam innej techniki o skutecznoci zblionej do TDD, ale moe wiesz co, czego ja nie wiem.
89
R OZDZIA 4.
K ODOWANIE
Chirurg lub prawnik, ktry zbyt czsto popenia takie bdy, nigdy nie bdzie uznany za
profesjonalist. Podobnie programista robicy zbyt wiele bdw dziaa nieprofesjonalnie.
Wyznaczanie sobie rytmu

Tworzenie oprogramowania to bardziej maraton ni sprint. Tego wycigu nie da si wygra,
biegnc od samego pocztku tak szybko, jak si da. Kluczem do zwycistwa jest zachowywanie
niezbdnych zasobw i wyznaczanie sobie odpowiedniego rytmu. Maratoczyk dba o siebie
zarwno przed wycigiem, jak i podczas niego. Zawodowi programici w podobny sposb
zachowuj swoj energi i kreatywno.
Wiedzie, kiedy odej

Nie moesz wrci do domu, dopki nie rozwiesz tego problemu? Oczywicie, e moesz,
a najprawdopodobniej tak naleaoby zrobi. Kreatywno i inteligencja to bardzo ulotne
stany umysu. Jeeli uginasz si od zmczenia, to na pewno si ich pozbywasz. Jeeli wtedy
zmuszasz swj przemczony mzg do pracy w pnych godzinach nocnych, prbujc
rozwiza jaki problem, to tylko zwikszasz swoje zmczenie, a tym samym zmniejszasz
szanse na to, e prysznic lub samochd pomog Ci znale rozwizanie.
Jeeli utkniesz w pracy i zmczenie nie pozwoli Ci dalej pracowa, to sprbuj si na chwil
odczy. Daj swojej podwiadomoci szans na podjcie prby rozwizania problemu.
Jeeli odpowiednio zadbasz o swoje zasoby, to uzyskasz wicej w krtszym czasie przy
znacznie mniejszym wysiku. Odpowiednio wyznaczaj rytm sobie i swojemu zespoowi.
Naucz si stosowa wzorce kreatywnoci oraz byskotliwoci i staraj si je wykorzysta do
swoich celw, a nie walczy przeciwko nim.
Jazda do domu
Miejscem, w ktrym udao mi si rozwiza zadziwiajco wiele problemw, jest mj
samochd wiozcy mnie z pracy do domu. Kierowanie autem wymaga zaangaowania
wielu niekreatywnych zasobw umysowych. Wykonywaniu tego zadania musisz powici
swoje oczy, rce oraz cz umysu. Oznacza to, e musisz odczy si od problemw
z pracy. Takie wanie odczenie pozwala Twojemu umysowi na poszukiwanie rozwiza
w inny, znacznie bardziej kreatywny sposb.
Prysznic
Rwnie wielk liczb problemw udao mi si rozwiza pod prysznicem. By moe ten
strumie wody wczenie rano pobudza mnie na tyle, e mog ponownie przeanalizowa
wszystkie rozwizania, na jakie wpad mj umys w czasie, gdy spaem.
90
S PNIENIA
Pracujc nad jakim problemem, czasami wchodzisz w niego tak gboko, e nie jeste
w stanie dostrzec wszystkich moliwych opcji. Pomijasz eleganckie rozwizania, poniewa
kreatywna cz Twojego umysu jest tumiona przez intensywno skupienia na zadaniu.
Czasami najlepszym sposobem na rozwizanie problemu jest powrt do domu, zjedzenie
kolacji, obejrzenie czego w telewizji, pjcie do ka i skorzystanie z prysznica po
przebudzeniu si nastpnego dnia.
Spnienia
Spnienia bd Ci si przytrafia. To zdarza si najlepszym spord nas. Zdarza si tym
najbardziej oddanym pracy. Czasami po prostu nasze szacunki nie s do dokadne i wtedy
si spniamy.
Waciw metod radzenia sobie z opnieniami jest wczesne ich wykrywanie i otwarte
informowanie o nich. Nie ma nic gorszego ni utrzymywanie do samego koca, e zdysz
na czas, i sprawienie zawodu w ostatnim momencie. Tak si nie robi. Zamiast tego regularnie
mierz swoje postpy i porwnuj je z celem, a nastpnie podawaj trzy4 wynikajce z tego
porwnania daty: najlepszy przypadek, normalny przypadek i najgorszy przypadek. Do tych
szacunkw nie dodawaj swoich nadziei! Trzy wyliczone daty zaprezentuj caemu zespoowi
i wszystkim zainteresowanym, a nastpnie codziennie je aktualizuj.
Nadzieja
Co zrobi, jeeli z tych szacunkw wynika, e moesz przestrzeli termin? Dla przykadu
zamy, e za 10 dni s targi i do tego czasu musimy mie gotowy produkt. Zamy te,
e Twoje trzy szacowane daty ukoczenia funkcji, nad ktr pracujesz, to 8/12/20.
Nie opieraj si na nadziei, e zdoasz zrobi wszystko w 10 dni! Nadzieja jest zabjc projektw.
Nadzieja niszczy plany i rujnuje reputacj. Nadzieja wpdzi Ci w powane tarapaty. Jeeli
targi zaczynaj si za 10 dni, a Twoja szacunkowa, normalna data ukoczenia to 12 dni,
to znaczy, e nie zdysz na czas. Upewnij si, e cay zesp i udziaowcy znaj szczegy
sytuacji, i nie odpuszczaj, dopki nie powstanie plan awaryjny. Nie dawaj innym faszywej
nadziei.
Popiech
Co zrobi, jeeli przeoony usadza Ci i prosi o prb dotrzymania terminu? Co zrobi,
jeeli kierownik nastaje, eby zrobi, co trzeba? Nie koryguj swoich szacunkw! Twoje
pierwotne szacunki bd o wiele dokadniejsze ni wszelkie zmiany, jakie wprowadzisz do
nich podczas takiej konfrontacji z szefem. Powiedz szefowi, e wszelkie moliwoci zostay
4
Wicej na ten temat opowiem w rozdziale Szacowanie.
91
R OZDZIA 4.
K ODOWANIE
ju wzite pod uwag (bo tak si stao) i jedyn metod poprawienia planu jest redukcja
zakresu projektu. Nie ulegaj pokusom przyspieszenia prac.
Biada biednemu programicie, ktry ugnie si pod presj i zgodzi si sprbowa dotrzyma
terminu. Taki programista zacznie wykorzystywa skrty i pracowa w nadgodzinach
w prnej nadziei na cud. To jest najprostsza recepta na katastrof, poniewa daje to
zespoowi i udziaowcom faszyw nadziej na sukces. Przez to nikt moe nie zauwaa
problemu, co opnia podjcie niezbdnych, cho trudnych decyzji.
Popiech nie jest adnym rozwizaniem. Nie jeste w stanie szybciej pisa kodu. Nie zmusisz
si do szybszego rozwizywania problemw. Jeeli zaczniesz podejmowa takie prby,
to tylko spowolnisz swoje dziaania, tworzc przy okazji baagan, ktry zacznie spowalnia
pozostaych czonkw zespou.
Musisz zatem udzieli szefowi i zespoowi uczciwej odpowiedzi, ktra pozbawi ich faszywej
nadziei.
Nadgodziny
Zdarza si, e szef mwi Ci: A jeeli popracujesz dwie dodatkowe godziny dziennie? A jeeli
przyjdziesz do pracy w sobot? Przecie musi by jaki sposb, eby wygospodarowa
dodatkowe godziny i przygotowa t funkcj na czas.
Nadgodziny mog by dobrym rozwizaniem, a czasami s nawet nieodzowne. Czasami
mona dotrzyma niemoliwego terminu, pracujc po 10 godzin dziennie, a nawet w jedn
sobot lub dwie. To jednak bardzo ryzykowne zaoenie. Nie jeste w stanie wykona 20%
wicej pracy, powicajc na to 20% wicej czasu. Co wicej, nadgodziny na pewno strac
jakikolwiek sens, jeeli taki tryb pracy potrwa duej ni dwa lub trzy tygodnie.
Oznacza to, e nie naley zgadza si na nadgodziny, chyba e (1) moesz sobie na to
pozwoli, (2) jest to rozwizanie krtkoterminowe, maksymalnie na dwa tygodnie i (3)
Twj szef ma ju plan awaryjny na wypadek, gdyby praca w nadgodzinach nie wystarczya.
Ten ostatni warunek jest tutaj najwaniejszy. Jeeli Twj szef nie jest w stanie stwierdzi,
co zrobi, jeeli nadgodziny nie przynios oczekiwanych efektw, to nie zgadzaj si na
dodatkowe godziny pracy.
Faszywa dostawa
Ze wszystkich nieprofesjonalnych zachowa, na jakie moe sobie pozwoli programista,
chyba najgorsze jest twierdzenie, e prace s zakoczone, cho ma si pen wiadomo
tego, e tak nie jest. Czasami jest to najzwyklejsze kamstwo, co samo w sobie jest ze.
Jednak znacznie bardziej podstpnym przypadkiem jest prba stworzenia nowej definicji
92
P OMOC
gotowego. Prbujemy si wtedy przekona, e jestemy wystarczajco gotowi, i od razu

przechodzimy do nastpnego zadania. Uznajemy, e praca, ktra zostaa jeszcze do
wykonania, moe zosta zrobiona pniej, kiedy bdzie na to czas.
Takie zachowanie jest bardzo zaraliwe. Jeeli robi tak jeden programista, to pozostali na
pewno to zauwa i zaczn postpowa podobnie. Jeden z nich jeszcze bardziej rozcignie
definicj tego, co gotowe, a reszta si do niej szybko przystosuje. Miaem nieprzyjemno
oglda ju ekstremalne przypadki takiego dziaania. Jeden z moich klientw definiowa
gotowe jako zapisane w systemie. Kod nawet nie musia si kompilowa. Jeeli nic nie
musi dziaa, to bardzo atwo powiedzie gotowe!
Gdy zesp wpada w t puapk, menederowie sysz, e wszystko w projekcie jest
w porzdku. Raporty o stanie wskazuj, e wszyscy pracuj zgodnie z planem. Przypomina
to piknik lepcw na torach kolejowych. Nikt nie zauwaa pocigu towarowego wiozcego
niedokoczon prac, a w kocu jest za pno.
Definicja gotowego
Problemu faszywych dostaw mona unikn, tworzc cakowicie niezalen definicj
gotowego. Najlepsz metod jej uzyskania jest wsppraca analitykw i testerw w celu
przygotowania zautomatyzowanych testw akceptacyjnych5, ktre musz zosta zaliczone,
aby dana funkcja moga zosta uznana za gotow. Takie testy powinny zosta zapisane
w wyspecjalizowanym jzyku, takim jak FitNesse, Selenium, RobotFX, Cucumber lub
podobnym. Poszczeglne testy musz by zrozumiae dla udziaowcw projektu oraz
dla biznesmenw, a przede wszystkim musz by uruchamiane odpowiednio czsto.
Pomoc
Programowanie to cika praca. Im kto jest modszy, tym trudniej mu w to uwierzy.
W kocu to tylko zbir instrukcji if i while. Jednak zbierajc dowiadczenie, zaczynasz
dostrzega, e najwaniejszy jest sposb, w jaki czone s ze sob te wszystkie instrukcje.
Nie moesz ich umieci po prostu w sekwencji i mie nadziej, e taka konstrukcja
zadziaa. Konieczne jest ostrone dzielenie caego systemu na mniejsze, zrozumiae czci,
ktre maj ze sob jak najmniej wsplnego. I to wanie jest najtrudniejsze.
Programowanie jest tak trudne, e jedna osoba nie jest w stanie zrobi tego dobrze.
Niezalenie od tego, jak wielki masz talent, to na pewno skorzystasz na przemyleniach
i pomysach innych programistw.
Zajrzyj do rozdziau 7., Testy akceptacyjne.
93
R OZDZIA 4.
K ODOWANIE
Pomaganie innym
Z tego wanie powodu kady programista powinien w miar moliwoci pomaga innym.
Izolowanie si w swoim boksie lub biurze i odmawianie odpowiedzi na pytania zadawane
przez innych jest naruszeniem etyki zawodowca. Twoja praca nie jest tak wana, e nie
moesz powici chwili na to, by pomc kolegom. Co wicej, kady profesjonalista podejmuje
honorowe zobowizanie do udzielania pomocy wszdzie tam, gdzie jest ona niezbdna.
Nie oznacza to, e nie potrzeba Ci czasu spdzonego w samotnoci. Oczywicie, e tego
potrzebujesz. Ale musisz o tym otwarcie i spokojnie informowa. Na przykad moesz
przekaza zespoowi, e pomidzy godzin 10 rano a poudniem nie naley Ci przeszkadza,
ale ju w godzinach od 13 do 15 Twoje drzwi s otwarte i kady moe przyj z pytaniami.
Musisz mie pen wiadomo tego, w jakim stanie s czonkowie Twojego zespou. Jeeli
zauwaasz, e kto ma problemy, to zaoferuj mu swoj pomoc. Moesz si naprawd zdziwi,
jak wielki skutek moe odnie Twoja pomoc. Nie chodzi o to, e ta inna osoba jest mniej
inteligentna od Ciebie. Po prostu spojrzenie z innej perspektywy moe mie ogromne
znaczenie przy rozwizywaniu problemw.
Prbujc komu pomc, najlepiej jest usi razem z nim i razem zacz tworzy kod.
Zaplanuj na ten cel jak godzin, a moe i wicej. By moe potrzeba bdzie mniej czasu,
ale te nie chodzi o popdzanie kogokolwiek. Uznaj dane zadanie za wasne i przy si
do niego solidnie. Cakiem moliwe, e na kocu nauczysz si wicej, ni dasz od siebie.
Przyjmowanie pomocy
Jeeli kto proponuje Ci swoj pomoc, oka mu wdziczno. Przyjmij j i staraj si j jak
najlepiej wykorzysta. Nie chro swojego terytorium. Nie rezygnuj z oferowanej pomocy,
nawet jeeli masz n na gardle. Powi na ten cel jakie p godziny. Jeeli przez ten czas
okae si, e kolega nie jest w stanie Ci pomc, to piknie mu podzikuj i zakocz sesj.
Pamitaj, e tak jak honor zobowizuje Ci do udzielania pomocy, tak i zobowizuje Ci
do jej przyjmowania.
Naucz si te prosi o pomoc. Jeeli utkniesz, dopadnie Ci zamroczenie albo po prostu nie
bdziesz w stanie ogarn problemu, to popro kogo o pomoc. Jeeli siedzisz w pokoju
z caym zespoem, moesz po prostu wsta i powiedzie: Potrzebuj pomocy. W innych
okolicznociach wykorzystaj Tweetera, e-mail albo telefon stojcy na biurku i popro
kogo o pomoc. Powtarzam raz jeszcze, e jest to kwestia etyki zawodowej. Zdecydowanie
nieprofesjonalne jest stanie w miejscu, podczas gdy pomoc jest tak atwo dostpna.
W tym momencie moe Ci si wydawa, e zaraz chralnie zapiewam Kumbaya, a w tle
rowe krliczki bd wskakiwa na grzbiety jednorocw i wsplnie poszybujemy ponad
tcz nadziei i zmian. No, nie do koca. Okazuje si, e programici bywaj aroganckimi,
94
B IBLIOGRAFIA
pochonitymi sob introwertykami. Tego zawodu nie wybiera si dlatego, e tak bardzo
lubi si ludzi. Wikszo z nas zostaa programistami, poniewa wolimy koncentrowa si
na sterylnych szczegach, jednoczenie przerzucajc rne pomysy, i w ogle udowadnia,
e mamy mzgi wielkoci maej planety, a jednoczenie unika skomplikowanej interakcji
z innymi ludmi.
To oczywicie stereotyp i wielka generalizacja, z wieloma rnymi wyjtkami. Ale
rzeczywisto jest taka, e programici raczej nie s najlepszymi wsppracownikami6.
A mimo to wsppraca jest bardzo istotnym czynnikiem skutecznego programowania.
Oznacza to, e cho dla wielu z nas wsppraca nie jest instynktowna, musimy wyrobi
sobie dyscyplin, ktra bdzie nas do tego zmuszaa.
Mentor
W dalszej czci ksiki powic temu tematowi cay rozdzia. Na razie powiem tylko
tyle, e szkolenie mniej dowiadczonych programistw jest zadaniem tych o wikszym
dowiadczeniu. I nie licz si tutaj kursy programowania. Nie licz si ksiki. Nic nie
jest w stanie szybciej wynie modego programisty na wyyny wydajnoci ni wasna
motywacja i pomoc starszych kolegw. I znw powicenie czasu, eby wzi modych
pod swoje skrzyda i odpowiednio ich szkoli, naley do etyki zawodowej dowiadczonych
programistw. Z tego wynika te, e zadaniem modszych programistw jest poszukiwanie
moliwoci skorzystania na dowiadczeniu starszych kolegw.
Bibliografia
[Martin09]: Robert C. Martin, Czysty kod. Podrcznik dobrego programisty, Gliwice,
Helion, 2009.
To znacznie czciej sprawdza si w przypadku mczyzn ni kobiet. Prowadziem kiedy bardzo

interesujc rozmow z @desi (Desi McAdam, zaoycielk witryny DevChix) na temat tego, co
motywuje kobiety programistki. Powiedziaem, e gdy udaje mi si w kocu uruchomi prawidowo
dziaajcy program, czuj si, jakbym powali wielk besti. Ona odpowiedziaa, e dla niej i wielu
innych kobiet, z ktrymi rozmawiaa, akt tworzenia kodu jest aktem wychowawczej kreacji.
95
R OZDZIA 4.
K ODOWANIE
96
TDD
Mino ju ponad 10 lat od czasu, gdy po raz pierwszy wiat usysza o TDD (Test Driven
Development rozwj oprogramowania sterowany testami). Praktyka ta bya czci
fali programowania ekstremalnego (XP Extreme Programming), ale pniej zostaa
zastosowana te w takich metodach jak Scrum i waciwie wszystkich innych metodach
zwinnych. Nawet zespoy niestosujce metodologii zwinnych uywaj dzisiaj TDD.
Kiedy w 1998 roku pierwszy raz usyszaem o programowaniu najpierw testw, byem
raczej sceptycznie nastawiony. Kto by nie by? Najpierw pisa testy? Kt wpad na tak
szalony pomys?
97
R OZDZIA 5.
TDD
W tym czasie miaem ju 30-letnie dowiadczenie w tworzeniu oprogramowania, dlatego

widziaem ju rne pomysy powstajce na naszej grzdce. Wiedziaem te, e nie naley
tak po prostu odrzuca jakichkolwiek pomysw, a szczeglnie tych, o ktrych mwi
Kent Beck.
A zatem w 1999 roku pojechaem do Medford w stanie Oregon, eby spotka si z Kentem
i od niego nauczy si nowej metodologii. To, czego dowiadczyem, wywoao u mnie szok!
Kent siedzia ze mn w swoim biurze i zacz pisa prosty programik w Javie. Ja przystpibym
bezporednio do pracy nad t drobnostk, ale Kent mnie powstrzyma i kaza przej
krok po kroku przez cay proces. Najpierw napisa ma cz testu jednostkowego, ktry
z ledwoci mona byo uzna za kod. Potem napisa tyle kodu programu, eby ten test
udao si skompilowa. Znowu dopisa troch testw i uzupenia je kodem programu.
Taki cykl pracy zupenie nie pasowa do moich dowiadcze. Byem przyzwyczajony do
pisania kodu przez prawie godzin, zanim w ogle sprbowaem go skompilowa i uruchomi.
Ale Kent uruchamia swj kod niemale co trzydzieci sekund. Byem niezmiernie zdziwiony.
Co wicej, od razu rozpoznaem czas trwania tego cyklu! Takiego samego cyklu pracy
uywaem w czasie swoich dziecicych1 zabaw z programowaniem gier w jzykach
interpretowanych, takich jak Basic lub Logo. W tych jzykach nie istniaa konieczno
kompilacji, dlatego wystarczyo dopisa wiersz kodu i uruchomi go. Taki cykl powtarza si
bardzo szybko, a dziki temu pisanie programw w tych jzykach te byo niezmiernie szybkie.
Jednak w przypadku prawdziwego programowania taki cykl pracy by absurdalny.
W prawdziwym programowaniu trzeba powici sporo czasu na napisanie kodu, a jeszcze
wicej na jego kompilacj. A potem ca gr czasu przeznaczy na debugowanie. W kocu
byem programist C++! A w tym jzyku czas kompilacji i konsolidacji mierzony jest
w minutach, a czasem i w godzinach. Takie 30-sekundowe cykle byy nie do pomylenia.
A mimo to Kent pracowa sobie nad programem w Javie, stosujc takie wanie 30-sekundowe
cykle, i nic nie wskazywao na to, e zaraz zacznie zwalnia. Siedzc tak oszoomiony w biurze
Kenta, uwiadomiem sobie, e przy zachowaniu takiej dyscypliny mgbym tworzy kod
w prawdziwych jzykach z szybkoci, jak znaem z Logo! To byo poraajce!
Sd na sali
Od tego czasu dowiedziaem si, e technika TDD jest czym wicej ni tylko prost sztuczk
pozwalajc skrci cykl pracy nad oprogramowaniem. Wie si z ni cay zbir zalet,
o ktrych napisz w poniszych akapitach.
1
Z mojego punktu widzenia dzieckiem jest jeszcze kady, kto nie ukoczy 35. roku ycia. Gdy miaem
20 lat, sporo czasu spdzaem na pisaniu maych, prostych gier w jzykach interpretowanych.
Pisaem w nich gry wojenne, przygodowe, wycigi konne, wopodobne, hazardowe i inne.
98
T RZY PRAWA TDD
Najpierw musz jednak powiedzie, e:

Sd jest na sali!
Kontrowersje si skoczyy.
GOTO jest ze.
A TDD naprawd dziaa.
Owszem, w tym czasie napisano ju wiele kontrowersyjnych blogw oraz artykuw

powiconych TDD i nadal powstaj nowe. Pocztkowo przewaay cakiem powane
prby krytykowania i zrozumienia tej techniki. Dzisiaj mona ju przeczyta tylko puste
tyrady. Najwaniejsze jest, e TDD dziaa, i powinnimy przyj to do wiadomoci.
Wiem, to brzmi strasznie jednostronnie, ale sdz, e tak jak chirurdzy nie powinni by
zmuszani do udowadniania zalet mycia rk, tak programici nie powinni by zmuszani
do obrony TDD.
Czy moesz myle o sobie jako o profesjonalicie, a jednoczenie nie mie pewnoci,
e Twj kod naprawd dziaa? A jak moesz mie pewno, e Twj kod dziaa, jeeli nie
przetestujesz go za kadym razem, gdy wprowadzisz do niego zmian? Jak moesz testowa
swj kod przy kadej zmianie, jeeli nie masz gotowych zautomatyzowanych testw o bardzo
wysokim pokryciu kodu? Jak moesz uzyska takie zautomatyzowane testy jednostkowe
z wysokim pokryciem, jeeli nie stosujesz TDD?
To ostatnie zdanie wymaga pewnego uszczegowienia. Czym waciwie jest TDD?
Trzy prawa TDD

1. Nie wolno napisa Ci nawet wiersza produktywnego kodu, jeeli wczeniej nie napiszesz
pasujcego testu jednostkowego, ktry nie zostanie zaliczony.
2. Nie wolno Ci napisa wicej testu jednostkowego, ni jest konieczne, eby test nie zosta
zaliczony. Nieudana kompilacja te powoduje, e test nie jest zaliczany.
3. Nie wolno Ci napisa wicej produktywnego kodu, ni potrzeba, eby aktualnie oblany
test zosta zaliczony.
Te trzy proste prawa zamykaj Ci w cyklu, ktry trwa by moe 30 sekund. Zaczynasz
od napisania maej czci testu jednostkowego. Ale ju po kilku sekundach musisz wpisa
nazw jakiej klasy lub jej funkcji, ktra jeszcze nie zostaa napisana, przez co testu nie da
si zaliczy z powodu bdu kompilacji. Oznacza to, e musisz dopisa kod produktywny,
tak eby test mona byo skompilowa. Nie moesz jednak napisa nic ponadto, a zatem
wracasz do pisania kodu w tecie jednostkowym.
99
R OZDZIA 5.
TDD
I tak w koo Macieju. Dopisanie kawaeczka kodu testowego. Dopisanie kawaeczka kodu
produktywnego. Dwa strumienie kodu rosnce jednoczenie w postaci uzupeniajcych
si skadnikw. Test dopasowuje si do kodu produktywnego, jak antyciao dopasowuje
si do antygenu.
Litania zalet
Pewno
Jeeli zaczniesz w normalnej pracy stosowa TDD, to kadego dnia bdziesz tworzy
dziesitki testw, co tydzie wytworzysz ich setki, a w rok zbior si tysice. A wszystkie
te testy bd zawsze aktualne i bdziesz uruchamia je przy kadej zmianie, jak wprowadzisz
do kodu.
Jestem gwnym autorem i konserwatorem projektu FitNesse2, czyli napisanego w Javie
narzdzia do testw akceptacyjnych. W czasie tworzenia tej ksiki projekt skada si
z 64 000 wierszy kodu, z czego 28 000 zawierao troch ponad 2200 testw jednostkowych.
Testy te pokrywaj ponad 90% kodu produktywnego3, a uruchomienie ich wszystkich
zajmuje jakie 90 sekund.
Za kadym razem, gdy wprowadzam jakkolwiek zmian do FitNesse, po prostu
uruchamiam testy jednostkowe. Jeeli zostan zaliczone, mam niemal cakowit pewno,
e wprowadzona wanie zmiana niczego nie popsua. Co waciwie znaczy niemal
cakowit pewno? Na tyle du, eby udostpnia poprawk!
Proces kontroli jakoci projektu FitNesse skada si z jednego polecenia: ant release.
Polecenie to kompiluje cay projekt od zera, uruchamia wszystkie testy jednostkowe
i akceptacyjne. Jeeli wszystkie testy zostan zaliczone, to znaczy, e mog udostpnia wersj.
Wspczynnik wprowadzania bdw

Oczywicie, e FitNesse nie jest szczeglnie wan aplikacj. Jeeli pojawi si w niej bd,
to nikt nie zginie ani nie straci milionw dolarw. Dziki temu mog wydawa kolejne
wersje na podstawie jedynie zaliczonych testw. Jednake FitNesse ma ju tysice
uytkownikw, a pomimo dopisania w ostatnim roku 20 000 wierszy nowego kodu
na mojej licie bdw znajduje si tylko 17 pozycji (wiele z nich to tylko kosmetyka).
Wiem zatem, e mj wspczynnik wprowadzania bdw jest bardzo niski.
http://fitnesse.org.
90% to minimum. Faktyczna warto jest zdecydowanie wysza. Niestety, dokadn warto pokrycia
bardzo trudno jest wyliczy, poniewa obliczajce j narzdzia nie widz kodu uruchamianego
w zewntrznych procesach albo w blokach catch.
100
T RZY PRAWA TDD
To nie jest efekt jednostkowy. Istnieje ju kilka raportw4 i bada5 opisujcych ogromn
redukcj liczby bdw. Kada firma od IBM do Microsoftu, od Sabre do Symanteca
dowiadczya dwukrotnego, piciokrotnego, a nawet dziesiciokrotnego zmniejszenia
liczby bdw. Takich wartoci nie moe ignorowa aden profesjonalista.
Odwaga
Dlaczego nie poprawiasz zego kodu w momencie, w ktrym go dostrzeesz? Twoj pierwsz
reakcj po zobaczeniu kodu zabaaganionej funkcji jest myl: Ten baagan trzeba koniecznie
uprztn. Zaraz po niej pojawia si jednak: Nawet tego nie dotkn. Dlaczego? Poniewa
wiesz, e jeeli tego dotkniesz, to prawdopodobnie co zepsujesz. A jeeli co zepsujesz,
to na Ciebie spadnie odpowiedzialno za to.
Co by si jednak stao, gdyby dano Ci pewno, e Twoje poprawki niczego nie zepsuj?
Czy wpynoby to na Twoje postpowanie? Co by byo, gdyby po klikniciu jednego
przycisku i odczekaniu 90 sekund mona byo uzyska pewno, e Twoje zmiany nic
nie zepsuy, a jedynie poprawiy jako kodu?
To jedna z najwaniejszych zalet TDD. Jeeli dysponujesz zestawem testw, ktrym moesz
zaufa, to nie masz ju obaw przed wprowadzaniem zmian. Jeeli widzisz zy kod, to po
prostu go poprawiasz. Kod upodabnia si do plasteliny, ktr moesz dowolnie ksztatowa,
tworzc proste i przyjemne struktury.
Gdy tylko programista przestaje si ba wprowadzania zmian, zaczyna czyci istniejcy
kod. Z kolei czysty kod jest znacznie atwiejszy do zrozumienia, atwiejszy do poprawienia,
a i jego rozbudowa jest prostsza. Dziki temu, e kod staje si prostszy, zmniejsza si szansa
powstania bdw. A cao kodu cigle jest poprawiana, zupenie inaczej ni w przypadku
typowego dla naszego zawodu powolnego niszczenia.
Czy zawodowy programista moe pozwoli sobie na dalsze niszczenie swojego kodu?
Dokumentacja
Zdarzyo Ci si ju korzysta z zewntrznych bibliotek? Czsto do takich bibliotek doczana
jest adnie sformatowana instrukcja napisana przez wyznaczonych do tego ludzi. Zazwyczaj
taka instrukcja skada si z byszczcych fotografii uzupenionych kkami i strzakami
oraz podpisem wyjaniajcym, jak naley skonfigurowa i zainstalowa dan bibliotek,
manipulowa ni czy te po prostu jej uywa. A na kocu instrukcji, w ktrym z dodatkw
znajduje si kilka maych przykadw paskudnego kodu.
http://www.objectmentor.com/omSolutions/agile_customers.html.
[Maximilien], [George2003], [Janzen2005], [Nagappan2008].
101
R OZDZIA 5.
TDD
Od czego zaczynasz czytanie takiej instrukcji? Jeeli jeste programist, to zapewne od

przykadw. Przechodzisz od razu do kodu, poniewa wiesz, e kod powie Ci prawd.
Wszystkie te byszczce fotografie, keczka i strzaki z pewnoci wygldaj bardzo adnie,
ale jeeli chcesz si dowiedzie, jak tego uywa, to patrzysz na kod.
Jeeli bdziesz postpowa zgodnie z trzema przedstawionymi tu reguami, to kady
z napisanych przez Ciebie testw jednostkowych bdzie opisywa sposb uycia systemu.
Postpujc zgodnie z tymi reguami, napiszesz testy jednostkowe opisujce metod tworzenia
kadego obiektu uywanego w systemie, a nawet kady sposb na utworzenie takiego
obiektu. Powstan testy jednostkowe opisujce wszystkie sensowne wywoania kadej
funkcji systemu. Kada czynno, ktr trzeba wykona w systemie, zostanie dokadnie
opisana za pomoc testw jednostkowych.
Testy jednostkowe s dokumentami. Opisuj one najniszy poziom projektu danego
systemu. S niedwuznaczne, dokadne i napisane w jzyku zrozumiaym dla czytajcego,
a jednoczenie s na tyle formalne, e mona je uruchomi. To najlepszy z moliwych
rodzaj niskopoziomowej dokumentacji. Ktry zawodowiec nie chciaby tworzy tak
wspaniaej dokumentacji?
Projekt
Jeeli postpujc zgodnie z tymi trzema prawami, najpierw napiszesz testy, staniesz przed
pewnym dylematem. Czsto dokadnie wiesz, jaki kod chcesz napisa, ale zasada testu
jednostkowego nakazuje Ci najpierw napisa test, ktry nie zostanie zaliczony! To znaczy,
e musisz przetestowa kod, ktry dopiero zaczniesz pisa.
Problem z testowaniem takiego kodu polega na tym, e najpierw musisz go wydzieli.
Czsto trudno testuje si funkcj, jeeli ta funkcja wywouje inne funkcje. Aby napisa
taki test, musisz wymyli sposb na oddzielenie danej funkcji od pozostaych. Oznacza
to, e konieczno napisania najpierw testu zmusza Ci do wymylenia dobrego projektu.
Jeeli nie napiszesz najpierw testu, to nic nie powstrzyma Ci przed poczeniem wielu
funkcji w niepoddajc si testowaniu mas. Jeeli test napiszesz pniej, to prawdopodobnie
uda Ci si przetestowa wejcia i wyjcia tej masy, ale przetestowanie poszczeglnych funkcji
moe by bardzo utrudnione.
Oznacza to, e postpujc zgodnie z trzema prawami i piszc najpierw testy, wytwarzasz
si, ktra zmusza Ci do tworzenia lepiej odizolowanego projektu. A ktry profesjonalista
nie skorzystaby z narzdzi pozwalajcych mu uzyska lepszy projekt oprogramowania?
Powiesz teraz: Przecie testy mog dopisa pniej. Niestety, nie moesz. Naprawd nie.
Oczywicie moesz pniej dopisa jakie testy, a jeeli si bardzo postarasz, to moesz
nawet osign wysokie pokrycie kodu. Ale testy pisane po powstaniu produktywnego
kodu s tylko rodzajem obrony. Testy pisane przed powstaniem kodu s bardzo ofensywne.
102
C ZYM TDD NIE JEST
Testy powstajce po fakcie s pisane przez osob, ktra poznaa dokadnie testowany kod
i doskonale wie, jak zosta rozwizany dany problem. Nie ma takiej moliwoci, eby te testy
byy tak wnikliwe jak testy pisane przed faktem.
Profesjonalne rozwizanie
Wniosek z tych wszystkich rozwaa jest taki, e TDD to bardzo profesjonalne rozwizanie.
Jest to dziedzina rozwijajca pewno siebie, odwag, zmniejszajca liczb bdw,
poprawiajca dokumentacj oraz projekt. Patrzc na to z tej perspektywy, nieuywanie
tej metody mona uzna za nieprofesjonalne.
Czym TDD nie jest

Mimo wszystkich swoich zalet TDD nie jest adn religi ani magicznym zaklciem.
Postpowanie zgodnie z trzema reguami nie zagwarantuje Ci adnej z opisanych zalet.
Nadal moesz tworzy brzydki kod, nawet jeeli najpierw napiszesz do niego testy. Co wicej,
moesz pisa paskudne testy.
Trzeba te pamita, e czasami stosowanie si do trzech regu jest niepraktyczne
i nieodpowiednie. Takie sytuacje s rzadkie, ale jednak istniej. aden zawodowy
programista nie powinien nigdy stosowa danej metodologii, jeeli ta przysparza
mu kopotw, a nie uatwia prac.
Bibliografia
[Maximilien]: E. Michael Maximilien, Laurie Williams, Assessing Test-Driven
Development at IBM, http://collaboration.csc.ncsu.edu/laurie/Papers/
MAXIMILIEN_WILLIAMS.PDF.
[George2003]: B. George i L. Williams, An Initial Investigation of Test-Driven
Development in Industry, http://collaboration.csc.ncsu.edu/laurie/Papers/
TDDpaperv8.pdf.
[Janzen2005]: D. Janzen i H. Saiedian, Test-driven development concepts, taxonomy,
and future direction, IEEE Computer, t. 38: 2005, nr 9, s. 43 50.
[Nagappan2008]: Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat
i Laurie Williams, Realizing quality improvement through test driven development:
results and experiences of four industrial teams, Springer Science + Business Media,
2008: http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf.
103
R OZDZIA 5.
TDD
104
WICZENIA
Kady zawodowiec rozwija si w swoim zawodzie, stosujc wiczenia poprawiajce rne

umiejtnoci. Muzycy cigle powtarzaj gamy. Gracze futbolu amerykaskiego biegaj przez
opony. Lekarze wicz szwy i metody chirurgiczne. Prawnicy wicz si w argumentowaniu.
onierze powtarzaj rne misje. Gdy chodzi o wydajno, kady profesjonalista wiczy.
W tym rozdziale skoncentrujemy si na rnych sposobach pozwalajcych programistom
wiczy si w swoim zawodzie.
105
R OZDZIA 6.
WICZENIA
Kilka wicze w tle

wiczenia nie s nowym pomysem w dziedzinie programowania, ale a do nowego
tysiclecia takie dziaania nie byy uwaane za wiczenia. Chyba pierwszy przykad
formalnego programu do wicze zosta wydrukowany na 6. stronie [K&R-C].
main()
{
printf("hello, world\n");
}
Kto z nas nie napisa tego programu w tej lub innej formie? Uywamy go jako sposb na
sprawdzenie nowego rodowiska lub nowego jzyka. Pisanie i uruchamianie tego programu
jest dowodem, e jestemy w stanie napisa i uruchomi dowolny program.
Gdy byem znacznie modszy, jednym z pierwszych programw, jakie pisaem na nowym
komputerze, by SQUIN, ktry oblicza kwadraty liczb cakowitych. Napisaem go
w asemblerze, BASIC-u, FORTRAN-ie, COBOL-u i setkach innych jzykw. By to
dla mnie sposb, by dowie, e mog zmusi komputer do zrobienia tego, co mu zadam.
Na pocztku lat 80. w sklepach zaczy pojawia si komputery osobiste. Gdy tylko dostaem
w swoje rce jeden z nich, czy by to VIC-20, Commodore-64, czy te TRS-80, zawsze
pisaem na nim may program, ktry wypisywa na ekranie niekoczcy si cig znakw
ukonika (\) i lewego ukonika (/). Wzory generowane przez taki program byy cakiem
przyjemne, a jednoczenie wyglday na bardziej skomplikowane ni sam program, ktry
je wytworzy.
Mimo e takie programy zdecydowanie byy wiczeniami, programici oglnie nie stosowali
wicze. Po prostu nigdy nikomu nie przyszo to na myl. Bylimy zbyt zajci pisaniem
kodu, eby w ogle pomyle o wiczeniu naszych umiejtnoci. Poza tym jaki miaby
by tego cel? Przez cae lata programowania nie potrzebowaem umiejtnoci szybkiego
reagowania ani szczeglnie sprawnych palcw. Do koca lat 70. nie uywalimy edytorw
ekranowych. Wikszo czasu spdzalimy w oczekiwaniu na zakoczenie pracy kompilatora
albo na debugowaniu straszliwie dugich cigw kodu. Nie wymylilimy jeszcze krciutkich
cykli TDD, dlatego niepotrzebne byo nam to szczeglne dopasowanie do rodowiska,
ktre mona uzyska tylko za pomoc wicze.
Dwadziecia dwa zera

Od pocztkw programowania troch si jednak zmienio. A niektre rzeczy zmieniy si
naprawd mocno. Z kolei pewne rzeczy nie zmieniy si prawie wcale.
Jedn z pierwszych maszyn, na ktre pisaem programy, byo PDP-8/I. Maszyna ta miaa
cykl o czasie 1,5 mikrosekundy. Do dyspozycji miaem 4096 12-bitowych sw pamici
operacyjnej. Cay komputer mia wielko lodwki i poera cakiem sporo energii elektrycznej.
106
K ILKA WICZE W TLE
Miaem te dysk, na ktrym mona byo zapisa 32 K 12-bitowych sw. Z komputerem

porozumiewaem si za porednictwem teletekstu o prdkoci 10 znakw na sekund.
Wtedy sdzilimy, e mamy potn maszyn, za pomoc ktrej tworzymy prawdziwe cuda.
Ostatnio kupiem nowego laptopa MacBook Pro. Ma dwurdzeniowy procesor z zegarem
2,8 GHz, 8 GB pamici RAM, dysk SSD o pojemnoci 512 GB oraz 17-calowy ekran
o rozdzielczoci 19201200 pikseli. Mog nosi go ze sob w plecaku, a pracowa, kadc
go na kolanach. Pobiera niecae 85 watw.
Mj laptop jest osiem tysicy razy szybszy, ma dwa miliony razy wicej pamici, sze
milionw razy wicej miejsca na dysku i pobiera zaledwie 1% energii, zajmujc tylko
1% przestrzeni starego PDP-8/I i kosztujc zaledwie jedn dwudziest pit jego ceny.
Policzmy zatem:
8000 2 000 000 16 000 000 100 100 25 = 6,4 1022
To gigantyczna warto. Mwimy tu o 22 rzdach wielkoci! Mniej wicej tyle angstremw
jest midzy Ziemi a Alfa Centauri. Tyle elektronw ukrywa si w srebrnym dolarze.
Tyle wynosi masa Ziemi w jednostkach Michaela Moorea. Ta liczba jest naprawd wielka.
A przy tym spokojnie ley sobie na moich kolanach. Na Twoich pewnie te.
I co robi z t moc powikszon o dziesi do dwudziestej drugiej? Mniej wicej to samo,
co robiem z PDP-8/I. Pisz instrukcj if, ptle while i instrukcje przypisania.
Oczywicie mam znacznie lepsze narzdzia do pisania tych instrukcji. Korzystam z duo
bardziej rozbudowanych jzykw, ale przez cay ten czas nie zmienia si natura pisanych
przeze mnie instrukcji. Programista z lat 60. bez wikszego problemu rozpoznaby
znaczenie kodu z roku 2010. Plastelina, ktr si bawimy, nie zmienia si mocno w cigu
ostatnich dziesicioleci.
Czas wykonania
Bardzo zmieni si jednak sposb, w jaki pracujemy. W latach 60. musielimy czeka dzie
lub dwa, eby zobaczy w kocu efekty naszej kompilacji. Pod koniec lat 70. kompilacja
programu o dugoci 50 000 wierszy trwaa mniej wicej 45 minut. Nawet w latach 90.
dugie czasy kompilacji nie byy niczym niezwykym.
Dzisiaj programici nie musz czeka na zakoczenie kompilacji1. Dzisiaj programici maj
do dyspozycji tak gigantyczn moc, e czerwono-zielony cykl refaktoryzacji mog realizowa
w cigu sekund.
1
Fakt, e cz programistw nadal czeka na jej zakoczenie, jest prawdziw tragedi i oznak
bezmylnoci. Dzisiaj czasy kompilacji powinny by mierzone w sekundach, a nie minutach,
a ju na pewno nie w godzinach.
107
R OZDZIA 6.
WICZENIA
Na przykad pracuj nad projektem o nazwie FitNesse, ktry skada si z 64 000 wierszu
kodu Javy. Pena kompilacja projektu, poczona z wykonaniem wszystkich testw
jednostkowych i integracyjnych, zajmuje mniej ni 4 minuty. Jeeli wszystkie testy zostan
zaliczone, to wiem, e mog wyda kolejn wersj. Cay proces kontroli jakoci, od kodu
rdowego do udostpnienia, zajmuje niecae 4 minuty. Czas samej kompilacji jest trudny
do zmierzenia. Testy czstkowe trwaj kilka sekund. Oznacza to, e cay cykl kompilacji
i testw mog wykonywa dziesi razy na minut!
Nie zawsze warto dziaa a tak szybko. Czsto znacznie lepszym rozwizaniem jest zwolni
i pomyle2. Ale zdarzaj si sytuacje, w ktrych jak najszybsza realizacja kolejnych cykli jest
dziaaniem niezwykle produktywnym.
Jakiekolwiek szybkie dziaanie wymaga odpowiedniej praktyki. Szybkie dziaanie w ptli
kodowania i testowania wymaga bardzo szybkiego podejmowania decyzji. A szybkie
podejmowanie decyzji wymaga umiejtnoci rozpoznawania wielu sytuacji i problemw
oraz dopasowywania do nich waciwych rozwiza.
Zastanwmy si nad walk dwch dowiadczonych wojownikw. Kady z nich musi
rozpozna zamiary przeciwnika i w cigu milisekund odpowiednio na nie zareagowa.
W trakcie walki nie masz moliwoci zatrzymania czasu, przeanalizowania pozycji
i zastanowienia si nad waciw reakcj. Walczc, musisz po prostu reagowa. Co wicej,
reagowaniem zajmuje si Twoje ciao, podczas gdy umys pracuje nad bardziej rozbudowan
strategi.
Podczas wykonywania kilku cykli tworzenia kodu i testowania na minut to Twoje ciao
wie, ktre klawisze ma naciska. Pierwotna cz Twojego umysu rozpoznaje dan sytuacj
i reaguje w cigu milisekund, stosujc pasujce rozwizanie, podczas gdy umys moe
swobodnie koncentrowa si na problemach wyszego poziomu.
Zarwno w przypadku wojownikw, jak i programistw szybko jest uzaleniona od
praktyki. A w obu przypadkach uzyskuje si j w podobny sposb. Wybieramy cay repertuar
par problem rozwizanie i powtarzamy je tak dugo, a poznamy je na pami.
Zastanwmy si nad gitarzyst klasy Carlosa Santany. Muzyka powstajca w jego gowie
po prostu przepywa przez jego palce. Nie zastanawia si on nad uoeniem palcw ani nad
zastosowaniem waciwej techniki. Jego umys moe swobodnie planowa rozbudowane
melodie, podczas gdy jego ciao przeksztaca te plany w niskopoziomowe ruchy palcw.
Jednak uzyskanie takiej atwoci grania wymaga wicze. Muzycy wicz gamy i etiudy,
powtarzajc je do znudzenia, a mog gra je na lepo.
Ta technika jest nazywana przez Richa Hickeya HDD, czyli Hammock-Driven Development
(rozwj hamakowy).
108
D OJO KODOWANIA
Dojo kodowania
Od 2001 roku prowadz zajcia demonstracyjne z TDD, ktre nazywam Gr w krgle
(ang. The Bowling Game)3. To mae i przyjemne wiczenie zajmuje okoo 30 minut.
Tworzy najpierw konflikt w projekcie, potem buduje napicie, a koczy si niespodziank.
Na podstawie tego przykadu napisaem cay rozdzia ksiki [PPP2002].
Przez lata zademonstrowaem to kata setki, a moe i tysice razy. Sprawio to, e jestem
w tym bardzo dobry! Mog je wykonywa na pico. Zminimalizowaem liczb nacini
klawiszy, dopasowaem nazwy zmiennych i zmieniem struktur algorytmu tak, e w kocu
staa si doskonaa. To byo moje pierwsze kata, cho wtedy tego jeszcze nie wiedziaem.
W 2005 roku wziem udzia w konferencji XP2005 w Sheffield, w Anglii. Skorzystaem
z sesji o nazwie Dojo kodowania (ang. Coding Dojo) prowadzonej przez Laurenta Bossavita
i Emmanuela Gaillota. Kazali wszystkim otworzy swoje laptopy i tworzy kod razem
z nimi, podczas gdy oni wykorzystywali TDD, eby przygotowa Gr ycia Conwaya.
To, co robili, nazywali kata, a pierwszestwo idei4 przyznawali Pragmatycznemu
Daveowi Thomasowi5.
Od tego czasu wielu programistw przyjo t pochodzc ze sztuk walki metafor sesji
wicze. Wyglda na to, e dojo kodowania6 zostao bardzo dobrze przyjte. Czasami
grupa programistw spotyka si i razem wiczy, podobnie jak robi to wojownicy. Zdarza
si te, e programici wicz samodzielnie, tak jak zdarza si to wojownikom.
Mniej wicej rok temu uczyem grup programistw z Omaha. W czasie obiadu poprosili
mnie o wzicie udziau w ich dojo kodowania. Obserwowaem, jak dwudziestu programistw
otworzyo swoje laptopy i klawisz po klawiszu powtarzali ruchy prowadzcego, ktry
wykonywa kata Gra w krgle.
W ramach dojo wykonywanych jest kilka rodzajw dziaa. Oto niektre z nich:
Kata
W sztukach walki kata to szczegowy zestaw ruchw, ktry symuluje jedn stron w walce.
Celem jest prba osignicia perfekcji, do ktrej mona si zbliy, ale nigdy nie mona jej
osign. Wojownik stara si nauczy swoje ciao, by doskonale wykonywao kady ruch,
Staa si ona bardzo popularnym kata, a wyszukiwanie tego hasa w Google zwraca wiele rde.
Orygina mona znale tutaj: http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata.
http://codekata.pragprog.com.
Okrelenie Pragmatyczny ma go odrnia od Wielkiego Davea Thomasa z OTI.
http://codingdojo.org/.
109
R OZDZIA 6.
WICZENIA
a nastpnie poczy poszczeglne ruchy w pynny taniec. Dobrze wykonane kata naprawd
przyjemnie si oglda.
Mimo caego ich uroku celem nauki kata nie jest prezentowanie ich na scenie. Ich zadaniem
jest takie wywiczenie umysu i ciaa, eby reagoway one na szczeglne sytuacje w walce.
Celem jest sprawienie, e takie doskonae ruchy stan si automatyczne i instynktowne,
tak by w razie potrzeby byy zawsze do dyspozycji.
W programowaniu kata jest dokadnym zestawem chronologicznie uoonych nacini
klawiszy oraz ruchw mysz symulujcych rozwizanie okrelonego problemu
programistycznego. Nie chodzi o samo wymylenie rozwizania problemu, poniewa
ono jest ju znane, ale o wywiczenie zwizanych z nim ruchw oraz decyzji.
Tutaj rwnie celem jest denie do perfekcji. Powtarzasz wiczenie raz za razem, aby
wywiczy mzg i palce w wykonywaniu odpowiednich ruchw i reagowaniu. Podczas
takich wicze zauwaysz drobne poprawy kadego wykonywanego ruchu albo i caego
rozwizania.
wiczenie caego zbioru rnych kata jest dobr metod na nauczenie si skrtw
klawiszowych oraz idiomw nawigacyjnych. Jest te dobr metod na nauk takich
metodologii jak TDD lub CI. Najwaniejsze jest jednak to, e jest to wietna metoda na
wprasowanie rozwiza typowych problemw w swoj podwiadomo, tak eby od razu
wiedzie, jak je rozwizywa w momencie, gdy si na nie natkniemy.
Podobnie jak wojownik programista powinien zna kilka rnych kata i wiczy je regularnie,
tak eby nie wyleciay mu z pamici. Wiele kata zostao zapisanych na stronie http://katas.
softwarecraftsmanship.org. Inne mona znale pod adresem http://codekata.pragprog.com.
Do moich ulubionych nale:
Gra w krgle (The Bowling Game): http://butunclebob.com/ArticleS.UncleBob.
TheBowlingGameKata.
Czynniki pierwsze (Prime Factors): http://butunclebob.com/ArticleS.UncleBob.
ThePrimeFactorsKata.
Zawijanie sw (Word Wrap): http://thecleancoder.blogspot.com/2010/10/
craftsman-62-darkpath.html.
Prawdziwym wyzwaniem jest nauczenie si kata tak dobrze, e mona zmieni je w muzyk.
To dopiero jest trudne7.
http://katas.softwarecraftsmanship.org/?p=71.
110
D OJO KODOWANIA
Wasa
W czasie gdy wiczyem jujitsu, wiele czasu spdzalimy w parach, wiczc nasze wasa.
Wasa mona przyrwna do dwuosobowego kata. Trzeba dokadnie zapamita poszczeglne
ruchy, a nastpnie je odtworzy. Jeden z partnerw odgrywa rol agresora, a drugi prbuje
si broni. Wszystkie ruchy s powtarzane w nieskoczono, a potem wiczcy zamieniaj
si rolami.
Programici mog wiczy w podobny sposb, wykorzystujc do tego gr ping-pong8. Dwch
partnerw wybiera w niej kata lub prosty problem. Jeden z nich pisze test jednostkowy,
a drugi musi sprawi, e zostanie on zaliczony. Potem zamieniaj si rolami.
Jeeli partnerzy wybior standardowe kata, to wynik wiczenia jest znany, a programici mog
wiczy i krytykowa wzajemne techniki posugiwania si klawiatur lub mysz, a take
poziom zapamitania danego kata. Jeeli jednak wybior nowy problem do rozwizania,
to gra staje si troch bardziej interesujca. Programista piszcy test ma ogromn wadz
nad ksztatem rozwizania. Ma te wielkie moliwoci tworzenia ogranicze. Na przykad
jeeli programista zdecyduje si zaimplementowa algorytm sortowania, to piszcy test
moe atwo naoy ograniczenia odnonie do prdkoci i zapotrzebowania na pami,
co bdzie wyzwaniem dla partnera. To sprawia, e caa gra moe sta si powan
rywalizacj i niez zabaw.
Randori
Randori jest walk w stylu wolnym. W naszym dojo jujitsu przygotowywalimy kilka
rodzajw starcia, a nastpnie je odgrywalimy. Czasami jedna osoba miaa si broni,
podczas gdy pozostali starali si j po kolei atakowa. Niekiedy dwie osoby miay atakowa
jednego obroc (zwykle by nim sensei, ktry niemal zawsze wygrywa). Kiedy indziej
stawalimy dwch na dwch itd.
Symulowana walka nie najlepiej przekada si na programowanie, ale istnieje pewna gra
nazywana randori, ktr wykorzystywaem podczas wielu dojo programowania. Przypomina
ona wasa z dwjk partnerw starajcych si rozwiza okrelony problem. Tym razem
jednak w zabawie bierze udzia wicej osb, a w reguach zostaje wprowadzona drobna
zmiana. Zawarto ekranu jest prezentowana na cianie. Jedna osoba pisze test i siada
na swoje miejsce. Nastpna osoba sprawia, e test zostaje zaliczony, i pisze kolejny test.
Mona to powtarza w kolejnoci dookoa stou, ale poszczeglne osoby mog si po prostu
zgasza, jeeli czuj tak potrzeb. W obu przypadkach wykonywanie takiego wiczenia
moe sprawia sporo radoci.
http://c2.com/cgi/wiki?PairProgrammingPingPongPattern.
111
R OZDZIA 6.
WICZENIA
Zadziwiajce jest, jak wiele mona si z takich sesji nauczy. Moesz w ten sposb pozna
metody rozwizywania problemw stosowane przez inne osoby. Takie informacje pomagaj
poszerzy wasne horyzonty i poprawi umiejtnoci.
Zwikszanie dowiadczenia
Profesjonalni programici zwykle cierpi z powodu braku zrnicowania stawianych przed
nimi problemw. Pracodawcy zazwyczaj wymuszaj stosowanie jednego jzyka, platformy
oraz dziedziny, w ktrych programista musi si porusza. Przy braku czynnika poszerzajcego
horyzonty moe to doprowadzi do niezdrowego zawenia yciorysu i umysu. Nierzadko
zdarza si, e tak ograniczeni programici s cakowicie nieprzygotowani na zmiany, jakie
okresowo przetaczaj si przez nasz bran.
Otwarte rda
Jednym ze sposobw wyrwania si z zastoju jest to, co czsto robi lekarze i prawnicy:
wykonanie pewnych prac pro bono, na przykad przez wspprac przy jakim
otwartordowym projekcie. W sieci istniej setki takich projektw i nie ma chyba
lepszego sposobu na poszerzenie repertuaru swoich umiejtnoci ni praca nad czym,
na czym zaley komu innemu.
Jeeli zatem programujesz normalnie w Javie, to docz do projektu pisanego w Ruby.
Jeeli w pracy wiele piszesz w C++, to znajd sobie projekt w Pythonie i postaraj si
go rozwija.
Etyka pracy
Profesjonalni programici wiczenia wykonuj w swoim czasie wolnym. Utrwalanie
i rozwijanie Twoich umiejtnoci nie jest zadaniem Twojego pracodawcy. Nie on ma
si zajmowa uatrakcyjnianiem Twojego CV. Pacjenci nie pac lekarzom za wiczenie
zakadania szww. Fani footbolu nie pac (zwykle) zawodnikom za patrzenie, jak biegaj
przez opony. Chodzcy chtnie na koncerty nie pac muzykom za ich wiczenia i granie
gam. A pracodawcy programistw nie powinni paci za czas powicony przez nich na
wiczenia.
Skoro czas wicze naley cakowicie do Ciebie, nie musisz korzysta z jzykw i platform
stosowanych przez Twojego pracodawc. Wybierz sobie dowolny jzyk i rozwijaj swj talent
poligloty. Jeeli w pracy poruszasz si w rodowisku .NET, to w czasie przerwy obiadowej
albo w domu powicz troch programowanie w Javie albo Ruby.
112
W NIOSKI
Wnioski
W ten lub inny sposb kady zawodowiec musi wiczy. Robi to, poniewa chce wykonywa
swoj prac najlepiej, jak to moliwe. Co wicej, na wiczenia powica swj prywatny
czas, gdy utrzymywanie umiejtnoci na wysokim poziomie uznaje za obowizek swj,
a nie pracodawcy. wiczenia wykonuje si wtedy, gdy Ci za to nie pac. Wykonuje si je
po to, eby uzyska dobr zapat za swoj prac.
Bibliografia
[K&R-C]: Brian W. Kernighan i Dennis M. Ritchie, The C Programming Language,
Upper Saddle River, NJ: Prentice Hall, 1975.
[PPP2002]: Robert C. Martin, Agile Software Development.Principles, Patterns,
113
R OZDZIA 6.
WICZENIA
114
T ESTY AKCEPTACYJNE
Rol profesjonalnego programisty mona podzieli na cz komunikacyjn i cz

programistyczn. Pamitaj, e programistw rwnie dotyczy zasada: mieci na wejciu, mieci
na wyjciu. Z tego wanie powodu profesjonalni programici staraj si upewni, e ich
komunikacja z pozostaymi czonkami zespou i ca firm jest dokadna i niedwuznaczna.
Komunikowanie wymaga
Jednym z najczstszych problemw w komunikacji midzy programistami i menederami
jest zdefiniowanie wymaga. Biznesmeni opowiadaj o tym, co jak im si wydaje
jest im potrzebne. Nastpnie programici tworz co, co jak im si wydaje opisa
115
R OZDZIA 7.
T ESTY AKCEPTACYJNE
biznesmen. Przynajmniej tak powinno to dziaa. W rzeczywistoci komunikacja dotyczca

wymaga jest niezmiernie skomplikowana, a cay proces naraony na bdy.
W 1979 roku, kiedy pracowaem dla firmy Teradyne, odwiedzi mnie Tom, meneder
instalacji i serwisu. Poprosi mnie, ebym pokaza mu, jak uy edytora tekstu ED-402
do przygotowania prostego systemu zgaszania problemw.
ED-402 by wasnociowym edytorem napisanym dla komputera M365, ktry by klonem
PDP-8 uywanym w Teradyne. Jako narzdzie do edycji tekstu by naprawd bardzo
rozbudowany. Mia nawet wbudowany jzyk skryptowy, ktrego uywalimy do
przygotowywania rnego rodzaju aplikacji dziaajcych na tekstach.
Tom nie by programist, ale potrzebna mu aplikacja bya tak prosta, e poprosi mnie
o nauczenie go szybko tej sztuki, tak aby mg samodzielnie napisa program. W swojej
naiwnoci uznaem, e to moliwe. W kocu ten jzyk skryptowy by tylko troszk bardziej
zaawansowanym wariantem jzyka makr stosowanego do edycji polece, wyposaonym
w podstawowe konstrukcje decyzyjne i zaptlajce.
Usiedlimy zatem razem i zapytaem, co planowana przez niego aplikacja miaaby robi.
Zacz od pocztkowego ekranu wprowadzania. Pokazaem mu zatem, jak utworzy plik
tekstowy zawierajcy instrukcje skryptu i jak wpisywa symboliczn reprezentacj polece
edycyjnych skadajcych si na skrypt. Gdy jednak spojrzaem w jego oczy, zobaczyem
tylko pustk. Moje wyjanienia nie miay dla niego adnego sensu.
Pierwszy raz si z czym takim spotkaem. Dla mnie byo to oczywiste, e polecenia edytora
s zapisywane za pomoc symboli. Na przykad aby zapisa polecenie control-B (umieszczao
ono kursor na pocztku biecego wiersza), wystarczy wpisa w pliku skryptu znaki ^B.
Dla Toma nie miao to adnego sensu. Nie by w stanie przestawi si z bezporedniego
edytowania pliku na edytowanie pliku, ktry bdzie edytowa plik.
Tom nie by gupi. Szybko zorientowa si, e zadanie jest znacznie trudniejsze, ni mu si
pocztkowo wydawao, a nie chcia inwestowa czasu i energii na uczenie si czego tak
niesamowicie skomplikowanego jak uywanie edytora do sterowania edytorem.
I tak krok po kroku zaczem sam tworzy ca aplikacj, podczas gdy on siedzia obok i mi
si przyglda. W cigu pierwszych dwudziestu minut stao si jasne, e jego zainteresowanie
przenioso si z mylenia, jak to zrobi samodzielnie, na upewnianie si, e ja robi to,
czego on chce.
Zajo nam to cay dzie. On opisywa kolejne funkcje, a ja je implementowaem pod jego
okiem. Cykl takiej pracy trwa jakie pi minut, dlatego nie byo sensu, eby zajmowa si
on czymkolwiek innym. Prosi mnie o zrobienie funkcji X, a pi minut pniej funkcja X
dziaaa.
116
K OMUNIKOWANIE WYMAGA
Czsto musia rysowa swoj wizj na kartce papieru. Niektre z jego pomysw trudno
byoby zrealizowa za pomoc ED-402, dlatego proponowaem inne rozwizania. Ostatecznie
zgadzalimy si na rozwizanie porednie, a potem staraem si je zastosowa.
W kocu prbowalimy to, co zostao zaimplementowane, a on zmienia zdanie. Mwi co
w rodzaju: No tak, ale to jednak nie dziaa tak, jak sobie wyobraaem. Moe sprbujemy
czego innego.
Godzina po godzinie prbowalimy, przestawialimy i nadawalimy aplikacji ostateczny
ksztat. Prbowalimy jednej rzeczy, potem innej, a potem jeszcze innej. Stawao si dla
mnie coraz wyraniejsze, e to on by tutaj rzebiarzem, a ja tylko trzymanym przez niego
narzdziem.
W kocu udao si nam przygotowa aplikacj, o ktrej myla Tom, cho on nadal nie
mia pojcia o tym, jak mgby sam napisa kolejny program. Z kolei ja dostaem porzdn
lekcj na temat tego, jak klienci dowiaduj si, czego im naprawd potrzeba. Nauczyem
si, e ich wizja poszczeglnych funkcji czsto nie jest w stanie przetrwa rzeczywistego
kontaktu z komputerem.
Przedwczesna dokadno
Zarwno programici, jak i biznesmeni czsto wpadaj w puapk przedwczesnej dokadnoci.
Biznesmeni chc od samego pocztku, jeszcze przed autoryzacj projektu, wiedzie, co waciwie
dostan. Programici z kolei chc od samego pocztku, jeszcze przed podaniem jakichkolwiek
szacunkw, wiedzie, co maj dostarczy. Obie strony chciayby mie dane o nieosigalnej
dokadnoci, ale czsto s w stanie powici fortun, eby mimo wszystko je otrzyma.
Zasada niepewnoci
Problem polega na tym, e pewne rzeczy wygldaj inaczej na papierze, a inaczej
w dziaajcym systemie. Gdy biznesmen widzi to, co opisa wczeniej, w gotowym systemie,
czsto zdaje sobie spraw, e nie o to mu chodzio. Gdy w kocu zobaczy swoje wymagania
w akcji, stwierdza, e ma lepszy pomys, ktry najczciej nie ma nic wsplnego z tym,
co wanie widzi.
W gr wchodzi tu pewnego rodzaju efekt obserwatora albo zasada niepewnoci. Kiedy
demonstrujesz funkcj biznesmenom, dajesz im wicej informacji, ni mieli wczeniej,
co wpywa na ich postrzeganie systemu jako caoci.
Ostatecznie okazuje si, e im dokadniej zdefiniowane bd wymagania systemu, tym
mniejsze bd miay one znaczenie w czasie implementowania.
117
R OZDZIA 7.
T ESTY AKCEPTACYJNE
Niepokojce szacunki
Programici rwnie mog wpa w puapk zbyt duej dokadnoci. Wiedz, e musz
oszacowa system, i czsto sdz, e to wymaga dokadnych informacji. Nieprawda.
Po pierwsze nawet z doskonale dokadnymi informacjami Twoje szacunki bd miay spor
niedokadno. Po drugie zasada niepewnoci te wstpnie dokadne dane przerabia na
sieczk. Wymagania odnonie do systemu na pewno si zmieni, przez co pocztkowa
precyzja staje si nieistotna.
Profesjonalni programici wiedz, e szacunki mog i powinny by tworzone na podstawie
mao dokadnych wymaga, a jednoczenie musz pamita, e szacunki s tylko
szacunkami. Na diagramach przedstawiajcych takie szacunki dodaj jeszcze paski
prezentujce moliwy bd, tak eby uwidoczni menederom t niepewno. (Zajrzyj
do rozdziau 10., Szacowanie).
Pna wieloznaczno
Rozwizaniem problemu przedwczesnej dokadnoci jest jak najdusze opnianie
pojawienia si tej precyzji. Profesjonalni programici nie zastanawiaj si nad danym
wymogiem do czasu, a przystpuj do jego implementowania. To moe jednak powodowa
inny rodzaj kopotw: pn wieloznaczno.
Udziaowcy projektu czsto si ze sob nie zgadzaj. W takiej sytuacji znacznie atwiej
jest im w jaki sposb obej ten brak porozumienia, ni faktycznie rozwiza problem.
Wyszukiwane s zatem sposoby takiego wyraenia wymagania, z ktrym kady moe si
zgodzi, cho to wcale nie rozwizuje problemu. Jaki czas temu syszaem, jak Tom DeMarco
powiedzia: Wieloznaczno w dokumencie wymaga systemu jest odzwierciedleniem
konfliktu midzy udziaowcami1.
Oczywicie do wytworzenia wieloznacznego wymagania nie trzeba adnej ktni ani braku
zgody. Czasami udziaowcy zakadaj, e czytelnicy dokumentu domyl si, co oni mieli
na myli.
We wasnym kontekcie mog doskonale zna swoje wymagania, ale dla programisty,
ktry pniej czyta ten tekst, moe on mie cakowicie odmienne znaczenie. Ten rodzaj
kontekstowej wieloznacznoci moe pojawi si rwnie wtedy, gdy klienci i programici
rozmawiaj bezporednio ze sob.
Sam (udziaowiec): Dobrze, natomiast te pliki trzeba bdzie zapisywa w kopii
zapasowej.
XP Immersion, 3 maja 2000, http://c2.com/cgi/wiki?TomsTalkAtXpImmersionThree.
118
K OMUNIKOWANIE WYMAGA
Paula: W porzdku, jak czsto tworzy tak kopi?.

Sam: Codziennie.
Paula: Dobrze. A gdzie mamy j zapisywa?.
Sam: Co masz na myli?.
Paula: Chcesz, eby kopi zapisywa w jakim konkretnym podkatalogu?.
Sam: To cakiem niezy pomys.
Paula: Jak nazwa ten podkatalog?.
Sam: Moe po prostu backup?.
Paula: Pewnie, nie ma problemu. A zatem codziennie bdziemy zapisywa kopi
zapasow w podkatalogu. A kiedy?.
Sam: Codziennie.
Paula: Nie, mam na myli, o ktrej godzinie mamy zapisywa te pliki?.
Sam: Och, to nie ma znaczenia.
Paula: W poudnie?.
Sam: No nie! Nie w czasie pracy. Lepiej bdzie o pnocy.
Paula: A zatem o pnocy.
Sam: wietnie, dziki.
Paula: Zawsze do usug.
Pniej Paula opowiada o tym zadaniu Peterowi, swojemu koledze z zespou.
Paula: Musimy te codziennie o pnocy kopiowa pliki protokou do podkatalogu
o nazwie backup.
Peter: Dobra, jak nazwa plik takiej kopii?.
Paula: Myl, e log.backup powinno pasowa.
Peter: Si zrobi.
W innym biurze Sam rozmawia przez telefon z klientem.
Sam: Oczywicie, pliki protokow bd zachowywane.
Carl: wietnie. To bardzo wane, ebymy nigdy nie stracili protokow. Musimy
do nich wraca nawet po miesicach albo i latach przy okazji jakich wycze,
awarii albo konfliktw.
Sam: Bez obaw, wanie rozmawiaem z Paul. Pliki bd zapisywane codziennie
o pnocy w katalogu o nazwie backup.
Carl: Brzmi niele.
119
R OZDZIA 7.
T ESTY AKCEPTACYJNE
Zakadam, e widzisz ju niejednoznaczno. Klient oczekuje, e zachowywane bd

wszystkie pliki protokow, ale Paula sdzi, e chodzi o zachowanie protokow z ostatniego
dnia. Gdy klient bdzie szuka plikw z kilku ostatnich miesicy, znajdzie tylko wczorajsze.
W tym przypadku to Paula i Sam dopucili si niedopatrzenia. Zadaniem profesjonalnych
programistw (i menederw) jest usunicie z wymaga systemu wszelkich niecisoci.
To naprawd trudne zadanie, a znam tylko jeden sposb na jego wykonanie.
Testy akceptacyjne
Pojcie testw akceptacyjnych jest uywane zdecydowanie zbyt szeroko. Niektrzy uwaaj,
e s to testy przeprowadzane przez uytkownikw, zanim zaakceptuj dane wydanie
systemu. Inni sdz, e chodzi o testy wykonywane przez dzia kontroli jakoci. W tym
rozdziale zdefiniujemy testy akceptacyjne jako testy napisane przez wsppracujcych
ze sob udziaowcw i programistw w celu zdefiniowania, kiedy dane wymaganie zostaje
spenione.
Definicja gotowego
Jedn z najwikszych niejednoznacznoci, z jakimi stykaj si zawodowi programici,
jest niejednoznaczne okrelenie, kiedy co jest gotowe. Gdy programista mwi, e wykona
dane zadanie, to co to waciwie oznacza? Czy zadanie zostao wykonane tak, e programista
moe przekaza dan funkcj dalej i mie cakowit pewno, e dziaa ona prawidowo?
Czy moe oznacza to, e wszystko jest gotowe dla dziau kontroli jakoci? A moe tylko
napisa kod funkcji i raz j uruchomi, ale nie przetestowa jej dokadnie?
Pracowaem ju z zespoami, ktre miay bardzo rne definicje sowa gotowe i zakoczone.
Jeden z takich zespow stosowa nawet dwa pojcia: gotowe i gotowe-gotowe.
Profesjonalni programici maj tylko jedn definicj tego sowa: gotowe znaczy gotowe.
Oznacza ono, e kod zosta napisany, wszystkie testy zostay zaliczone, a funkcja zostaa
zaakceptowana przez dzia kontroli jakoci i udziaowcw projektu.
Jak jednak mona osign a tak wysoki poziom gotowoci i nadal szybko rozwija
system w kadej iteracji? Trzeba przygotowa zestaw automatycznych testw, po ktrych
zaliczeniu stwierdzane jest, e kod spenia wszystkie kryteria! Testy akceptacyjne rozwijanej
funkcji zostaj zaliczone i wszystko jest gotowe.
Profesjonalni programici rozwijaj definicj wymaga systemu tak daleko, e na ich
podstawie opracowuj testy akceptacyjne. Pracuj przy tym z udziaowcami projektu
i dziaem kontroli jakoci, aby upewni si, e przygotowane testy akceptacyjne w peni
opisuj wymagania.
120
T ESTY AKCEPTACYJNE
Sam: Dobrze, natomiast te pliki trzeba bdzie zapisywa w kopii zapasowej.

Paula: W porzdku, jak czsto tworzy tak kopi?.
Sam: Codziennie.
Paula: Dobrze. A gdzie mamy j zapisywa?.
Sam: Co masz na myli?.
Paula: Chcesz, eby kopi zapisywa w jakim konkretnym podkatalogu?.
Sam: To cakiem niezy pomys.
Paula: Jak nazwa ten podkatalog?.
Sam: Moe po prostu backup?.
Tom (tester): Nie, backup to zbyt oglna nazwa. Co waciwie ma znale si w tym
katalogu?.
Sam: Kopie zapasowe.
Tom: Kopie czego?.
Sam: Plikw protokow.
Paula: Ale mamy tylko jeden plik protokou.
Sam: Nie, jest ich kilka. Po jednym na kady dzie.
Tom: To znaczy, e jest jeden aktywny plik protokou i wiele kopii zapasowych?.
Sam: To chyba oczywiste.
Paula: O! A mylaam, e chodzi tylko o tymczasow kopi zapasow.
Sam: Nie, nie! Klient chce przechowywa te pliki w nieskoczono.
Paula: A to co nowego. Dobrze, e teraz si o tym dowiedziaam.
Tom: A zatem nazwa podkatalogu powinna mwi nam, co si w nim znajduje.
Sam: Znajd si w nim wszystkie pliki nieaktywnych protokow.
Tom: Czyli mona go nazwa old_inactive_logs.
Sam: Brzmi dobrze.
Tom: A kiedy ten katalog bdzie tworzony?.
Sam: Sucham?.
Paula: Moemy tworzy ten katalog przy uruchamianiu systemu, ale tylko w przypadku,
gdy jeszcze nie istnieje.
Tom: No to mamy pierwszy test. Musz uruchomi system i sprawdzi, czy utworzony
zosta katalog old_inactive_logs. Potem mog do tego katalogu doda jaki
plik. Nastpnie musz zamkn system, uruchomi go ponownie i sprawdzi,
czy katalog i umieszczony w nim plik jeszcze istniej.
121
R OZDZIA 7.
T ESTY AKCEPTACYJNE
Paula: Ten test zajmie ci strasznie duo czasu. Aktualnie czas uruchomienia systemu
to 20 sekund i cigle si wydua. Poza tym nie chc kompilowa caego systemu
na potrzeby uruchomienia testu akceptacyjnego.
Tom: Co zatem proponujesz?.
Paula: Utworzymy klas SystemStarter. Program gwny zaaduje taki starter
z doczon list obiektw StartupCommand zbudowanych zgodnie ze wzorcem
polecenia. Nastpnie program nakae obiektowi SystemStarter uruchomi
wszystkie obiekty z listy. Jedno z tych polece utworzy katalog, jeeli nie bdzie
jeszcze istnia.
Tom: OK. Czyli wszystko, co musz zrobi, to przetestowa ten konkretny obiekt
wywiedziony z klasy StartupCommand. Mog napisa prosty test w FitNesse.
Tom podchodzi do tablicy.
Pierwsza cz bdzie wygldaa mniej wicej tak:
zakadajc, e mamy polecenie LogFileDirectoryStartupCommand
zakadajc, e katalog old_inactive_logs nie istnieje
gdy polecenie zostanie uruchomione
to katalog old_inactive_logs powinien istnie
i by pusty
Druga cz testu musi wyglda tak:

zakadajc, e katalog old_inactive_logs istnieje
i zawiera plik o nazwie x
to katalog old_interactive_logs powinien nadal istnie
i powinien nadal zawiera plik o nazwie x
Paula: To chyba powinno zaatwi spraw.

Sam: Rany! To wszystko jest naprawd konieczne?.
Paula: Sam, ktre z tych zda jest na tyle nieistotne, e mona je pomin?.
Sam: Chodzi mi o to, e to wyglda na strasznie duo roboty, takie wymylanie
i zapisywanie tych wszystkich testw.
Tom: To jest sporo pracy, ale nie jest jej wicej ni przy rcznym zapisywaniu planu
testw. A jeszcze wicej pracy wymaga rczne powtarzanie tego samego testu.
Komunikacja
Zadaniem testw akceptacyjnych jest odpowiednia komunikacja, wprowadzenie jasnoci
i precyzji. Zgadzajc si na to, programici, udziaowcy i testerzy ustalaj, jakie jest planowane
zachowanie systemu. Za uzyskanie takiej jasnoci odpowiedzialne s wszystkie strony
projektu. Profesjonalni programici uznaj za cz swojej pracy wspprac z udziaowcami
i testerami w celu ustalenia, e wszyscy wiedz, co ma zosta przygotowane.
122
T ESTY AKCEPTACYJNE
Automatyzacja
Testy akceptacyjne zawsze powinny by automatyzowane. W cyklu ycia oprogramowania
miejsce na testy manualne znajduje si gdzie indziej. Ten rodzaj testw nigdy nie powinien
by wykonywany rcznie. Powd jest bardzo prosty: koszta.
Spjrz na rysunek 7.1. Widoczne na nim rce nale do menedera kontroli jakoci
pracujcego w wielkiej firmie internetowej. Trzyma w nich dokument bdcy spisem treci
jego planu testw manualnych. Zarzdza on ca armi testerw w kilku zagranicznych
centrach, ktrzy wykonuj cay ten plan raz na sze tygodni. Za kadym razem kosztuje
to ponad milion dolarw. Trzyma ten dokument w taki sposb, poniewa wanie wraca
ze spotkania ze swoim menederem, ktry powiedzia mu, e musi ograniczy budet
o poow. Kieruje zatem do mnie pytanie: Ktr poow tych testw mam pomija?.
Rysunek 7.1. Plan testw manualnych
Nazwanie tego katastrof byoby mocnym niedopowiedzeniem. Koszta prowadzenia

planu testw manualnych s tak wielkie, e zdecydowali si je powici i przystali na stan,
w ktrym nie bd wiedzieli, czy poowa ich produktw bdzie dziaa.
Profesjonalni programici nie pozwalaj na powstanie takiej sytuacji. Koszt
zautomatyzowania testw akceptacyjnych jest tak niewielki w porwnaniu z kosztami
wykonywania testw manualnych, e nie jest ekonomicznie opacalne tworzenie
skryptw, ktre miayby by wykonywane przez ludzi. Profesjonalni programici bior
odpowiedzialno za swoj cz pracy, upewniajc si, e testy akceptacyjne s wykonywane
automatycznie.
123
R OZDZIA 7.
T ESTY AKCEPTACYJNE
Istnieje wiele otwartordowych i komercyjnych narzdzi pozwalajcych na

zautomatyzowanie testw akceptacyjnych. FitNesse, Cucumber, cuke4duke, Robot
Framework i Selenium to zaledwie kilka z nich. Wszystkie te narzdzia pozwalaj na
zdefiniowanie zautomatyzowanych testw w formie czytelnej dla osb niezwizanych
z programowaniem. Co wicej, umoliwiajcej takim osobom pisanie wasnych testw.
Dodatkowa praca
Uwaga Sama dotyczca nakadu pracy jest cakiem zrozumiaa. Pisanie tego rodzaju testw
akceptacyjnych naprawd wyglda na ogrom pracy. Jednak z rysunku 7.1 wynika, e tak
naprawd nie jest to praca dodatkowa. Pisanie tych testw jest prac zwizan z tworzeniem
specyfikacji systemu. Tworzenie specyfikacji o takim poziomie dokadnoci jest jedynym
sposobem pozwalajcym nam, programistom, stwierdzi, co waciwie znaczy gotowe.
Tak dokadna specyfikacja pozwala udziaowcom projektu upewni si, e system, za ktry
pac, naprawd robi to, co powinien. Poza tym napisanie tak dokadnej specyfikacji jest
jedynym sposobem na to, eby testy mona byo zautomatyzowa. Nie mona zatem
patrze na to jak na dodatkow prac, ale raczej trzeba widzie w tym metod pozwalajc
na ogromn oszczdno czasu i pienidzy. Takie testy zapobiegn implementowaniu
niewaciwego systemu i powiedz Ci dokadnie, kiedy system bdzie gotowy.
Kto i kiedy pisze testy akceptacyjne?

W idealnym wiecie udziaowcy i kontrola jakoci wsppracuj ze sob, piszc takie testy,
a programici kontroluj je jeszcze dla uzyskania penej spjnoci. W rzeczywistym wiecie
udziaowcy tylko rzadko maj czas i ochot, eby wystarczajco dokadnie pozna system.
W zwizku z tym zwykle przekazuj to zadanie analitykom biznesowym, kontroli jakoci
albo nawet programistom. Jeeli okazuje si, e to programista musi napisa testy
akceptacyjne, to trzeba zadba o to, by programista piszcy testy nie zajmowa si
jednoczenie implementowaniem testowanej funkcji.
Analitycy biznesowi zwykle tworz optymistyczn wersj testw, poniewa takie testy
opisuj funkcje majce du warto dla firmy. Dzia kontroli jakoci pisze zwykle testy
pesymistyczne, obejmujce wszelkie warunki kracowe. Wynika to z faktu, e zadaniem
kontroli jakoci jest wymylanie, co moe pj le.
Zgodnie z zasad pnej dokadnoci testy akceptacyjne powinny by pisane tak pno,
jak to tylko moliwe, najczciej na kilka dni przed zaimplementowaniem danej funkcji.
W projektach zwinnych s pisane po wybraniu funkcji dla nastpnej iteracji lub sprintu.
Pierwszych kilka testw akceptacyjnych powinno by gotowych ju pierwszego dnia iteracji.
Kolejne powinny by pisane w nastpnych dniach, a do poowy iteracji, kiedy to wszystkie
testy akceptacyjne musz by przygotowane. Jeeli testy te nie bd przygotowane do poowy
124
T ESTY AKCEPTACYJNE
iteracji, to cz programistw bdzie musiaa wspomc ich tworzenie. Jeeli bdzie si to

zdarzao czsto, to naley doda do zespou wicej analitykw biznesowych i testerw.
Rola programisty
Prace nad implementowaniem funkcji zaczyna si, gdy gotowe bd jej testy akceptacyjne.
Programici uruchamiaj testy akceptacyjne tworzonej funkcji, aby si dowiedzie, w jaki
sposb nie zostan one zaliczone. Nastpnie pracuj nad poczeniem testu akceptacyjnego
z systemem, a potem staraj si zaliczy ten test, implementujc opisywan przez niego
funkcj.
Paula: Peter, pomoesz mi z tym?.
Peter: No pewnie. W czym problem?.
Paula: Mam tutaj test akceptacyjny, ktrego jak widzisz, nie udao si zaliczy.
zakadajc, e katalog old_inactive_logs nie istnieje
to katalog old_inactive_logs powinien istnie
i powinien by pusty
Peter: No faktycznie, czerwony. Ale nikt nie dopisa do niego scenariuszy. Na szybko
napisz pierwszy.
|scenario| given the command _|cmd|
|create command|@cmd|
Paula: Operacja createCommand jest ju gotowa?.

Peter: Oczywicie. Jest w klasie CommandUtilitiesFixture. Napisaem j w zeszym
tygodniu.
Paula: OK, sprbuj uruchomi test.
Peter: (uruchamia test) Dobrze, pierwszy wiersz ju zielony. Moemy przej
do kolejnego.
Nie przejmuj si za bardzo scenariuszami i dodatkami. To tylko uzupenienia, ktre trzeba
dopisa, eby poczy test z testowanym systemem.
Wystarczy powiedzie, e wszystkie narzdzia udostpniaj jak metod dopasowywania
wzorcw do rozpoznawania i analizowania zapisanego testu, a nastpnie wywoywania
funkcji, ktre dostarczaj dane do testowanego systemu. Nakad pracy jest tutaj naprawd
niewielki, a poszczeglnych scenariuszy i dodatkw mona uywa ponownie w innych
testach.
Najwaniejsze w tym jest to, e przyczenie testu akceptacyjnego do systemu i zaliczenie
poszczeglnych testw jest zadaniem programisty.
125
R OZDZIA 7.
T ESTY AKCEPTACYJNE
Negocjowanie testw i pasywna agresja

Autorzy testw s tylko ludmi i dlatego popeniaj bdy. Czasami testy zapisane w okrelony
sposb trac swj sens w momencie, gdy zacznie si je implementowa. Niektre mog
by nadmiernie skomplikowane. Inne z kolei dziwacznie sformuowane. Mog zawiera
niedorzeczne zaoenia. Albo by z gruntu nieprawidowe. Takie testy mog doprowadza
do frustracji programistw, ktrzy maj je zaliczy.
Zadaniem kadego zawodowego programisty jest negocjowanie z autorem w celu uzyskania
lepszego testu. Z kolei nigdy nie wolno przyjmowa postawy pasywno-agresywnej i stwierdza:
Skoro to zostao zapisane w tecie, dokadnie to zaimplementuj.
Pamitaj, e zadaniem zawodowca jest wspomaganie zespou w deniu do przygotowania
jak najlepszego oprogramowania. Oznacza to, e kady powinien wyszukiwa bdy oraz
niedopatrzenia i wsplnie pracowa nad ich korygowaniem.
Paula: Tom, ale to chyba si nie zgadza.
upewnij si, e operacja wysyania zakoczy si w cigu 2 sekund
Tom: Jak dla mnie jest OK. W wymaganiach zapisano, e uytkownicy nie powinni
czeka duej ni dwie sekundy. Gdzie widzisz problem?.
Paula: Problem polega na tym, e takiej gwarancji moemy udzieli tylko w sensie
statystycznym.
Tom: To brzmi troch podstpnie. W wymaganiach s zapisane dwie sekundy.
Paula: Zgadza si. I moemy tego dotrzyma w 99,5% przypadkw.
Tom: Ale wymaganie nie zostao zdefiniowane w ten sposb.
Paula: Ale tak wyglda rzeczywisto. Nie ma sposobu na to, eby zagwarantowa
zakoczenie wysyania w dwie sekundy.
Tom: Sam si wcieknie.
Paula: No wanie nie. Ju z nim rozmawiaam o tym i nie ma nic przeciwko, pod
warunkiem e normalne odczucie uytkownika nie przekroczy dwch sekund.
Tom: No dobrze. W takim razie jak mam zapisa ten test? Nie mog przecie wpisa,
e operacja wysyania zwykle koczy si w cigu dwch sekund.
Paula: Zapisz to statystycznie.
Tom: Czyli mam tysic razy uruchomi operacj wysyania i sprawdzi, e co najwyej
pi prb trwao duej ni dwie sekundy? To przecie absurd.
Paula: Nie, to zajoby prawie godzin. Jest na to lepsza metoda. Co powiesz na to?.
wykonaj 15 operacji wysyania i zsumuj ich czasy
upewnij si, e ocena Z dla 2 sekund wynosi przynajmniej 2,57
Tom: Co to jest ocena Z?.
126
T ESTY AKCEPTACYJNE
Paula: To troch statystyki. Moe to bdzie lepsze.

wykonaj 15 operacji wysyania i zsumuj ich czasy
upewnij si, e w 99,5% przypadkw czas wykonania jest krtszy
ni 2 sekundy
Tom: To jest zdecydowanie czytelniejsze, ale czy mog zaufa obliczeniom

wykonywanym w tle?.
Paula: W wynikach testu bd podawa wszystkie obliczenia porednie, tak eby
mona byo wszystko skontrolowa w razie wtpliwoci.
Tom: OK, to mi si podoba.
Testy akceptacyjne i testy jednostkowe

Testy akceptacyjne nie s testami jednostkowymi. Testy jednostkowe s pisane przez
programistw dla programistw. S formalnymi dokumentami projektowymi opisujcymi
najnisz struktur i zachowanie kodu. Odbiorcami tych testw s inni programici,
nikt inny.
Testy akceptacyjne s pisane przez nieprogramistw dla nieprogramistw (nawet jeeli
ostatecznie to programista musi je zapisa). S formalnymi dokumentami opisujcymi
wymagania, definiujcymi, jak system powinien si zachowywa z punktu widzenia
uytkownika. Odbiorcami tych testw s zarwno programici, jak i pozostali uczestnicy
projektu.
Kuszce moe si wydawa wyeliminowanie dodatkowej pracy przez zaoenie, e te dwa
rodzaje testw s nadmiarowe. Chocia testy jednostkowe i akceptacyjne czsto sprawdzaj
te same rzeczy, to jednak nie s wzgldem siebie nadmiarowe.
Po pierwsze, mimo e testuj te same rzeczy, to jednak robi to za pomoc innych
mechanizmw i cieek. Testy jednostkowe dobieraj si do wntrznoci systemu i wywouj
poszczeglne metody w wybranych klasach. Testy akceptacyjne korzystaj z systemu na
znacznie wyszym poziomie: na poziomie API, a nawet interfejsu uytkownika. Oznacza
to, e cieka wykonania w tych testach jest odmienna.
Jednak najwaniejszym powodem, dla ktrego tych testw nie mona traktowa jako
nadmiarowych, jest to, e ich podstawowym zadaniem nie jest testowanie. Fakt, e s one
testami, to tylko przypadek. Testy jednostkowe i akceptacyjne s przede wszystkim
dokumentami, a dopiero potem testami. Ich podstawowym zadaniem jest formalne
udokumentowanie projektu, struktury i zachowania systemu. To, e przy okazji sprawdzaj,
czy te parametry s zgodne z oczekiwaniami, jest bardzo uyteczne, ale to specyfikacja
jest ich prawdziw natur.
127
R OZDZIA 7.
T ESTY AKCEPTACYJNE
Interfejsy uytkownika i inne komplikacje

Wstpne zaprojektowanie interfejsu uytkownika jest bardzo trudne. Oczywicie jest to
moliwe, ale tylko rzadko takie prby kocz si dobrze. Powodem takiego stanu rzeczy
jest fakt, e estetyka jest subiektywna, a zatem moe si zmienia. Ludzie chc si bawi
interfejsami uytkownika. Chc je dopieszcza i zmienia. Chc prbowa rnych czcionek,
kolorw, ukadw strony i przepyww. Oznacza to, e GUI cigle si zmienia.
Sprawia to, e pisanie testw akceptacyjnych dla interfejsw uytkownika jest kopotliwe.
Sztuczka polega na takim zaprojektowaniu GUI, eby mona byo go traktowa jak API,
a nie jak zbir przyciskw, suwakw, tabel i menu. Moe to brzmie dziwacznie, ale na tym
polega dobry projekt.
Istnieje zasada projektowania nazywana zasad pojedynczej odpowiedzialnoci (SRP Single
Responsibility Principle). Zgodnie z ni naley oddzieli od siebie rzeczy zmieniajce si
z rnych powodw, a grupowa te, ktre zmieniaj si z tego samego powodu. Interfejsy
uytkownika nie s tu wyjtkiem.
Ukad, format i przepyw w interfejsie uytkownika zmieniaj si z powodu estetyki
i wydajnoci pracy, ale znajdujce si poniej moliwoci GUI pozostaj niezmienne
mimo tych wszystkich zmian. Z tego powodu w trakcie pisania testw akceptacyjnych
dla interfejsu uytkownika trzeba wykorzystywa te niezmieniajce si zbyt czsto
podstawowe abstrakcyjne elementy.
Na przykad na stronie moe znajdowa si wiele przyciskw. Zamiast tworzy testy
klikajce poszczeglne przyciski na podstawie ich pozycji na stronie, lepiej jest klika je,
wykorzystujc ich nazwy. A jeszcze lepiej byoby, gdyby kady z tych przyciskw mia swj
unikalny identyfikator, ktrego mogyby uywa testy. Znacznie atwiej pisze si test
wybierajcy przycisk o identyfikatorze ok_button ni wybierajcy przycisk w trzecim
rzdzie i czwartej kolumnie siatki.
Testowanie przez waciwy interfejs

Najlepszym rozwizaniem jest jednak tworzenie testw wywoujcych funkcje testowanego
systemu poprzez waciwe API, a nie przez operacje na GUI. Testowane API musi by
jednak tym samym, z ktrego korzysta GUI. To nic nowego. Eksperci od projektowania
ju od dziesicioleci nakazuj nam oddziela interfejs uytkownika od regu biznesowych.
Testowanie poprzez interfejs uytkownika jest zawsze problematyczne, chyba e testowany
jest sam interfejs. Powodem jest to, e GUI moe si zmienia, przez co takie testy s bardzo
nietrwae. Jeeli kada zmiana w interfejsie uytkownika psuje tysic testw, to trzeba te
testy wyrzuci albo przesta wprowadza zmiany do GUI. adna z tych opcji nie jest
dobra. Dlatego testy regu biznesowych powinny korzysta z API znajdujcego si tu
pod interfejsem uytkownika.
128
W NIOSKI
Niektre testy akceptacyjne opisuj zachowanie samego GUI. Takie testy musz korzysta
z interfejsu uytkownika. Trzeba jednak pamita, e nie sprawdzaj one regu biznesowych,
a zatem nie wymagaj podczenia ich do GUI. Z tego powodu podczas testowania GUI
dobrze jest odczy interfejs uytkownika od regu biznesowych i zastpi te ostatnie
atrapami.
Testy interfejsu uytkownika naley ograniczy do minimum. Takie testy s nietrwae,
poniewa GUI szybko si zmienia. Im wicej testw GUI przygotujesz, tym bardziej
prawdopodobne jest, e z czasem zostan one porzucone.
Ciga integracja
Upewnij si, e wszystkie Twoje testy jednostkowe i akceptacyjne s uruchamiane kilka razy
dziennie w ramach systemu cigej integracji (ang. continuous integration system). System
ten powinien by uruchamiany przez system kontroli wersji kodu rdowego. Za kadym
razem, gdy kto wprowadza zmiany do moduu, system CI powinien uruchamia kompilacj,
a nastpnie wykonywa wszystkie testy w systemie. Wyniki takiego przebiegu powinny by
wysyane do wszystkich czonkw zespou.
Zatrzyma pras
Bardzo wane jest, eby testy w systemie CI byy uruchamiane bardzo czsto. Wszystkie
te testy powinny zosta zaliczone. Jeeli to si nie uda, to cay zesp powinien wstrzyma
prace i skupi si na tym, eby poprawi feralny test. Niepen kompilacj i niezaliczone
testy naley traktowa jak sytuacj alarmow i zdarzenie zatrzymujce pras.
Wsppracowaem ju z zespoami, ktre nie traktoway powanie nieudanych kompilacji
systemu. Wszyscy byli zbyt zajci, eby poprawia niezaliczone testy, dlatego spychali je
na bok, obiecujc, e poprawi je pniej. W jednym przypadku zesp usun z procesu
kompilacji niedziaajce testy, poniewa ich czerwone statusy byy w tym momencie nie na
rk. Pniej, po przekazaniu systemu klientowi, przypomnieli sobie, e zapomnieli wczy
te testy do procesu. Dowiedzieli si o tym, poniewa wcieky klient dzwoni i cigle zgasza
kolejne bdy.
Wnioski
Porozumiewanie si w sprawie szczegw jest bardzo trudne. Specjalnego wyrazu nabiera
to w przypadku, gdy programici i udziaowcy projektu musz porozumie si w sprawie
szczegw tworzonej aplikacji. Zbyt atwo kada ze stron moe machn rk i zaoy,
e druga strona j zrozumie. Czsto zdarza si te tak, e obie strony zgadzaj si na
porozumienie, ale rozchodz si, poniewa maj zupenie rne wyobraenia.
129
R OZDZIA 7.
T ESTY AKCEPTACYJNE
Jedynym znanym mi sposobem na skuteczne wyeliminowanie bdw komunikacji midzy

programistami i udziaowcami jest pisanie zautomatyzowanych testw akceptacyjnych.
Ich wykonywanie jest dziaaniem czysto formalnym. S cakowicie jednoznaczne i nie
mog rozsynchronizowa si z aplikacj. S zatem doskonaym dokumentem opisujcym
wymagania.
130
S TRATEGIE TESTOWANIA
Profesjonalni programici testuj swj kod. Jednak testowanie nie jest tylko kwesti napisania
kilku testw jednostkowych albo testw akceptacyjnych. Pisanie tych testw z ca pewnoci
pomaga, ale nie jest wystarczajce. Kady profesjonalny zesp programistw musi mie
dobr strategi testowania.
W 1989 roku pracowaem w firmie Rational nad pierwszym wydaniem systemu Rose. Mniej
wicej co miesic szef dziau kontroli jakoci ogasza dzie polowania na bdy. Kady
czonek zespou od programistw do menederw, sekretarki i administratorw baz danych
siedzia i prbowa wywoa jaki bd w Rose. Za wykrycie okrelonych rodzajw bdw
131
R OZDZIA 8.
byy przyznawane rne nagrody. Osoba, ktra wykrya bd powodujcy nage zamknicie
systemu, wygrywaa obiad dla dwojga. Z kolei osoba, ktra znalaza najwicej bdw,
wygrywaa weekend w Monterrey.

Mwiem ju o tym wczeniej, ale powiem jeszcze raz. Mimo e Twoja firma ma osobny
zesp kontroli jakoci, ktrego zadaniem jest testowanie oprogramowania, to celem
zespou programistw powinno by takie przygotowanie tego oprogramowania, eby
kontrola jakoci nie znalaza nic.
Oczywicie mao prawdopodobne jest, eby ten cel udawao si osign za kadym razem.
W kocu skoro mamy grup inteligentnych ludzi, ktrzy s zdeterminowani, eby znale
wszelkie niedocignicia i braki w naszym produkcie, to z pewnoci uda im si co
znale. Mimo to za kadym razem, gdy kontrola jakoci znajdzie bd w systemie, zesp
programistw powinien reagowa przeraeniem. Powinni zapyta samych siebie, jak to byo
moliwe, i przedsiwzi kroki uniemoliwiajce powstanie takich bdw w przyszoci.
Kontrola jakoci jest czci zespou

Z poprzedniego podrozdziau moe wynika, e dziay rozwojowy i kontroli jakoci
powinny ze sob konkurowa, a midzy nimi powinny panowa wrogie stosunki. Nie o to
jednak chodzi. Oba dziay powinny raczej wspdziaa, eby zapewni wysok jako
systemu. Najlepsz rol dla pracownikw dziau kontroli jakoci jest dziaanie definiujce
i uszczegawiajce.
Kontrola jakoci i definicje

Zadaniem dziau kontroli jakoci powinna by wsppraca z ca firm w celu przygotowania
zautomatyzowanych testw akceptacyjnych, ktre stan si prawdziw specyfikacj systemu
i dokumentem opisujcym wymagania wobec niego. W kadej kolejnej iteracji dzia
powinien gromadzi wymagania od klienta i przekada je na testy opisujce programistom
podane zachowanie systemu (rozdzia 7., Testy akceptacyjne). Oglnie analitycy
biznesowi tworz testy optymistyczne, natomiast dzia kontroli jakoci tworzy pesymistyczne
testy obejmujce wszystkie warunki kracowe.
Kontrola jakoci i uszczegowienia

Innym zadaniem dziau kontroli jakoci jest wykorzystanie testw badawczych1 do
zdefiniowania prawdziwego zachowania dziaajcego systemu i zgoszenia go programistom
http://www.satisfice.com/articles/what_is_et.shtml.
132
P IRAMIDA AUTOMATYZACJI TESTW
i analitykom biznesowym. W tym przypadku dzia kontroli jakoci nie interpretuje

wymaga wobec systemu, ale raczej dokumentuje jego rzeczywiste zachowanie.
Piramida automatyzacji testw

Profesjonalni programici do tworzenia testw jednostkowych stosuj technik TDD.
Zespoy profesjonalnych programistw wykorzystuj testy akceptacyjne do definiowania
zachowa swoich systemw oraz do cigej integracji (rozdzia 7.) zapobiegajcej bdom
regresyjnym. Ale te testy to tylko cz caoci. Oczywicie bardzo dobrze jest mie peen
zestaw testw jednostkowych i akceptacyjnych, ale oprcz tego potrzebne s jeszcze testy
wyszego poziomu, dajce nam pewno, e dzia kontroli jakoci nie znajdzie ju nic. Na
rysunku 8.1 przedstawiem piramid automatyzacji testw2, czyli graficzn reprezentacj
rodzajw testw wymaganych w profesjonalnych zespoach tworzcych oprogramowanie.
Rysunek 8.1. Piramida automatyzacji testw
Testy jednostkowe
Na samym dole piramidy s testy jednostkowe. Testy te s pisane przez programistw dla
programistw, w jzyku programowania, w ktrym tworzony jest system. Zadaniem tych
testw jest zdefiniowanie systemu na jego najniszym poziomie. Programici pisz je przed
napisaniem kodu produktywnego i traktuj jak sposb na zdefiniowanie tego, co maj
2
[COHN09], s. 311 312.
133
R OZDZIA 8.
zamiar napisa. Testy te s wykonywane w ramach cigej integracji i zapewniaj tym

samym, e zamiary programisty zostay zrealizowane.
Teoretycznie testy jednostkowe powinny zapewnia niemal stuprocentowe pokrycie kodu.
W rzeczywistoci pokrycie to powinno obejmowa ponad 90% kodu. I powinno to by
prawdziwe pokrycie, a nie oszukane testy, ktre tylko wykonuj kod, ale nie sprawdzaj
jego wynikw.
Testy komponentw
Tutaj znajduj si niektre z testw akceptacyjnych, o ktrych wspominaem w poprzednim
rozdziale. Pisane s one tak, eby testowa poszczeglne komponenty systemu. Komponenty
te obejmuj take reguy biznesowe, dlatego ich testy mona traktowa jak testy akceptacyjne
tych regu.
Jak mona zobaczy na rysunku 8.2, test komponentu zawija si naokoo tego, co testuje.
Przekazuje do komponentu dane wejciowe i odbiera od niego dane wyjciowe. Sprawdza
nastpnie, czy wyjcie pasuje do wejcia. Wszelkie pozostae komponenty systemu s w tym
momencie odczone z wykorzystaniem odpowiednich technik podmiany i imitowania
komponentw.
Rysunek 8.2. Akceptacyjny test komponentu
Testy komponentw s pisane przez dzia kontroli jakoci i analitykw biznesowych

przy wspudziale dziau rozwojowego. Powstaj w rodowiskach do tworzenia testw
komponentw, takich jak FitNesse, JBehave albo Cucumber. (Elementy GUI s testowane
za pomoc przeznaczonych do tego rodowisk, takich jak Selenium albo Watir). Celem jest,
eby kady by w stanie odczyta i zinterpretowa takie testy, a moe nawet je tworzy.
Testy komponentw powinny pokrywa mniej wicej poow systemu. Tworzone s zwykle
w celu sprawdzenia optymistycznych wariantw i oczywistych przypadkw alternatywnych
i kracowych. Ogromna wikszo przypadkw pesymistycznych pokrywana jest ju
w testach jednostkowych, a przez to trac one znaczenie w testach komponentw.
134
P IRAMIDA AUTOMATYZACJI TESTW
Testy integracyjne
Te testy maj znaczenie tylko w wikszych systemach skadajcych si z wielu komponentw.
Jak pokazaem na rysunku 8.3, cz kilka komponentw w grup i testuj ich wzajemn
komunikacj. Pozostae komponenty systemu pozostaj odczone z wykorzystaniem
typowych technik podmiany i imitowania.
Rysunek 8.3. Test integracyjny
Testy integracyjne mona nazwa testami choreografii. Nie maj testowa regu biznesowych,
ale raczej to, czy poszczeglne komponenty waciwie ze sob wsppracuj. S to testy
hydrauliczne, sprawdzajce, czy poszczeglne komponenty s ze sob odpowiednio poczone
i mog si ze sob komunikowa.
Testy integracyjne zazwyczaj pisane s przez architektw systemu albo przez jego gwnych
projektantw. Zapewniaj, e struktura architektoniczna systemu pozostaje nienaruszona.
To wanie na tym poziomie mona przeprowadza testy wydajnoci i przepustowoci.
Testy integracyjne zwykle pisane s w tym samym jzyku i rodowisku, w ktrym powstaj
testy komponentw. Nie s jednak wykonywane w ramach cigej integracji, poniewa czsto
czasy ich wykonania s bardzo dugie. Zamiast tego s uruchamiane cyklicznie (co noc albo
raz na tydzie), zalenie od tego, czy ich autorzy uznaj to za konieczne.
Testy systemowe
Testy systemowe s testami zautomatyzowanymi uruchamianymi na caym, poczonym
systemie. S ostatecznymi testami integracyjnymi. Nie testuj bezporednio regu
biznesowych, ale sprawdzaj, czy cay system zosta prawidowo poczony, a poszczeglne
jego czci dziaaj zgodnie z zaoeniami. Wrd tych testw powinny znale si te testy
przepustowoci i wydajnoci.
Ten rodzaj testw jest pisany przez architektw systemu. Zwykle s tworzone w tym samym
jzyku i rodowisku, w ktrym powstaway testy integracyjne interfejsu uytkownika. Ze
wzgldu na czas trwania wykonywane s raczej rzadko, ale im czciej si to dzieje, tym lepiej.
135
R OZDZIA 8.
Testy systemowe pokrywaj moe 10% systemu. Wynika to z faktu, e ich zadaniem nie jest
zapewnienie waciwego zachowania systemu, ale jego waciwej konstrukcji. Podane
zachowania bazowego kodu i komponentw zostay ju dokadnie przetestowane przez testy
z niszych poziomw piramidy.
Manualne testy badawcze

To w tym momencie ludzie kad rce na klawiatury, a oczy kieruj na ekrany. Ten rodzaj
testw nie jest zautomatyzowany, nie ma w nim adnych skryptw. Ich celem jest badanie
reakcji systemu na nieoczekiwane zachowania uytkownika i potwierdzanie zachowa
oczekiwanych. Na koniec potrzebne s ludzki umys i kreatywno pozwalajce na badanie
i poznawanie systemu. Przygotowywanie jakiegokolwiek planu tego rodzaju testw jest
sprzeczne z ich celami.
W niektrych zespoach s specjalne osoby wykonujce te zadania. Inne zespoy po prostu
ogaszaj jeden dzie lub dwa polowania na bdy, w czasie ktrych jak najwicej osb,
w tym i menederowie, sekretarki, programici, testerzy i twrcy dokumentacji, bawi si
systemem i stara na wszelkie sposoby sprowadzi go na kolana.
Tutaj celem nie jest pokrycie kodu. Nie bdziemy sprawdza poprawnoci kadej reguy
biznesowej i kadej moliwej cieki wykonania. Chodzi bardziej o sprawdzenie, czy system
zachowuje si poprawnie przy wsppracy z czowiekiem, i kreatywne wyszukanie jak
najwikszej liczby osobliwoci.
Wnioski
TDD jest bardzo potnym narzdziem, a testy akceptacyjne s cennym rodkiem wyraania
i wymuszania wymaga wobec systemu. S one jednak tylko czci oglnej strategii
testowania. Chcc jak najbardziej zbliy si do celu, w ktrym kontrola jakoci nie
znajdzie nic, zespoy programistw musz wsppracowa z dziaem kontroli jakoci
i wsplnie przygotowywa hierarchi testw jednostkowych, testw komponentw, testw
integracyjnych, testw systemu i testw badawczych. Testy te powinny by uruchamiane
tak czsto, jak to moliwe, aby zapewni jak najwiksz ilo danych i utrzyma nieprzerwan
czysto systemu.
Bibliografia
[COHN09]: Mike Cohn, Succeeding with Agile. Software Development Using Scrum,
Boston, MA: Addison-Wesley, 2009.
136
Z ARZDZANIE CZASEM
Osiem godzin to zadziwiajco krtki czas. To tylko 480 minut albo 28 800 sekund. Jako
profesjonalista oczekujesz zapewne, e jak najskuteczniej wykorzystasz t niewielk pul
sekund. Jak strategi moesz zastosowa, eby na pewno nie marnowa cennego czasu?
Jak mona skutecznie zarzdza swoim czasem?
W 1986 roku mieszkaem w Little Sandhurst, w hrabstwie Surrey w Anglii. Zarzdzaem
wtedy 15-osobowym dziaem programistw firmy Teradyne w Bracknell. Moje chaotyczne
dni wypeniay rozmowy telefoniczne, improwizowane spotkania i najrniejsze przerwy.
Chcc wykona jakkolwiek prac, przyjem kilka do drastycznych zasad zarzdzania
czasem.
137
R OZDZIA 9.
Z ARZDZANIE CZASEM
Kadego ranka budziem si o 5 rano i jechaem rowerem do biura w Bracknell, gdzie
docieraem o 6 rano. To dawao mi 2,5 godziny ciszy, zanim zaczyna si codzienny chaos.
Po dotarciu do pracy rysowaem na tablicy plan dnia. Dzieliem czas na 15-minutowe
czstki i wpisywaem do nich dziaania, ktrymi bd si zajmowa w danym wycinku czasu.

Cakowicie wypeniaem pierwsze 3 godziny planu. Od godziny 9 zaczynaem pomija
w kadej godzinie po jednym 15-minutowym bloku. W ten sposb mogem atwo wepchn
nieprzewidziane przerwy w takie otwarte przestrzenie, a potem pracowa dalej.
Czas po obiedzie pozostawiaem niezaplanowany, poniewa wiedziaem, e do tego czasu
rozpta si prawdziwe pieko i przez pozosta cz dnia bd musia dziaa w trybie

reaktywnym. W czasie tych rzadkich popoudniowych chwil, kiedy chaos troch przycicha,
pracowaem po prostu nad najwaniejszymi rzeczami.
Ten plan nie zawsze si sprawdza. Nie zawsze udawao mi si wsta o 5 rano, a czasami chaos
pochania moje staranne strategie i zajmowa mnie przez cay dzie. Ale przez wikszo
dni byem w stanie utrzyma si na powierzchni wody.
Spotkania
Koszt spotkania to mniej wicej 200 dolarw za godzin, za uczestnika. W t cen wliczam
zarwno pensj i dodatki, jak i koszta pomieszczenia itp. Nastpnym razem biorc udzia
w spotkaniu, policz jego koszta. Na pewno bd zadziwiajce.
O spotkaniach mona powiedzie na pewno, e:
1. Spotkania s niezbdne.
2. Spotkania s strasznym marnotrawstwem czasu.
Czasami oba punkty rwnie dobrze opisuj jedno spotkanie. Cz uczestnikw moe uzna
je za wartociowe, podczas gdy pozostali uznaj je za niepotrzebne.
Profesjonalici s wiadomi wysokich kosztw spotka. Wiedz te, e ich wasny czas
jest cenny w kocu musz napisa kod i zdy zrobi to w terminie. Z tego powodu
aktywnie oponuj przed udziaem w spotkaniach, z ktrych nie da si czerpa bezporednich
i znaczcych zyskw.
Odmawianie
Nie musisz bra udziau w kadym spotkaniu, na ktre dostaniesz zaproszenie. Co wicej,
udzia w zbyt wielkiej liczbie spotka mona uzna za dziaanie nieprofesjonalne. Musisz
mdrze korzysta ze swojego czasu, a zatem ostronie wybieraj spotkania i grzecznie
odmawiaj uczestniczenia w tych, ktre uznasz za nieprzydatne.
138
S POTKANIA
Osoba zapraszajca Ci na spotkanie nie zajmuje si zarzdzaniem Twoim czasem. Tylko

Ty moesz to robi. A zatem po otrzymaniu zaproszenia na spotkanie nie przyjmuj go,
chyba e Twoja obecno na nim jest absolutnie niezbdna i przydatna dla prac, ktre
aktualnie wykonujesz.
Czasami spotkania bd dotyczy czego, co Ci interesuje, ale nie jest Ci cakowicie
niezbdne. Wtedy musisz samodzielnie zdecydowa, czy moesz pozwoli sobie na
powicenie tego czasu. Zachowaj jednak ostrono takich spotka moe by do
duo, eby wypeni cae Twoje dni.
Czasami spotkania bd dotyczy czego, w czym moesz pomc, ale niemajcego adnego
znaczenia dla aktualnie wykonywanych przez Ciebie prac. Musisz wtedy zdecydowa,
czy strata poniesiona przez Twj projekt warta jest zyskw w innym projekcie. To moe
brzmie bardzo cynicznie, ale Twoj podstawow odpowiedzialnoci jest Twj wasny
projekt. Mimo to czasem dobrze jest, gdy jeden zesp wspomaga inny, dlatego warto
omwi swj udzia w takim spotkaniu z wasnym zespoem i menederem.
Czasami Twojej obecnoci na spotkaniu da bdzie kto z kierownictwa, na przykad
starszy projektant albo meneder innego projektu. Wwczas musisz zdecydowa, czy
danie tych osb jest waniejsze od Twojego wasnego planu prac. Wtedy rwnie pomocne
moe okaza si zapytanie wasnego zespou i menedera.
Jednym z najwaniejszych zada Twojego kierownika jest ograniczanie liczby Twoich
spotka. Dobry meneder bdzie bardzo chtnie broni Twojej decyzji o odmowie udziau
w spotkaniu, poniewa powinien on na rwni z Tob przejmowa si wykorzystaniem
Twojego czasu.
Wychodzenie ze spotka
Spotkania nie zawsze id zgodnie z planem. Czasami bierzesz udzia w spotkaniu, ktre
odbyoby si bez Ciebie, gdyby tylko wczeniej dostarczono Ci odpowiednie informacje.
Niekiedy dodawane s nowe tematy albo kto zaczyna zdominowywa rozmow swoim
konikiem. Przez lata wypracowaem sobie prost zasad: gdy spotkanie staje si nudne,
to po prostu wychodz.
Przypominam, e Twoim zadaniem jest odpowiednie zarzdzanie swoim czasem. Jeeli
okazuje si, e bierzesz udzia w spotkaniu, ktre zupenie nie przyczynia si do dobrego
wykorzystania Twojego czasu, znajd sposb, eby grzecznie si z niego wycofa.
Oczywicie nie naley wybiega z pokoju konferencyjnego, krzyczc: Ale nudy!. To byoby
niegrzeczne. Moesz jednak we waciwym momencie zapyta, czy Twoja obecno jest
konieczna. Naley wtedy wyjani, e nie masz a tyle czasu do dyspozycji, i poprosi
o przyspieszenie dyskusji albo zmian planu spotkania.
139
R OZDZIA 9.
Z ARZDZANIE CZASEM
Trzeba sobie uwiadomi, e dalszy udzia w takim spotkaniu bdzie dla Ciebie strat
czasu i nie jeste w stanie wnie nic istotnego do dyskusji. Twoim zadaniem jest mdre
gospodarowanie czasem i pienidzmi pracodawcy, dlatego wybranie waciwego momentu
i wyjcie ze spotkania jest zachowaniem godnym profesjonalisty.
Przygotuj plan i cel spotkania

Powodem, dla ktrego jestemy gotowi ponosi koszta spotka, jest to, e czasami konieczne
jest zebranie w jednym pokoju wszystkich uczestnikw, aby osign okrelony cel. Chcc
rozsdnie wykorzysta czas uczestnikw spotkania, powinnimy przygotowa jego plan
z rozpisanym czasem dyskusji na kady z tematw i okreli cel.
Jeeli poprosz Ci o udzia w spotkaniu, upewnij si, e znasz wszystkie dyskutowane na
nim tematy, ilo czasu przeznaczon na kady z nich i cele, jakie chce si osign. Jeeli
nie uzyskasz na te pytania jasnych odpowiedzi, to grzecznie odmw udziau w spotkaniu.
Jeeli po przystpieniu do spotkania stwierdzisz, e pierwotny plan zosta cakiem zmieniony
albo porzucony, popro o zarzucenie nowego tematu spotkania i postpowanie zgodnie
z pierwotnym planem. Jeeli tak si nie stanie, o ile to moliwe, postaraj si grzecznie wycofa.
Spotkania na stojco
Takie spotkania nale do kanonu metodologii zwinnych. Nazwa wywodzi si z tego,
e od uczestnikw spotkania oczekuje si stania przez cay jego czas. Po kolei kady
uczestnik odpowiada na trzy pytania:
1. Co dzisiaj zrobiem?
2. Co mam zamiar zrobi jutro?
3. Co mi przeszkadza?
To wszystko. Odpowied na kade z pyta powinna zajmowa nie wicej ni 20 sekund,
dlatego na kadego uczestnika spotkania przypada bdzie najwyej minuta. Nawet
w grupie dziesiciu osb spotkanie powinno si skoczy przed upywem 10 minut.
Spotkania planujce iteracje

W kanonie metodologii zwinnych s to spotkania, ktre najtrudniej zorganizowa
prawidowo. Jeeli ich prowadzenie bdzie ze, to zajm o wiele za duo czasu. Waciwe
ich prowadzenie wymaga umiejtnoci, ktre na pewno warto sobie przyswoi.
W ramach spotkania planujcego iteracje powinno si wybra pozycje backlogu, ktre
zostan zrealizowane w kolejnej iteracji projektu. Dla kandydujcych pozycji powinny by
140
S POTKANIA
ju gotowe szacunki pracochonnoci. Podobnie powinna by gotowa ocena ich biznesowej

wartoci. W naprawd dobrych organizacjach napisane ju s (a przynajmniej naszkicowane)
testy komponentw i akceptacyjne.
Spotkanie powinno szybko posuwa si naprzd, a kady kandydat wybrany z backlogu
powinien by tylko pokrtce omwiony, a nastpnie zatwierdzony lub odrzucony. Nad
poszczeglnymi pozycjami nie naley dyskutowa duej ni 5 do 10 minut. Jeeli konieczna
jest dusza dyskusja, to naley j przenie na inny termin i wybra do niej tylko cz zespou.
Moja oglna zasada mwi, e spotkanie planujce nie powinno trwa duej ni 5% oglnego
czasu iteracji. Oznacza to, e w przypadku tygodniowej iteracji (40 godzin) spotkanie powinno
zakoczy si po dwch godzinach.
Retrospektywa iteracji i demonstracja produktu

Te spotkania maj miejsce na zakoczenie kadej iteracji. Czonkowie zespou rozmawiaj
o tym, co poszo prawidowo, a co le. Udziaowcy mog obejrze demonstracj nowych,
dziaajcych funkcji. Z tymi spotkaniami mona bardzo mocno przesadzi, przez co
pochaniaj ogromne iloci czasu. Zaplanuj je zatem na 45 minut przed kocem pracy
ostatniego dnia iteracji. Przeznacz nie wicej ni 20 minut na retrospektyw i 25 minut
na demonstracj funkcji. Pamitaj, e min zaledwie tydzie lub dwa, dlatego nie powinno
by zbyt wielu tematw do omawiania.
Ktnie i nieporozumienia
Kent Beck powiedzia mi kiedy co bardzo wanego: Kada ktnia, ktrej nie da si
zaagodzi w 5 minut, nie zostanie zaagodzona w ramach dalszej ktni. Powodem takiego
przecigania sprawy jest to, e adna ze stron nie moe znale konkretnego dowodu
potwierdzajcego jej tezy. Takie ktnie s najzwyczajniej religijne, w przeciwiestwie
do ktni bazujcych na faktach.
Techniczne rozbienoci potrafi wybuchn a po sam stratosfer. Kada ze stron ma
pewne umocowania swoich pogldw, ale rzadko dysponuje jakimikolwiek danymi. Bez
danych w kadej ktni, w ktrej nie uda si zawrze porozumienia w cigu kilku minut
(pomidzy 5 a 30), nie ma najmniejszych szans na porozumienie. Jedynym rozwizaniem
jest dostarczenie niezbdnych danych.
S ludzie, ktrzy prbuj wygra tak ktni za pomoc siy charakteru. Mog wtedy
krzycze, dziaa natarczywie albo protekcjonalnie. To nie ma adnego znaczenia. Sia woli
nie usuwa niezgody na dugo. Tylko dane mog tego dokona.
Niektrzy mog zachowywa si pasywno-agresywnie. Zgadzaj si na zakoczenie sporu,
a potem sabotuj wyniki, odmawiajc swojego zaangaowania w rozwizanie. Tacy ludzie
141
R OZDZIA 9.
Z ARZDZANIE CZASEM
mwi sobie: Przecie tego chcieli, a zatem dostan dokadnie to, o co prosili. To chyba
najgorszy z moliwych przykad nieprofesjonalnego zachowania. Nigdy nie naley tak
postpowa. Jeeli si na co zgadzasz, to musisz si w to zaangaowa.
Jak zdoby dane niezbdne do zaagodzenia sporu? Czasami mona wykona kilka
eksperymentw albo symulacji. Niekiedy jednak alternatyw bdzie rzucenie monet
i wybranie jednego z dwch moliwych rozwiza.
Jeeli wybrane rozwizanie zadziaa, to znaczy, e byo waciwe. Jeeli wpadniesz w tarapaty,
to zawsze moesz si wycofa i sprbowa drugiego rozwizania. Dobrze jest te ustali czas
i zestaw kryteriw uatwiajcych stwierdzenie, kiedy naley porzuci wybrane rozwizanie.
Wystrzegaj si spotka, ktre s jedynie sposobem na upublicznienie sporu i zebranie
poparcia dla jednej lub drugiej strony. I unikaj tych spotka, na ktrych obecna jest tylko
jedna ze stron sporu.
Jeeli spr musi by zaagodzony, to popro obie strony o zaprezentowanie zespoowi swoich
argumentw w cigu maksymalnie 5 minut. Nastpnie cay zesp powinien zagosowa.
Tego rodzaju spotkanie nie potrwa nawet 15 minut.
Manna skupienia
Wybacz, jeeli ten, podrozdzia bdzie mia posmak metafizyki New Age albo Dungeons
& Dragons. Po prostu w ten sposb wyobraam sobie cae to zagadnienie.
Programowanie jest wiczeniem intelektualnym, ktre wymaga dugich okresw
koncentracji i skupienia. Skupienie jest niestety bardzo rzadkim dobrem, podobnie jak
manna1. Po wyczerpaniu swojej manny skupienia musisz j uzupeni, wykonujc przez
przynajmniej godzin czynnoci niewymagajce koncentracji.
Nie wiem dokadnie, czym jest ta manna skupienia, ale mam wraenie, e jest to wrcz
fizyczna substancja (albo moe jej brak), ktra wpywa na nasz uwag i czujno.
Czymkolwiek jest, na pewno czujesz, gdy jest z Tob, czujesz rwnie, gdy jej brakuje.
Profesjonalni programici nauczyli si tak zarzdza swoim czasem, eby jak najlepiej
wykorzysta swoj mann skupienia. Pisz kod, gdy masz sporo manny skupienia, a mniej
produktywne czynnoci wykonuj wtedy, gdy jej brakuje.
Manna jest zasobem czsto wykorzystywanym w grach fantasy i przygodowych, takich jak
Dungeons & Dragons. Kady gracz ma pewien zasb manny, czyli magicznej substancji, ktra
wyczerpuje si w czasie rzucania czarw. Im potniejsze jest zaklcie, tym wicej manny zuywa.
Niestety, manna odradza si bardzo powoli, w pewnym dziennym rytmie. Oznacza to, e atwo
mona wyczerpa swoje zasoby w zaledwie kilku sesjach rzucania zakl.
142
M ANNA SKUPIENIA
Manna skupienia jest te zasobem, ktrego powoli ubywa. Jeeli nie korzystasz z niej
wtedy, gdy jest dostpna, to najprawdopodobniej j stracisz. To midzy innymi dlatego
spotkania mog mie tak niszczce dziaanie. Jeeli ca swoj mann skupienia roztrwonisz
na spotkaniach, to nie zostanie Ci nic w czasie, gdy zechcesz pisa kod.
Zmartwienia i rozproszona uwaga rwnie zuywaj Twoj mann skupienia. Wczorajsza
ktnia z on lub mem, zadrapanie, ktre udao Ci si zrobi dzi rano na zderzaku, albo
niezapacony rachunek to wszystko bardzo szybko wysysa z Ciebie mann skupienia.
Sen
Nie jestem w stanie wyrazi tego do stanowczo. Najwicej manny skupienia mam po dobrze
przespanej nocy. Siedem godzin snu czsto dostarcza mi manny skupienia na pene osiem
godzin pracy. Profesjonalni programici odpowiednio planuj swj sen tak, eby najwicej
manny skupienia mie w czasie, gdy rano przychodz do pracy.
Kofeina
Bez wtpienia niektrzy z nas umiej lepiej wykorzysta swoje zasoby manny skupienia,
wlewajc w siebie niewielkie iloci kawy. Ale tu trzeba postpowa ostronie. Kofeina
sprawia, e nasze skupienie staje si roztrzsione, a wiksze jej iloci mog skierowa
je na bardzo dziwne tory. Naprawd solidna dawka kofeiny moe sprawi, e stracisz cay
dzie, koncentrujc si na zupenie niepotrzebnych rzeczach.
Konsumpcja i tolerancja kofeiny to sprawa bardzo osobista. Sam lubi wypi kubek mocnej
kawy rano i dietetyczn kol do obiadu. Czasami podwajam sobie dawk, ale bardzo rzadko
przekraczam t granic.
adowanie akumulatorw
Mann skupienia mona czciowo odzyska, robic co niewymagajcego koncentracji.
Dugi spacer, rozmowa z przyjacielem albo spogldanie przez okno mog podnie poziom
Twojej manny skupienia.
Niektrzy prbuj medytowa. Inni pozwalaj sobie na krtk drzemk. Jeszcze inni suchaj
jakiego podcastu albo czytaj gazet.
Wiem te, e po wyczerpaniu manny nie mona zmusza si do dalszego skupienia. Nadal
moesz pisa kod, ale niemal na pewno konieczne bdzie poprawianie go nastpnego dnia.
No chyba e pogodzisz si z istnieniem tego paskudztwa przez kolejne tygodnie i miesice.
Lepiej jednak powici 30 albo i 60 minut na co niewymagajcego koncentracji.
143
R OZDZIA 9.
Z ARZDZANIE CZASEM
Skupienie mini
Co niesamowitego jest w wykonywaniu wicze fizycznych, takich jak sztuki walki, tai-chi
albo joga. Mimo e wiczenia te wymagaj od Ciebie duego skupienia, to jednak jest to inny
rodzaj skupienia ni to niezbdne podczas tworzenia kodu. Nie jest to skupienie intelektu,
ale mini. I w jaki przedziwny sposb skupienie mini pozwala na odzyskanie moliwoci
intelektu. To jednak co wicej ni proste naadowanie akumulatorw. Przekonaem si ju,
e regularne wiczenia fizyczne zwikszaj moje moliwoci skupienia umysowego.
Moj ulubion form skupienia fizycznego jest jazda na rowerze. Jad przez godzin lub
dwie, pokonujc w tym czasie jakie 30 lub 40 kilometrw. Jed zwykle po ciece biegncej
wzdu rzeki Plaines, dlatego nie musz si przejmowa samochodami.
W czasie jazdy sucham podcastw na temat astronomii lub polityki. Czasami wybieram
po prostu swoj ulubion muzyk, a innym razem zdejmuj suchawki i wsuchuj si
w odgosy natury.
S te ludzie, ktrzy lubi prace rczne. Na przykad bawi si stolark, budowaniem
modeli albo pielgnacj ogrodu. Niezalenie od rodzaju takiej aktywnoci jest co w pracach
wykorzystujcych gwnie minie, e powikszaj one moliwoci pracy umysowej.
Wejcie kontra wyjcie

Inn rzecz, ktra moim zdaniem bardzo wpywa na skupienie, jest dopasowanie mojego
wyjcia do waciwego wejcia. Pisanie oprogramowania jest zajciem kreatywnym. Uwaam,
e najbardziej kreatywny jestem wtedy, gdy dowiadczam kreatywnoci innych ludzi.
Czytam zatem sporo literatury science fiction. Kreatywno tych autorw w jaki sposb
stymuluje moje wasne kreatywne cieki tworzce oprogramowanie.
Paczkowanie czasu i pomidory

Jedn z bardzo skutecznych technik zarzdzania czasem i skupieniem jest doskonale znana
technika pomidora2 (ang. pomodoro technique). Sam pomys jest bardzo prosty. Nastawiasz
standardowy czasomierz kuchenny (tradycyjne maj ksztat pomidora) na 25 minut. W czasie
gdy czasomierz odlicza, nie pozwalasz, eby cokolwiek przeszkadzao Ci w tym, co robisz.
Jeeli zadzwoni telefon, odbierz i zapytaj, czy moesz oddzwoni w cigu 25 minut. Jeeli
kto bdzie chcia zada Ci pytanie, grzecznie popro, eby zada je za 25 minut. Niezalenie
od tego, co Ci przeszkadza, po prostu przesu to do momentu, a czasomierz zadzwoni.
W kocu mao ktra sprawa jest a tak pilna, e nie moe poczeka 25 minut.
http://www.pomodorotechnique.com/.
144
U NIKI
Gdy czasomierz zadzwoni, natychmiast przerywasz to, co aktualnie robisz. Zajmujesz si

wszystkimi sprawami, ktre zostay przesunite w trakcie ostatniego pomidora. Nastpnie
robisz sobie 5-minutow przerw. Potem znowu nastawiasz czasomierz i zaczynasz
kolejnego pomidora. Po czterech pomidorach robisz sobie dusz przerw mniej
wicej 30-minutow.
Na temat tej techniki napisano ju cakiem sporo i zachcam Ci do poczytania o niej.
Ju jednak podany wyej opis powinien da Ci jej oglny zarys.
Stosujc t technik, dzielisz swj czas na czas pomidora i czas bez pomidora. Czas pomidora
jest czasem produktywnym. To wanie podczas kadego pomidora wykonujesz rzetelnie
swoj prac. Poza pomidorami s tylko spotkania, przerwy i inne zajcia, ktre nie
przyczyniaj si do realizacji Twoich zada.
Ile pomidorw moesz przerobi jednego dnia? Dobrego dnia moe Ci si uda zrobi
nawet 12 lub 14 pomidorw. Jeeli zdarzy si gorszy dzie, to by moe zdoasz zrobi
zaledwie dwa lub trzy. Jeeli zaczniesz liczy pomidory, to szybko dowiesz si, jak cz
dnia spdzasz na produktywnych zajciach, a ile czasu powicasz na inne rzeczy.
Niektrym ta technika spodobaa si tak bardzo, e szacuj pracochonno zada
w pomidorach, a swoj wydajno mierz w pomidorach na tydzie. To jednak tylko
wisienka na torcie. Prawdziw zalet techniki pomidora jest to 25-minutowe okno
produktywnie spdzonego czasu, ktrego agresywnie bronisz przed jakimikolwiek
wtrceniami.
Uniki
Czasami najzwyczajniej w wiecie nie masz serca do pracy. By moe wynika to z tego,
e zadanie, ktre na Ciebie czeka, jest tak straszne, nieprzyjemne albo po prostu nudne.
Moe sdzisz, e zadanie to popchnie Ci w kierunku niechcianej konfrontacji albo zapdzi
w kozi rg. A moe po prostu nie masz ochoty na akurat t prac.
Odwrcenie priorytetw
Niezalenie od powodu zawsze znajdziesz jaki sposb na unikanie faktycznej pracy.
Przekonujesz si, e co jest o wiele waniejsze, i tym wanie si zajmujesz. Takie dziaanie
jest nazywane odwrceniem priorytetw. Podnosisz priorytet jednego zadania tylko po to,
eby opni wykonanie zadania o faktycznie wyszym priorytecie. Odwrcenie priorytetw
jest kamstwem, ktrym sami siebie mamimy. Nie moemy znie tego, co trzeba zrobi,
dlatego przekonujemy si, e inne zadanie jest waniejsze. Wiemy, e tak nie jest, ale i tak
wmawiamy sobie co innego.
145
R OZDZIA 9.
Z ARZDZANIE CZASEM
Cho tak naprawd wcale si nie okamujemy. Tak naprawd przygotowujemy sobie tylko
kamstwo na wypadek, gdy kto nas zapyta, co i dlaczego bdziemy dzisiaj robi. Tworzymy
sobie w ten sposb ochron przed ocen innych.
Jak mona si domyla, nie jest to zachowanie profesjonalne. Profesjonalici oceniaj
priorytet poszczeglnych zada, nie uwzgldniajc przy tym osobistych lkw i pragnie,
a nastpnie wykonuj te zadania w odpowiedniej kolejnoci.
lepe uliczki
lepe uliczki s czci ycia kadego twrcy oprogramowania. Czasami podejmuje si
decyzj, ktra kieruje nas na technologiczn ciek prowadzc donikd. Im bardziej
jestemy zwizani ze swoj decyzj, tym gbiej wchodzimy w t dzicz. Jeeli na szali way
si Twoja reputacja profesjonalisty, to z raz obranej cieki nie zejdziesz ju nigdy.
Roztropno i dowiadczenie pozwol Ci unika niektrych lepych uliczek, ale nigdy nie
uda Ci si przed nimi uciec. Dlatego wanie potrzebna jest Ci umiejtno szybkiego
rozpoznawania takich sytuacji i odwaga, eby si z nich wycofa. Czasami jest to nazywane
regu dziury: gdy si w jakiej znajdziesz, przesta kopa.
Profesjonalici staraj si nie przywizywa do idei tak mocno, e pniej nie s w stanie
jej porzuci i pody inn ciek. Staraj si mie umys otwarty na inne pomysy,
by po zabrniciu w lep uliczk mie jakie inne rozwizania.
Marsze, bagna i baagan

Od lepych uliczek gorszy jest jednak baagan. Kady baagan Ci spowalnia, cho nigdy
cakiem Ci nie zatrzymuje. Baagan utrudnia posuwanie si naprzd, ale przy odpowiedniej
determinacji postpy nadal s moliwe. Baagan jest gorszy od lepej uliczki, poniewa
zawsze widzisz w nim drog prowadzc naprzd, ktra dodatkowo sprawia wraenie
krtszej ni droga powrotna (cho to zudne wraenie).
Widziaem ju, jak baagan w oprogramowaniu niszczy produkty i cae firmy. Widziaem,
jak produktywno zespow w kilka miesicy zmieniaa si z szybkiego jazzu w marsz
aobny. Nic poza baaganem nie ma tak dugofalowego i negatywnego wpywu na
produktywno zespou programistw. Naprawd nic.
Problem polega na tym, e tworzenia baaganu nie da si unikn, podobnie jak nie da si
unika lepych uliczek. Dowiadczenie i ostrono pomagaj troch je omija, ale w kocu
i tak podejmiesz decyzj, w wyniku ktrej powstanie jaki baagan.
Rozwj takiego baaganu jest dobrze zakamuflowany. Tworzysz rozwizanie jakiego prostego
problemu, starajc si, eby powstajcy kod by prosty i czysty. Gdy zakres i zoono tego
146
W NIOSKI
problemu rosn, starasz si rozbudowywa istniejcy kod i nadal jak najlepiej utrzymywa
jego czysto. W pewnym momencie uwiadamiasz sobie, e podjta ju na samym
pocztku decyzja bya bdna i dlatego kod nie skaluje si dobrze wraz z napywaniem
kolejnych wymaga.
To jest wanie krytyczny moment! Moesz zawrci i poprawi projekt, ale moesz te
brn dalej. Zawrcenie w tym momencie wydaje si kosztowne, poniewa zmusza Ci
do przebudowy istniejcego kodu, ale ju nigdy pniej zawrcenie nie bdzie tak atwe
jak teraz. Jeeli zdecydujesz si brn dalej, to zmienisz system w bagno, z ktrego moesz
si ju nigdy nie wydosta.
Profesjonalici obawiaj si baaganu duo bardziej ni lepych uliczek. Zawsze szukaj
miejsc, w ktrych baagan zaczyna narasta, i nie szczdz rodkw na jak najwczeniejsz
ucieczk od niego.
Dalsze posuwanie si w takim bagnie, jeeli wiesz, e to jest bagno, to najgorszy z moliwych
przykad odwrcenia priorytetw. Prc naprzd, oszukujesz siebie, swj zesp, swoj
firm i swoich klientw. Mwisz im, e wszystko bdzie w porzdku, podczas gdy wsplnie
zmierzacie ku zagadzie.
Wnioski
Profesjonalni programici staraj si jak najlepiej zarzdza swoim czasem i moliwociami
koncentracji. Znaj pokusy wynikajce z odwrcenia priorytetw, a ich zwalczanie staje si
dla nich spraw honoru. Nie zamykaj si na inne rozwizania, ale staraj si mie otwarty
umys. Nie przywizuj si za bardzo do jednego rozwizania, tak eby nie mie oporw przed
jego porzuceniem. Cay czas wypatruj te rosncego baaganu i staraj si jak najszybciej
posprzta wypatrzone miejsca. Nie ma smutniejszego widoku ni zesp programistw
bezproduktywnie walczcych z coraz gbszym bagnem.
147
R OZDZIA 9.
Z ARZDZANIE CZASEM
148
10
S ZACOWANIE
Szacowanie jest jednym z najprostszych i jednoczenie najbardziej przeraajcych dziaa,

z ktrymi zmierzy si musi profesjonalny programista. Uzalenione s przecie od niego
wielkie pienidze, a take nasza reputacja. Powoduje ono wiele naszych strachw i poraek.
Szacowanie jest gwn koci niezgody panujcej midzy menederami a programistami.
Jest te rdem wszelkiego braku zaufania wpywajcego na ten zwizek.
W 1978 roku byem gwnym programist 32-kilobajtowego programu dla procesora Z-80,
pisanego w asemblerze. Program ten by zapisywany na 32 ukadach EEPROM o pojemnoci
1 KB. Wszystkie 32 ukady scalone byy nastpnie umieszczane na trzech pytkach
drukowanych, z ktrych kada moga pomieci do 12 takich ukadw.
149
R OZDZIA 10.
S ZACOWANIE
Obsugiwalimy wtedy setki urzdze zainstalowanych w centralach telefonicznych

w caych Stanach Zjednoczonych. Gdy tylko poprawialimy jaki bd albo dodawalimy
now funkcj, musielimy wysya serwisantw do kadego urzdzenia, eby wymienili
wszystkie 32 ukady!
To by prawdziwy koszmar. Zarwno ukady, jak i same pytki byy do delikatne.
Nki scalakw wyginay si i odamyway. Cige wyginanie pytek drukowanych mogo
spowodowa uszkodzenia lutw. Ryzyko powstania uszkodze i bdw byo ogromne.
A koszt takich dziaa dla naszej firmy by o wiele za wysoki.
Mj szef Ken Finder zapyta mnie wtedy, czy nie da si czego w tym wszystkim poprawi.
Chcia, ebym wymyli jaki sposb na wprowadzanie zmian do jednego ukadu bez
koniecznoci jednoczesnej wymiany wszystkich pozostaych. Jeeli czytasz moje ksiki
albo suchasz moich wykadw, to wiesz, jak bardzo zachcam do stosowania niezalenego
rozmieszczania komponentw. To wtedy dostaem pierwsz lekcj.
Problemem naszego oprogramowania byo to, e powstawao jako jeden wielki plik
wykonywalny. Jeeli do programu zosta dodany nowy wiersz, to wszystkie adresy
z kolejnych wierszy musiay zosta zmienione. Niestety, kady ukad mieci przestrze
adresow o wielkoci zaledwie 1 K, dlatego przy kadej zmianie programu zmieniaa si
zawarto niemal wszystkich ukadw.
Rozwizanie tego problemu byo cakiem proste. Kady ukad musia zosta oddzielony
od pozostaych. Kady z nich musia sta si niezalenym elementem kompilacji, ktry
mona by zapisywa niezalenie od pozostaych.
Zmierzyem zatem wielkoci wszystkich funkcji naszej aplikacji i napisaem prosty program
dopasowujcy je jak ukadank do poszczeglnych ukadw, pozostawiajc w kadym z nich
mniej wicej 100 bajtw wolnego miejsca na rozbudow. Na pocztku kadego ukadu
umieciem tablic wskanikw do wszystkich funkcji zapisanych w tym ukadzie. W czasie
rozruchu urzdzenia wskaniki te byy przenoszone do pamici RAM. Cay kod w systemie
zosta zmieniony tak, eby funkcje byy wywoywane wycznie przez te wskaniki rezydujce
w pamici, ale nigdy bezporednio.
Dokadnie tak. Ukady stay si obiektami z tablicami metod wirtualnych. Wszystkie funkcje
byy uruchamiane polimorficznie. I w ten sposb poznaem kilka zasad projektowania
obiektowego, jeszcze zanim dowiedziaem si, czym jest obiekt.
Zyski z tej zmiany byy ogromne. Moglimy wysya do serwisantw tylko pojedyncze
ukady, ale co waniejsze, moliwe stao si wprowadzanie poprawek w dziaajcych
systemach przez przeniesienie funkcji do pamici RAM i zmian wektora wywoania.
Dziki temu debugowanie i wprowadzanie poprawek u klienta stao si o wiele atwiejsze.
Odchodz jednak od tematu. Gdy Ken prosi mnie o rozwizanie tego problemu, wspomnia
co o wskanikach do funkcji. Jaki dzie lub dwa zajo mi sformalizowanie tego pomysu,
150
C ZYM JEST SZACOWANIE ?
a potem przedstawiem mu szczegowy plan. Zapyta, jak dugo potrwa wprowadzanie

tych zmian, a ja odpowiedziaem, e zajmie mi to jaki miesic.
Prace trway cae trzy miesice.
W caym swoim yciu pijany byem dwa razy, a tylko raz spiem si cakowicie. Byo to
w czasie przyjcia boonarodzeniowego firmy Teradyne w 1978 roku. Miaem wtedy 26 lat.
Przyjcie odbywao si w biurze firmy, ktre skadao si gwnie z otwartych przestrzeni
laboratoriw. Wszyscy przyjechali do firmy wczenie, a potem przysza potna burza niena,
ktra uniemoliwiaa przyjazd zamwionego zespou i firmy kateringowej. Na szczcie
mielimy sporo alkoholu.
Z tej nocy pamitam bardzo mao. A to, co zapamitaem, wolabym raczej zapomnie.
Przedstawi Ci jednak pewien wany moment.
Siedziaem na pododze ze skrzyowanymi nogami obok Kena (mojego szefa, ktry w tym
czasie mia 29 lat i nie by pijany), jczc o tym, jak dugo zajmuje mi praca nad wektoryzacj
wywoa. Alkohol uwolni moje skrywane dotychczas obawy i niepewno co do moich
szacunkw. Nie sdz, e pooyem gow na jego kolanach, ale takie szczegy nie zachoway
si w mojej pamici.
Pamitam jednak, e spytaem go, czy jest na mnie wcieky i czy sdzi, e caa ta operacja
zajmuje za wiele czasu. Mimo e z caej tej nocy pamitam niewiele, to jednak jego odpowied
zapisaa mi si w pamici na stae. Powiedzia: Tak, uwaam, e zajmuje ci to strasznie
duo czasu, ale widz te, e ciko nad tym pracujesz i robisz cige postpy. To jest co,
co jest nam bardzo potrzebne. I nie, nie jestem wcieky.
Czym jest szacowanie?

Problem polega na tym, e nasze szacunki traktujemy zupenie odmiennie. Kadra
menederska patrzy na nie jak na zobowizania, natomiast programici traktuj je raczej
jak przypuszczenia. A rnica midzy tymi znaczeniami jest ogromna.
Zobowizanie
Zobowizanie jest czym, czego musisz dotrzyma. Jeeli zobowizujesz si wykona
co do wyznaczonego dnia, to po prostu musisz to zrobi do tego czasu. Jeeli oznacza to,
e musisz pracowa 12 godzin dziennie, w weekendy i zrezygnowa z rodzinnego urlopu,
to tak musi by. Podejmujc zobowizanie, musisz go dotrzyma.
Profesjonalici nie podejmuj zobowiza, chyba e dokadnie wiedz, e mog ich
dotrzyma. To naprawd jest takie proste. Jeeli prosz Ci o zobowizanie si do czego,
a Ty nie masz pewnoci, czy bdziesz w stanie to zrobi, to najlepiej bdzie odmwi.
151
R OZDZIA 10.
S ZACOWANIE
Jeeli prosz Ci o zobowizanie si do czego, a Ty wiesz, e to jest moliwe, ale bdzie

wymagao dugich nadgodzin, weekendu i rezygnacji z urlopu, to tylko do Ciebie naley
decyzja. Ale lepiej przygotuj si na te wszystkie powicenia.
Zobowizania wymagaj pewnoci. Inni ludzie, przyjmujc Twoje zobowizanie, zaczn na
jego podstawie tworzy wasne plany. Koszt niedotrzymania zobowizania bdzie ogromny
zarwno dla nich, jak i dla Twojej reputacji. Niedotrzymanie zobowizania jest rodzajem
nieuczciwoci, tylko troch mniej nieprzyjemnym od samego kamstwa.
Szacunek
Szacunek jest tak naprawd tylko przypuszczeniem. Nie ma nic wsplnego ze zobowizaniem.
Nie wie si z obietnicami. Nietrafienie z szacunkiem nie jest adn ujm na honorze.
Powodem, dla ktrego tworzymy szacunki, jest to, e nie wiemy, jak dugo trwa bdzie
dane zadanie.
Niestety, wikszo programistw zupenie nie umie szacowa. Nie chodzi o przyswojenie
sobie jakiej tajnej umiejtnoci szacowania nic takiego nie istnieje. Powodem naszych
bdnych szacunkw jest to, e nie znamy natury szacowania.
Szacunek nie jest liczb, ale rozkadem. Pomyl prosz:
Mike: Kiedy wedug twoich szacunkw zakoczysz to zadanie?.
Peter: Za trzy dni.
Czy Peter naprawd zrobi wszystko w cigu trzech dni? Moliwe, ale jak bardzo
prawdopodobne? Odpowied brzmi: nie mamy zielonego pojcia. Co Peter mia na myli,
a czego dowiedzia si Mike? Czy Mike bdzie zaskoczony za trzy dni, jeeli Peter nie
bdzie jeszcze gotowy? Niby dlaczego miaby by? Przecie Peter do niczego si nie
zobowizywa. Nie powiedzia mu jednak te, jak bardzo prawdopodobne jest zakoczenie
prac w trzy dni w porwnaniu z czterema albo picioma dniami.
Co si stanie, gdy Mike zapyta Petera o prawdopodobiestwo sprawdzenia si jego
trzydniowego szacunku?
Mike: Jakie s szanse na to, e skoczysz w cigu trzech dni?.
Peter: Cakiem spore.
Mike: Moesz jako je okreli?.
Peter: Pidziesit, szedziesit procent.
Mike: Czyli istnieje niemaa szansa, e zajmie to nawet cztery dni.
Peter: No tak, to moe potrwa nawet pi do szeciu dni, cho w to akurat wtpi.
Mike: Jak bardzo wtpisz?.
152
C ZYM JEST SZACOWANIE ?
Peter: No nie wiem. Jestem na 95% pewien, e zrobi wszystko przed upywem
szeciu dni.
Mike: Czyli moe si to przecign do siedmiu dni?.
Peter: Tylko jeeli wszystko naraz pjdzie le. Rany, jeeli wszystko pjdzie le,
to moe mi zaj nawet dziesi lub jedenacie dni. Ale taki natok nieszcz
nie jest za bardzo moliwy.
Teraz zaczynamy zblia si do prawdy. Szacunek Petera jest rozkadem prawdopodobiestwa.
Peter widzi prawdopodobiestwo ukoczenia zadania w sposb przedstawiony na rysunku 10.1.
Rysunek 10.1. Rozkad prawdopodobiestwa
Teraz ju wiemy, dlaczego Peter poda swj pierwotny trzydniowy szacunek. Na wykresie
trzeci dzie ma najwyszy supek. A zatem dla Petera jest to najbardziej prawdopodobny
czas trwania zadania. Mike widzi to jednak nieco inaczej. Patrzy na praw stron wykresu
i martwi si tym, e Peterowi prace mog zaj nawet jedenacie dni.
Czy Mike powinien si tym martwi? Oczywicie! Murphy1 zawsze znajdzie jaki sposb
na Petera, a zatem co na pewno pjdzie nie tak.
Ukryte zobowizania
Teraz Mike ma problem. Nie ma pewnoci, ile czasu zajmie Peterowi wykonanie zadania.
eby zmniejszy t niepewno, moe poprosi Petera o jakie zobowizanie. Ale jest to co,
czego Peter nie moe mu da.
1
Prawo Murphyego mwi, e jeeli co moe pj le, to na pewno pjdzie le.
153
R OZDZIA 10.
S ZACOWANIE
Mike: Peter, moesz mi poda konkretn dat zakoczenia prac?.

Peter: Niestety nie. Jak ju mwiem, prawdopodobnie cao zakocz w trzy,
moe cztery dni.
Mike: Moemy zatem powiedzie, e cztery?.
Peter: Nie, bo cao moe potrwa pi lub sze dni.
Jak na razie wszyscy zachowuj si fair. Mike prosi o zobowizanie, a Peter ostronie
odmwi. W zwizku z tym Mike prbuje innego podejcia:
Mike: No dobra, moesz jednak sprbowa zrobi to w nie wicej ni sze dni?.
Proba Mikea brzmi do niewinnie, a on zapewne nie ma te zych intencji. Ale tak
naprawd, to czego Mike da od Petera? Jak ma wyglda to prbowanie?
Mwiem ju o tym w rozdziale 2. Sowo prbowa ma wiele znacze. Jeeli Peter zgodzi
si sprbowa, to zobowie si do zakoczenia prac w sze dni. Nie mona tego inaczej
interpretowa. Zgoda na prbowanie jest zgod na zakoczenie prac.
Jak inaczej mona to interpretowa? Co waciwie Peter ma zamiar zrobi w ramach
prbowania? Czy bdzie pracowa wicej ni osiem godzin? Taka jest jasna implikacja.
Czy bdzie musia pracowa w weekendy? To rwnie si narzuca. Czy bdzie musia
zrezygnowa z urlopu? Owszem, to te si pod tym kryje. Te wszystkie rzeczy s czci
prbowania. Jeeli Peter nie zrobi tych rzeczy, to Mike bdzie mg oskary go
o niedostateczne starania.
Zawodowcy jasno odrniaj szacunki od zobowiza. Nie zobowizuj si, chyba e na
pewno wiedz, i osign sukces. Staraj si te nie bra na siebie ukrytych zobowiza.
Jak najwyraniej staraj si przedstawi rozkad prawdopodobiestwa swoich szacunkw,
aby menederowie mogli odpowiednio przygotowa plany.
PERT
W 1957 roku zostaa utworzona technika PERT (Program Evaluation and Review
Technique technika oceny i rozwoju programw) majca wspomaga projekt polarnej
odzi podwodnej dla U.S. Navy. Jednym z elementw tej techniki jest sposb obliczania
szacunkw. Przygotowano wtedy bardzo prost, a jednoczenie skuteczn metod
przeksztacania szacunkw w rozkady prawdopodobiestwa prezentowane menederom.
Szacujc pracochonno zadania, podajesz trzy wartoci. Nazywane jest to analiz trzech
zmiennych:
O: Szacunek optymistyczny ta warto powinna by bardzo optymistyczna.
Zakoczenie zadania w tym czasie powinno by moliwe jedynie wwczas, gdy absolutnie
154
PERT
wszystko udaoby si bez problemw. Caa procedura bdzie miaa sens tylko wtedy,
gdy prawdopodobiestwo prawidowoci tego szacunku bdzie wynosio okoo 1%2.
W przypadku Petera, zgodnie z rysunkiem 10.1, powinien to by jeden dzie.
N: Szacunek normalny to szacunek z najwikszym prawdopodobiestwem. Jeeli
narysowalibymy wykres, to miaby on najwyszy supek. Wedug rysunku 10.1 byyby

to trzy dni.
P: Szacunek pesymistyczny tutaj rwnie powinna by to bardzo pesymistyczna ocena.
Powinna obejmowa wszystko z wyjtkiem huraganw, wojny nuklearnej, zabkanej

czarnej dziury i tym podobnych katastrof. Cao zadziaa, jeeli prawdopodobiestwo
tej oceny bdzie mniejsze ni 1%. Zgodnie z wykresem Petera byoby to 12 dni.
Mamy ju te trzy szacunki, wic moemy obliczy rozkad prawdopodobiestwa,
wykorzystujc ponisze wzory:
O 4N P
6
Warto jest tutaj oczekiwanym czasem trwania zadania. W przypadku Petera bdzie
to (1 + 12 + 12)/6, czyli jakie 4,2 dnia. W przypadku wikszoci zada bdzie to warto
nieco pesymistyczna, poniewa prawa strona rozkadu prawdopodobiestwa zawsze jest
bardziej rozcignita od lewej3.
P O
6
Warto jest odchyleniem standardowym4 rozkadu prawdopodobiestwa dla danego

zadania. Jest miar niepewnoci danego zadania. Jeeli warto ta jest dua, to dua jest
te niepewno. W przypadku Petera wynosi ona (12 1)/6, czyli jakie 1,8 dnia.
Otrzymujc od Petera szacunek 4,2/1,8 Mike wie, e zadanie najpewniej zostanie wykonane
w cigu 5 dni, ale moe te zaj 6, a nawet 9 dni.
Mike nie zajmuje si jednak tylko tym jednym zadaniem. Zarzdza projektem skadajcym
si z wielu rnych zada. Peter otrzyma trzy z nich, ktre musz by wykonywane
w okrelonej kolejnoci. Peter przygotowa dla tych zada szacunki przedstawione
w tabeli 10.1.
Dokadna warto w przypadku rozkadu normalnego to 1:769 albo 0,13% albo 3 sigma.
Prawdopodobiestwo jeden do tysica jest ju cakiem bezpieczne.
PERT zakada, e przypomina to rozkad beta. To cakiem dobre zaoenie, poniewa minimalny
czas trwania zadania czsto jest bardziej pewny ni czas maksymalny. [McConnell2006], rysunek 1.3.
Jeeli nie wiesz, czym jest odchylenie standardowe, to znajd dobry podrcznik do rachunku
prawdopodobiestwa i statystyki. To pojcie jest cakiem atwe do ogarnicia, a bywa niezwykle
przydatne.
155
R OZDZIA 10.
S ZACOWANIE
Tabela 10.1. Zadania Petera

Zadanie
Optymistyczne
Normalne
Pesymistyczne
Alfa
12
4,2
1,8
Beta
1,5
14
3,5
2,2
Gamma
6,25
11
6,5
1,3
Nie sdzisz, e zadanie beta jest troch dziwne? Wyglda na to, e Peter ma spor
pewno co do czasu ukoczenia, ale moe zdarzy si co, co bardzo utrudni mu prac.
Jak Mike powinien to zinterpretowa? Jaki czas ma on zaplanowa na ukoczenie
wszystkich trzech zada przez Petera?
Okazuje si, e za pomoc kilku prostych oblicze Mike moe poczy wszystkie zadania
Petera i wyznaczy rozkad prawdopodobiestwa caego zestawu zada. Obliczenia te s
naprawd nieskomplikowane:
sekwencji zadania
W przypadku dowolnej sekwencji zada oczekiwany czas jej trwania jest prost sum
oczekiwanych czasw trwania wszystkich zada z tej sekwencji. A zatem skoro Peter
mia do wykonania trzy zadania o szacunkach 4,2/1,8; 3,5/2,2 i 6,5/1,3, to prawdopodobnie
uda mu si zakoczy je wszystkie w 14 dni: 4,2 + 3,5 + 6,5.
sekwencji
2
zadania
Standardowe odchylenie caej sekwencji jest pierwiastkiem kwadratowym sumy

kwadratw standardowych odchyle poszczeglnych zada. Oznacza to, e standardowe
odchylenie wszystkich trzech zada Petera wynosi mniej wicej 3.
(1,82 + 2,22 + 1,32)1/2 =
(3,24 + 2,48 + 1,69)1/2 =
9,771/2 = ~3,13
Dziki temu Mike wie, e zadania Petera zajm najpewniej 14 dni, ale cakiem moliwe jest
te, e bdzie on na nie potrzebowa 17 dni (1), a istnieje te prawdopodobiestwo 20 dni
(2). Wszystkie zadania mog zaj te jeszcze wicej czasu, ale to akurat jest bardzo mao
prawdopodobne.
Przyjrzyj si jeszcze raz tabeli z wszystkimi szacunkami. Czujesz ch zakoczenia wszystkich
trzech zada w pi dni? W kocu optymistyczne szacunki to 1, 1 i 3 dni. Nawet szacunki
normalne sumuj si do zaledwie 10 dni. W jaki sposb cao urosa do 14 dni z moliwoci
dalszego wzrostu do 17 lub 20? Ot wskanik niepewnoci poszczeglnych zada sprawia,
e cay plan nabiera realizmu.
156
S ZACOWANIE ZADA
Jeeli masz troch wicej ni kilka lat dowiadcze w programowaniu, to z pewnoci zdarzyo
Ci si widzie projekty, ktre pocztkowo szacowano bardzo optymistycznie, a potem
zajmoway trzy do piciu razy wicej czasu. Przedstawiona tu prosta technika PERT jest
jedn z metod pozwalajcych na unikanie zbyt optymistycznych oczekiwa. Profesjonalni
programici staraj si definiowa bardzo rozsdne oczekiwania mimo naciskw, eby
sprbowa dziaa szybko.
Szacowanie zada
Mike i Peter popenili straszliwy bd. Mike pyta Petera, jak dugo potrwaj jego zadania.
Peter poda mu szczere szacunki, ale zapomnieli o opiniach pozostaych czonkw zespou.
By moe bd mieli inne pomysy.
Najwaniejszym z dostpnych Ci narzdzi do szacowania zada s otaczajcy Ci ludzie.
Oni mog zobaczy co, co Ty przeoczysz. To oni mog pomc Ci przygotowa dokadniejsze
szacunki.
Wideband Delphi
W latach 70. XX wieku Barry Boehm zaprezentowa technik szacowania, ktr nazwa
wideband delphi5. Pniej przez lata powstao wiele jej odmian. Niektre s bardziej
formalne, a inne zupenie nieformalne, ale wszystkie maj pewn cech wspln: konsensus.
Sama strategia jest prosta. Zesp si zbiera, omawia zadanie, szacuje je i powtarza
ca dyskusj i szacowanie tak dugo, a zostanie osignite porozumienie.
Pierwotna metoda opisana przez Boehma wymagaa przynajmniej kilku spotka
i dokumentw, co jak na mj gust wizao si ze zbyt wielkim ceremoniaem
i przygotowaniami. Wol jednak stosowa rozwizania z niewielk nadmiarowoci
nakadu pracy, takie jak ponisze.
Latajce palce
Wszyscy siedz wok stou i omawiaj po kolei wszystkie zadania. Rozmawiaj o tym,
co jest zwizane z kadym zadaniem, co moe je skomplikowa i jak mona je
zaimplementowa. Uczestnicy spotkania umieszczaj swoje rce pod stoem i podnosz
od zera do piciu palcw w zalenoci od wasnej oceny czasochonnoci zadania.
Prowadzcy spotkanie liczy 1, 2, 3 i wszyscy naraz pokazuj swoje rce.
[Boehm81].
157
R OZDZIA 10.
S ZACOWANIE
Jeeli wszyscy si na to zgodz, to przechodz do nastpnego zadania, a jeeli nie,

to dyskutuj dalej, by ustali przyczyn swojej niezgody. Cao powtarza si tak dugo,
a zostanie uzyskany konsensus.
Zgoda nie musi by cakowita. Wystarczy, e poszczeglne szacunki nie bd si od
siebie bardzo rniy. Na przykad mieszank trjek i czwrek rwnie mona uzna za
porozumienie. Jeeli jednak wszyscy podnosz cztery palce, a jedna osoba pokazuje tylko
jeden palec, to jest o czym rozmawia.
Skal szacunkw ustala si zaraz na pocztku spotkania. Moe to by liczba dni
przeznaczonych na realizacj zadania, ale mona te ustali ciekawsz skal typu:
liczba palcw razy 3 albo liczba palcw do kwadratu.
Wane jest to, e wszyscy musz jednoczenie pokaza swoje palce. Nie chcemy,
eby poszczeglne osoby zmieniay szacunki na podstawie ocen pozostaych.
Planujcy poker
W 2002 roku James Grenning napisa wspaniay artyku6 opisujcy planujcego pokera
(ang. planning poker). Ten wariant techniki wideband delphi sta si tak popularny,
e kilka rnych firm wykorzystao go do przygotowania materiaw marketingowych
w postaci talii kart do planujcego pokera7. Istnieje nawet strona internetowa o nazwie
planningpoker.com, za pomoc ktrej mona przeprowadzi sesj planowania
z rozproszonym zespoem.
Idea jest bardzo prosta. Kady czonek zespou dostaje zestaw kart z rnymi numerami.
Liczby od 0 do 5 sprawdzaj si cakiem dobrze, a jednoczenie cay system jest wtedy
rwnoznaczny z latajcymi palcami.
Wybierane jest zadanie i zaczyna si dyskusja. W pewnym momencie prowadzcy prosi
wszystkich o wybranie karty. Czonkowie zespou wybieraj kart odpowiadajc ich ocenie
i trzymaj j tak, eby nikt nie widzia wybranej liczby. Nastpnie prowadzcy nakazuje
wszystkim pokaza swoje karty.
Reszta dziaa dokadnie tak samo jak latajce palce. Jeeli wszyscy si zgadzaj, to szacunek
jest przyjmowany, w przeciwnym wypadku karty wracaj do zestaww, a gracze do dyskusji.
Wybieranie waciwych kart do zestawu stao si ju cakiem osobn dziedzin nauki.
Niektrzy poszli ju tak daleko, e uywaj kart odpowiadajcych cigowi Fibonacciego.
Inni dodali jeszcze karty ze znakami nieskoczonoci i zapytania. Osobicie uwaam,
e karty o oznaczeniach 0, 1, 3, 5, 10 powinny wystarczy.
6
[Grenning2002].
http://store.mountaingoatsoftware.com/products/planning-poker-cards.
158
P RAWO WIELKICH LICZB
Szacowanie pokrewiestwa
Szczeglnie ciekaw wariacj techniki wideband delphi zaprezentowa mi kilka lat temu
Lowell Lindstrom. Rozwizanie to dobrze sprawdzio si kilka razy z rnymi klientami
i zespoami.
Wszystkie zadania s zapisane na kartach bez adnych szacunkw dotyczcych
pracochonnoci. Zesp szacujcy stoi wok stou albo przy cianie, na ktrej karty
s poprzyczepiane losowo. Czonkowie zespou nie rozmawiaj ze sob, ale po prostu
sortuj karty wzgldem siebie. Dusze zadania wdruj na prawo, a krtsze na lewo.
Kady czonek zespou moe w dowolnym momencie przesun dowoln kart,
nawet jeeli zostaa ona ju przesunita przez kogo innego. Kada karta przesunita
wicej ni razy jest odkadana na bok do omwienia.
Ostatecznie ciche sortowanie kart si koczy i mona rozpocz dyskusj. Omawiane
s rnice zda co do kolejnoci uoenia kart. Szybkie sesje projektowania albo rcznie
rysowane diagramy mog uatwi uzyskanie konsensusu.
Nastpnym krokiem jest rysowanie linii pomidzy kartami, ktre reprezentuj grupy
rozmiarw liczone w dniach, tygodniach albo punktach. Tradycyjnie stosuje si pi grup
zgodnych z cigiem Fibonacciego (1, 2, 3, 5, 8).
Szacunki trjwartociowe
Przedstawione tu techniki sprawdzaj si przy wybieraniu normalnych szacunkw
poszczeglnych zada. Jak jednak wspominaem wczeniej, najczciej chcemy uzyska
trzy wartoci szacunkw pozwalajce na okrelenie rozkadu prawdopodobiestwa.
Optymistyczny i pesymistyczny szacunek kadego zadania mona szybko okreli za
pomoc kadego z przedstawionych wariantw techniki wideband delphi. Na przykad
stosujc technik planujcego pokera, wystarczy poprosi o podniesienie kart z szacunkiem
pesymistycznym, a potem optymistycznym.
Prawo wielkich liczb

Szacunki zawsze s obarczone bdem. To wanie dlatego nazywa si je szacunkami.
Jedn z metod radzenia sobie z takimi bdami jest wykorzystanie prawa wielkich liczb8.
Z tego prawa wynika, e jeeli jedno wielkie zadanie podzielimy na kilka mniejszych
i oszacujemy je niezalenie od siebie, to suma tych szacunkw bdzie dokadniejsza
od szacunku dotyczcego tego wielkiego zadania. Powodem zwikszenia dokadnoci
jest to, e bdy w mniejszych zadaniach maj tendencj do znoszenia si wzajemnie.
8
http://pl.wikipedia.org/wiki/Prawo_wielkich_liczb.
159
R OZDZIA 10.
S ZACOWANIE
Oczywicie to optymistyczne podejcie. Bdy w szacunkach zwykle s zwizane

z niedoszacowaniem, a rzadziej z przeszacowaniem, dlatego wzajemne znoszenie si
bdw nigdy nie jest doskonae. Mimo to podzielenie wielkiego zadania na kilka
mniejszych i szacowanie ich niezalenie od siebie nadal sprawdza si doskonale. Cz
bdw faktycznie si wzajemnie zniesie, a samo podzielenie zadania sprawia, e lepiej
poznajemy jego szczegy i odkrywamy ewentualne puapki.
Wnioski
Profesjonalni programici wiedz, jak przedstawi swoim przeoonym szacunki, ktre
ci mog wykorzysta do planowania. Nie skadaj obietnic, ktrych nie mog dotrzyma,
i nie bior na siebie zobowiza, jeeli nie maj pewnoci, czy bd w stanie ich dotrzyma.
Gdy profesjonalista bierze na siebie zobowizanie, to podaje mocne dane i si z niego
wywizuje. W wikszoci przypadkw profesjonalici nie bior takich zobowiza, ale
podaj probabilistyczne szacunki opisujce oczekiwany czas ukoczenia zadania i moliw
wariancj.
Profesjonalni programici wsppracuj z innymi czonkami swojego zespou i wsplnie
staraj si okreli szacunki zada, ktre pniej przedstawi menederom.
Techniki opisane w tym rozdziale s przykadami rnych metod wykorzystywanych przez
programistw do tworzenia szacunkw. Nie s to jedyne takie techniki i niekoniecznie s
najlepsze z moliwych. S to techniki, ktre sprawdziy si w mojej pracy.
Bibliografia
[McConnell2006]: Steve McConnell, Software Estimation: Demystifying the Black Art,
Redmond, WA: Microsoft Press, 2006.
[Boehm81]: Barry W. Boehm, Software Engineering Economics, Upper Saddle River, NJ:
Prentice Hall, 1981.
[Grenning2002]: James Grenning, Planning Poker or How to Avoid Analysis Paralysis
while Release Planning, kwiecie 2002, http://renaissancesoftware.net/papers/14-papers/
44-planing-poker.html.
160
11
P RESJA
Wyobra sobie, e dowiadczasz fenomenu przebywania poza ciaem, obserwujesz siebie

na stole operacyjnym w czasie, gdy chirurg wykonuje operacj na Twoim otwartym sercu.
Ten chirurg stara si uratowa Twoje ycie, ale czasu jest mao, dlatego musi zdy przed
pewnym ostatecznym terminem. I ten termin naprawd jest ostateczny.
Jak wyobraasz sobie zachowanie tego lekarza? Chcesz, eby zachowa spokj i rozsdek?
Chcesz, eby wydawa swojemu zespoowi jasne i precyzyjne polecenia? Chcesz, eby
postpowa zgodnie z wyuczonymi procedurami i wedug najlepszych zasad swojego zawodu?
161
R OZDZIA 11.
P RESJA
Czy moe raczej wolisz, eby poci si i przeklina? Chcesz, eby rozbija i rozrzuca swoje
narzdzia? Chcesz, eby obwinia zarzd o nierealistyczne oczekiwania i cigle narzeka na
brak czasu? Chcesz, eby zachowywa si jak profesjonalista, czy jak typowy programista?
Profesjonalny programista pod presj jest spokojny i zdecydowany. Gdy presja wzrasta,
odwouje si do swojego wyszkolenia i swojej dyscypliny, wiedzc, e to najlepsza metoda
na dotrzymanie terminw i zobowiza.
W 1988 roku pracowaem w firmie Clear Communications. By to typowy start-up, ktry
nigdy tak naprawd nie wystartowa. Przebrnlimy przez pierwsze kopoty finansowe,
a zaraz potem pojawiy si kolejne, i jeszcze jedne.
Pocztkowa wizja produktu wygldaa bardzo obiecujco, ale nigdy nie udao si nam
odpowiednio zdefiniowa jego architektury. Najpierw produkt mia skada si zarwno
z oprogramowania, jak i ze sprztu. Potem przeksztaci si w samo oprogramowanie.
Platforma dla tego oprogramowania zmienia si z komputerw PC na Sparc. Potencjalni
klienci zmienili si z bogatych firm w odbiorc masowego. Ostatecznie nawet cel naszego
produktu zmieni si, poniewa firma szukaa czegokolwiek, co wygenerowaoby zyski.
W cigu niemal czterech lat, ktre spdziem w tej firmie, nie zobaczya ona chyba nawet
grosza przychodu.
Nie musz zatem nadmienia, e pracujcy w niej programici znajdowali si pod cig
presj. Przed terminalem w biurze spdzilimy wiele bardzo dugich nocy, a nawet jeszcze
duszych weekendw. Pisalimy w jzyku C funkcje o dugoci 3000 wierszy. Pojawiay si
awantury z wykrzykiwanymi obelgami. Czsto knuto intrygi i planowano podstpy. Pici
przebijay ciany, dugopisy rzucone w gniewie odbijay si od tablic, na cianach pojawiay
si wydrapane karykatury nielubianych kolegw. Ten strumie stresu i gniew nigdy si nie
koczyy.
Terminy byy wyznaczane przez okrelone wydarzenia. Poszczeglne funkcje miay by
gotowe na targi albo prezentacje dla klientw. Na nastpn prezentacj musielimy mie
gotowe wszystko, o co poprosi klient, niewane, jak gupie to byy dania. Zawsze
brakowao nam czasu i zawsze mielimy jakie zalegoci. Tworzone plany przyprawiay
o zawrt gowy.
Jeeli pracowae 80 godzin w tygodniu, moge zasuy na miano bohatera. Takim samym
bohaterem mona byo zosta po przygotowaniu jakiego paskudnego kodu na prezentacj
dla klienta. Jeeli kto si dostatecznie stara, mg dosta awans. Jeeli kto si nie stara,
wylatywa na bruk. To by prawdziwy start-up i chodzio tylko o wypracowane wartoci.
I w 1988 roku, mimo 20 lat dowiadczenia, wsiadem do tego wzka.
Byem jednym z menederw informujcych pracujcych dla mnie programistw, e musz
pracowa szybciej i wicej. Byem jednym z tych pracujcych po 80 godzin wyrobnikw,
tworzcych liczce 3000 wierszy funkcje w C o 2 nad ranem, podczas gdy moje dzieci spay
162
U NIKANIE PRESJI
w domu bez opieki ojca. Byem jednym z krzyczcych i rzucajcych dugopisami wciekych
ludzi. Wyrzucaem ludzi z pracy, jeeli nie chcieli si dopasowa. To by koszmar. Ja sam
byem koszmarem.
Potem nadszed dzie, w ktrym moja ona zmusia mnie do spojrzenia w lustro. Nie
spodobao mi si to, co w nim zobaczyem. Powiedziaa mi, e przebywanie ze mn nie jest
przyjemne, i musiaem si z ni zgodzi. Ale wcale mi si to nie podobao, dlatego wcieky
wybiegem z domu, zaczem chodzi po okolicy bez adnego celu. aziem tak jakie p
godziny, gotujc si ze zoci. I wtedy zaczo pada.
I co w mojej gowie si przeczyo. Zaczem si mia. miaem si ze swojej wasnej
gupoty. miaem si ze swojego stresu, z czowieka, ktrego zobaczyem w lustrze, a ktry
uprzykrza ycie sobie i swoim bliskim w imi czego?
Tego dnia wszystko si zmienio. Przestaem robi tak szalone nadgodziny i zakoczyem
ycie w wielkim stresie. Przestaem rzuca dugopisami i pisa gigantyczne funkcje w C.
Stwierdziem, e bd cieszy si swoj karier, wykonujc swoj prac dobrze, a nie gupio.
Odszedem z tej pracy tak profesjonalnie, jak tylko mogem, i zostaem konsultantem.
Od tego dnia nigdy nikogo nie nazwaem ju szefem.
Unikanie presji
Najlepszym sposobem na uzyskanie spokoju mimo presji jest unikanie sytuacji powodujcych
presj. Takie uniki zapewne nie zlikwiduj presji cakowicie, ale pozwol na zminimalizowanie
i skrcenie tych nieprzyjemnych okresw.
Zobowizania
Jak ju mwiem w rozdziale 10., wane jest, eby nie zobowizywa si do dotrzymywania
terminw, ktrych nie jestemy cakowicie pewni. Menederowie zawsze nastaj na tego
typu zobowizania, poniewa eliminuj one ryzyko. Naszym zadaniem jest kwantyfikacja
tego ryzyka i przedstawienie go menederom, tak eby mogli nim odpowiednio zarzdza.
Przyjmowanie nierealistycznych zobowiza niweczy ten cel, a zatem nie suy ani nam,
ani naszym przeoonym.
Czasami zobowizania s przenoszone na nas. Okazuje si, e menederowie potrafi zoy
klientowi obietnice, nawet si z nami nie konsultujc. W takiej sytuacji honor nakazuje nam
pomc menederom wywiza si ze zobowizania. Trzeba jednak pamita, e honor wcale
nie nakazuje nam go zaakceptowa.
To bardzo wana rnica. Profesjonalici zawsze wspomagaj menederw w poszukiwaniu
sposobu osignicia celu. Ale jednoczenie niekoniecznie przyjmuj na siebie zobowizania
163
R OZDZIA 11.
P RESJA
zoone w ich imieniu. Moe si przecie okaza, e nie ma adnego sposobu na dotrzymanie
zoonej obietnicy, a wtedy osoba skadajca tak obietnic musi przyj na siebie
odpowiedzialno za ni.
atwo powiedzie. Jeli firma si chwieje, a Twoje wypaty s opniane z powodu
niedotrzymanych zobowiza, trudno nie ulega presji. Jeeli jednak zachowujesz si
profesjonalnie, to przynajmniej moesz zacz szuka nowej pracy z podniesion gow.
Utrzymanie czystoci
Sposobem na szybki rozwj projektu i dotrzymywanie wszystkich terminw jest odpowiednie
utrzymanie czystoci. Profesjonalici nie poddaj si pokusie tworzenia baaganiarskiego
kodu tylko po to, eby robi to szybciej. Profesjonalici wiedz doskonale, e wyraenie
szybko i paskudnie to oksymoron. Paskudny kod zawsze oznacza spowolnienie!
Moemy unika presji, utrzymujc nasz system, kod i projekt w jak najlepszym stanie.
Nie oznacza to, e mamy spdza godziny na polerowaniu kodu. To znaczy tylko tyle,
e nie powinnimy tolerowa baaganu. Wiemy, e baagan nas spowalnia, przez co nie
dotrzymujemy terminw i amiemy dane sowo. A zatem staramy si, eby wyniki naszej
pracy byy tak schludne, jak tylko si da.
Dyscyplina kryzysowa
Obserwujc swoje zachowania w czasie kryzysu, moesz stwierdzi, w co naprawd wierzysz.
Jeeli podczas kryzysu przestrzegasz swojej dyscypliny, to znaczy, e naprawd wierzysz
w jej skuteczno. Jeeli jednak w czasie kryzysu zmieniasz sposb postpowania, to znaczy,
e tak naprawd nie uznajesz swoich normalnych zachowa za skuteczne.
Jeeli podczas normalnej pracy stosujesz metodologi TDD, ale porzucasz j w czasie kryzysu,
to nie uznajesz jej za naprawd uyteczn. Jeeli w spokojnych czasach utrzymujesz w swoim
kodzie porzdek, ale gdy tylko pojawia si kryzys, dopuszczasz powstanie baaganu, to znaczy,
e nie wierzysz w to, e baagan moe Ci spowolni. Jeeli w kryzysie programujesz w parach,
ale normalnie tego nie robisz, to uznajesz, e programowanie w parach jest skuteczniejsze
od programowania solo.
Wybierz rozwizania, ktre uznasz za skuteczne w czasie kryzysu, a potem stosuj je przez
cay czas. Wykorzystywanie tych rozwiza w normalnej pracy jest najlepszym sposobem
na unikanie kryzysu.
Nie zmieniaj te swojego zachowania w czasie, gdy pojawia si presja. Jeeli Twoje
rozwizania s najlepszym sposobem pracy, to naley ich przestrzega rwnie podczas
najgbszego kryzysu.
164
J AK RADZI SOBIE Z PRESJ
Jak radzi sobie z presj

Unikanie i agodzenie presji z ca pewnoci s dobrymi metodami, ale czasami presja
dopada nas mimo naszych najlepszych intencji i zabiegw. Czasami projekt trwa duej,
ni ktokolwiek mg przypuszcza. Czasami pierwotny projekt okazuje si bdny i musi
zosta przebudowany. Czasami tracimy wartociowego czonka zespou albo klienta.
Czasami podejmujemy zobowizania, ktrych nie jestemy w stanie dotrzyma. Co robi
w takiej sytuacji?
Nie panikuj
Opanuj stres. Bezsenne noce nie pomog Ci w szybszej pracy. Podobnie nie pomoe Ci
siedzenie i zamartwianie si. A najgorsze, co moesz zrobi, to zacz si spieszy! Za wszelk
cen opieraj si tej pokusie. Popiech wpdzi Ci tylko gbiej w bagno.
Zdecydowanie lepiej bdzie zwolni. Jeszcze raz przemyle problem. Zaplanowa kurs na
najlepsze z moliwych rozwiza, a nastpnie poda w tym kierunku w staym i rozsdnym
tempie.
Informuj
Poinformuj swj zesp i przeoonego o kopotach. Przedstaw im swj plan wybrnicia
z nich i popro o uwagi i wskazwki. Unikaj niespodzianek. Poza niespodziankami chyba
nic nie wprawia ludzi w wikszy gniew i nie prowokuje do mniej racjonalnych zachowa.
Niespodzianki dziesiciokrotnie zwikszaj presj.
Polegaj na swoich metodach

Gdy robi si ciko, polegaj na swoich metodach pracy. Powodem, dla ktrego stosujesz
te metody, jest to, e pomagaj Ci one w czasach duej presji. To wanie wtedy naley
szczeglnie uwanie trzyma si sprawdzonych rozwiza. To nie jest odpowiedni czas,
eby je kwestionowa i porzuca.
Zamiast panicznie poszukiwa czegokolwiek, co mogoby pomc szybciej wykona prac,
jeszcze dokadniej zacznij postpowa zgodnie z przyjtymi metodami. Jeeli stosujesz
TDD, to pisz jeszcze wicej testw jednostkowych ni zwykle. Jeeli bezwzgldnie
refaktorujesz kod, to jeszcze mocniej si do tego przy. Jeeli piszesz niewielkie funkcje,
to pisz jeszcze mniejsze. Jedyn metod na wybrnicie z tego kocioka jest poleganie na tym,
co ju wiesz, e dziaa na swoich sprawdzonych metodach pracy.
165
R OZDZIA 11.
P RESJA
Sprowad pomoc
Programuj w parach! Gdy grunt zaczyna si pali, znajd kogo, kto zechce programowa
z Tob w parze. Zadanie ukoczysz szybciej, z mniejsz liczb bdw. Twj partner uatwi
Ci trzymanie si staych metod pracy i powstrzyma Twoj panik. Twj partner zauway
szczegy, ktre umkn Tobie, bdzie mia ciekawe pomysy, a kiedy si zdekoncentrujesz,
bdzie mg przej paeczk.
Natomiast gdy kto inny ma kopoty, zaproponuj mu programowanie w parach. Pom
mu wydosta si z doka.
Wnioski
Podstawow sztuk radzenia sobie z presj jest unikanie jej, gdy tylko to moliwe. Gdy
jednak nas dopadnie, trzeba jako j przetrwa. Presji mona unika przez odpowiednie
dobieranie zobowiza, przestrzeganie uznanych metod pracy i utrzymywanie czystego
kodu. Presj mona przetrwa, zachowujc spokj, informujc o istniejcej sytuacji,
przestrzegajc metod pracy i proszc o pomoc.
166
12
W SPPRACA
Wikszo oprogramowania jest tworzona przez zespoy. Zespoy dziaaj najskuteczniej,

gdy ich czonkowie profesjonalnie ze sob wsppracuj. Nieprofesjonalne jest bycie
w zespole odludkiem i samotnikiem.
W 1974 roku miaem 22 lata. Moje maestwo z cudown Ann Marie trwao zaledwie sze
miesicy. Dopiero za rok miao si urodzi moje pierwsze dziecko: Angela. W tym czasie
pracowaem w oddziale firmy Teradyne znanym jako Chicago Laser Systems.
Razem ze mn pracowa mj kolega ze szkoy Tim Conrad. W ramach naszej wsppracy
przygotowalimy kilka maych cudw. W jego piwnicy budowalimy razem komputery.
W mojej piwnicy zbudowalimy drabin Jakuba. Nauczylimy si programowa PDP-8
i czy ukady scalone i tranzystory tak, eby powsta kalkulator.
167
R OZDZIA 12.
W SPPRACA
Bylimy programistami pracujcymi nad systemem wykorzystujcym laser do bardzo

dokadnego dopasowania parametrw elementw elektronicznych, takich jak oporniki
i kondensatory. Na przykad przygotowalimy kryszta do pierwszego cyfrowego zegarka
Motoroli Pulsar.
Programowalimy wtedy na komputerze M365, ktry by klonem PDP-8 uywanym
w firmie Teradyne. Pisalimy programy w asemblerze, a wszystkie pliki przechowywalimy
na tamach magnetycznych. Oczywicie moglimy edytowa programy na ekranie, ale byo
to do uciliwe, dlatego wikszo naszego kodu czytalimy i wstpnie poprawialimy
na wydrukach.
Nie mielimy adnych funkcji pozwalajcych na przeszukiwanie istniejcego kodu. Nie byo
sposobu na znalezienie wszystkich miejsc, w ktrych bya wywoywana dana funkcja albo
uywana okrelona staa. Jak moesz sobie wyobrazi, nie uatwiao nam to pracy.
Pewnego dnia Tim i ja postanowilimy, e napiszemy sobie generator referencji. Program
powinien odczytywa dane z tamy i wypisywa wszystkie symbole z podaniem pliku
i wiersza, w ktrych dany symbol by uywany.
Pierwotny program napisalimy cakiem szybko. Nie by szczeglnie skomplikowany.
Po prostu odczytywa dane z tamy, parsowa skadni asemblera, tworzy tabel symboli
i do poszczeglnych pozycji dopisywa referencje. Dziaao to wietnie, ale niestety
okropnie wolno. Ponad godzin zajmowaa programowi analiza naszego gwnego
programu operacyjnego (Master Operating Program MOP).
Cao dziaaa tak wolno dlatego, e rosnc tabel symboli przechowywalimy w jednym
buforze pamici. Po znalezieniu kadej nowej referencji dopisywalimy j do bufora,
przesuwajc pozostae dane w d o kilka bajtw.
Ani Tim, ani ja nie bylimy ekspertami od struktur danych i algorytmw. Nigdy nie
syszelimy o tablicach mieszajcych i przeszukiwaniu binarnym. Nie mielimy pojcia,
jak mona usprawni algorytm. Wiedzielimy tylko, e to, co zrobilimy, byo za wolne.
Prbowalimy zatem jednej rzeczy za drug. Prbowalimy umieszcza referencje w listach.
Prbowalimy pozostawia w tablicy przerwy i przesuwa dane w buforze, gdy te przerwy
zostay zapenione. Prbowalimy tworzy listy takich przerw. Wyprbowalimy dziesitki
szalonych pomysw.
Stalimy przed tablic w biurze, rysowalimy diagramy naszych struktur danych i robilimy
obliczenia, prbujc przewidzie wydajno. Codziennie przychodzilimy do biura z jakim
nowym pomysem. Wsppracowalimy ze sob jak szaleni.
Cz z naszych prb faktycznie podniosa wydajno. Cz raczej j zmniejszya. To
doprowadzao nas do szewskiej pasji. Wtedy pierwszy raz dowiedziaem si, jak trudno
optymalizuje si oprogramowanie i jak nieintuicyjny jest to proces.
168
P ROGRAMICI KONTRA LUDZIE
Ostatecznie udao nam si osign czas poniej 15 minut, co byo czasem zblionym do
tego, ile zajmowao proste przeczytanie tamy z kodem. Bylimy zatem cakiem zadowoleni.
Programici kontra ludzie

Nie zostalimy programistami, poniewa tak bardzo lubimy pracowa z innymi ludmi.
Z reguy uwaamy, e relacje interpersonalne s zagmatwane i nieprzewidywalne. Lubimy
czyste i przewidywalne zachowania maszyn, ktre programujemy. Najszczliwsi jestemy
wtedy, gdy moemy zamkn si sami w pokoju i skoncentrowa nad jakim bardzo
interesujcym problemem.
Tak, to ogromna generalizacja, od ktrej istnieje wiele wyjtkw. Jest wielu programistw,
ktrzy dobrze sobie radz, wsppracujc z innymi ludmi, i nawet wietnie si przy tym
bawi. Jednak rednia naszej grupy pasuje raczej do przedstawionego na pocztku obrazu.
My, programici, lubimy delikatn deprywacj sensoryczn i zanurzenie si w stanie skupienia.
Programici kontra pracodawcy

W latach siedemdziesitych i osiemdziesitych, gdy pracowaem jako programista w firmie
Teradyne, stwierdziem, e jestem naprawd dobry w debugowaniu. Uwielbiaem takie
wyzwania i rzucaem si na problemy peen wigoru i entuzjazmu. Przede mn nie ukry si
aden bd!
Gdy udao mi si wyeliminowa kolejny bd, czuem si jak zwycizca, jakbym zabi
Jabberwocka! Szedem wtedy do mojego szefa Kena Findera, w rce trzymajc Vorpala,
i z pasj opowiadaem, jaki interesujcy bd znalazem. Pewnego dnia Ken krzykn na
mnie: Bdy nie s interesujce. Je trzeba po prostu usun!.
Tego dnia czego si nauczyem. Dobrze jest z pasj wykonywa swoje zadania, ale dobrze
jest te mie na oku cele ludzi, ktrzy Ci pac.
Podstawowym zadaniem profesjonalnego programisty jest spenianie wymaga
przedstawionych przez pracodawc. Oznacza to wspprac z menederami, analitykami
biznesowymi, testerami i pozostaymi czonkami zespou, by dogbnie pozna cele firmy
i projektu. Nie oznacza to, e musisz zosta firmowym kujonem. Wane jest jednak, eby
dobrze wiedzie, dlaczego piszesz kod, ktry wanie piszesz, i w jaki sposb zatrudniajca
Ci firma na tym kodzie skorzysta.
Najgorsz rzecz, jak moe zrobi profesjonalny programista, jest zagrzebanie si
w grobowcu technologii, podczas gdy naokoo niego caa firma wali si i ponie. Twoim
zadaniem jest utrzymanie firmy na powierzchni!
169
R OZDZIA 12.
W SPPRACA
Oznacza to, e profesjonalny programista powica czas na poznanie swojej firmy i brany,
w ktrej ona dziaa. Rozmawia z klientami o uywanym przez nich oprogramowaniu.
Rozmawia z ludmi z dziau sprzeday i marketingu o trapicych ich problemach. Rozmawia
z ich menederami, chcc pozna krtko- i dugoterminowe cele zespou.
Mwic krtko, profesjonalni programici interesuj si statkiem, ktrym przyszo im pyn.
Jedyny raz, kiedy wyrzucono mnie z pracy zwizanej z programowaniem, mia miejsce
w 1976 roku. W tym czasie pracowaem w firmie Outboard Marine Corp. Pomagaem
w niej pisa system automatyzacji fabryki wykorzystujcy komputery IBM System/7
do monitorowania dziesitek maszyn do odlewu aluminium, ktre pracoway na hali.
Pod wzgldem technicznym bya to bardzo wymagajca, ale te wdziczna praca.
Architektura komputerw System/7 bya fascynujca, a i sam system automatyzacji
fabryki by bardzo ciekawy.
Mielimy te bardzo dobry zesp. Jego kierownik John by zarwno kompetentny, jak
i zmotywowany, natomiast moi dwaj koledzy programici mili i pomocni. Pracowalimy
w laboratorium specjalnie przygotowanym na potrzeby tego projektu. Nasz biznesowy
partner bardzo zaangaowa si z nami w prace laboratoryjne. Nasz meneder Ralph by
kompetentny, skoncentrowany i rzeczywicie mia wadz.
Wszystko powinno byo dziaa doskonale. To ja byem problemem. Bardzo entuzjastycznie
podchodziem do caego projektu i do uywanej w nim technologii. Niestety, w podeszym
wieku 24 lat nie byem w stanie zmusi si do zainteresowania sam firm i jej wewntrzn
polityczn struktur.
Pierwszy bd popeniem ju pierwszego dnia. Pojawiem si w pracy bez krawata. Miaem
krawat w czasie rozmowy kwalifikacyjnej i widziaem wtedy, e wszyscy nosili krawaty,
ale jako nie wycignem odpowiednich wnioskw. Pierwszego dnia Ralph podszed do
mnie i po prostu powiedzia: W tej firmie nosimy krawaty.
Nie mog nawet wyrazi, jak bardzo tego nie znosiem. Mczyo mnie to straszliwie.
Codziennie nosiem krawat i nienawidziem tego. Ale dlaczego? Przecie wiedziaem,
w co si pakuj. Znaem konwencje panujce w tej firmie. Dlaczego miabym si denerwowa?
Tylko dlatego, e byem samolubnym, narcystycznym maym palantem.
Po prostu nie mogem dotrze do pracy na czas i sdziem, e nie ma to znaczenia. W kocu
robiem dobr robot. To prawda, naprawd doskonale wywizywaem si z zadania
polegajcego na pisaniu programw. Mog powiedzie, e byem najlepszym programist
w zespole. Umiaem pisa kod szybciej i lepiej ni pozostali koledzy. Byem w stanie szybciej
rozwizywa rne problemy. Wiedziaem, e jestem dla firmy wartociowy, i dlatego nie
liczyy si dla mnie terminy i czas.
170
P ROGRAMICI KONTRA LUDZIE
Decyzja o zwolnieniu mnie zapada pewnego dnia, gdy nie zjawiem si na czas podczas
prezentacji kolejnego kamienia milowego. Najwyraniej John powiedzia nam wszystkim,
e w przyszy poniedziaek chce zobaczy prezentacj dziaajcych funkcji systemu. Jestem
pewien, e o tym wiedziaem, ale takie terminy nie byy dla mnie szczeglnie istotne.
System nadal by aktywnie rozwijany i nie zosta wprowadzony do produkcji. Nie byo
powodu, eby dziaa, skoro nikogo nie byo w laboratorium. Byem chyba ostatni osob
wychodzc w pitek do domu i najwyraniej pozostawiem system w stanie nienadajcym
si do uycia. Fakt, e w poniedziaek bdzie tak wany, po prostu wylecia mi z gowy.
W poniedziaek spniem si godzin i zobaczyem, jak wszyscy stoj zebrani nad
niedziaajcym systemem. John zapyta mnie: Bob, dlaczego system dzisiaj nie dziaa?.
Odpowiedziaem: Nie mam pojcia. Usiadem i zaczem szuka przyczyny. Nadal nic
mi nie witao na temat poniedziakowej prezentacji, ale z mowy ciaa wszystkich zebranych
wnioskowaem, e co jest mocno nie w porzdku. Wtedy John podszed do mnie i szepn
mi do ucha: A co by byo, gdyby Stenberg postanowi nas odwiedzi?. A potem odszed
zniesmaczony.
Stenberg by wiceprezesem firmy odpowiedzialnym za automatyzacj. Dzisiaj cieszyby si
tytuem CIO. Zadane pytanie nie miao dla mnie adnego sensu. No i co? pomylaem.
Przecie system nie jest jeszcze w produkcji, co za rnica?.
Pniej tego dnia dostaem pierwszy list z ostrzeeniem. Informowa mnie, e musz zmieni
swoje nastawienie albo konieczne bdzie szybkie wypowiedzenie. Byem naprawd
przeraony!
Troch czasu zajo mi przeanalizowanie swojego zachowania i uwiadomienie sobie,
co waciwie robiem le. Rozmawiaem na ten temat z Johnem i Ralphem. Byem
zdeterminowany, eby zmieni siebie i swj stosunek do pracy.
I udao mi si! Przestaem si spnia. Zaczem zwraca uwag na wewntrzn polityk
firmy. Zaczem rozumie, dlaczego John tak bardzo obawia si Stenberga. W kocu
zobaczyem, w jak trudnej sytuacji go postawiem, unieruchamiajc cay system przed
feralnym poniedziakiem.
Niestety, to wszystko byo za mao i za pno. Koci zostay ju rzucone. Miesic pniej
dostaem drugi list z ostrzeeniem za trywialny bd, jaki mi si przytrafi. Ju wtedy
powinienem by zauway, e te listy s tylko formalnoci, a decyzja o zwolnieniu mnie
zostaa ju podjta. Ale byem zdeterminowany, eby ratowa sytuacj, dlatego zaczem
pracowa jeszcze ciej.
Spotkanie, na ktrym zostaem zwolniony, miao miejsce kilka tygodni pniej.
Poszedem do domu do mojej 22-letniej, ciarnej ony i musiaem jej powiedzie,
e straciem prac. Nie jest to dowiadczenie, ktre chciabym kiedykolwiek powtrzy.
171
R OZDZIA 12.
W SPPRACA
Programici kontra programici

Programici czsto maj problemy ze cis wspprac z innymi programistami. Prowadzi
to do naprawd powanych problemw.
Wasno kodu
Jednym z najgorszych symptomw dysfunkcyjnego zespou jest sytuacja, w ktrej kady
programista tworzy mur otaczajcy jego kod i odmawia pozostaym prawa do zmian.
Bywaem w miejscach, w ktrych programici nie pozwalali innym nawet zobaczy swojego
kodu. To prosta recepta na katastrof.
Pewnego razu pracowaem jako konsultant dla firmy tworzcej drukarki najwyszej klasy.
Takie maszyny skadaj si z wielu rnych elementw, takich jak podajniki, drukarki,
sztaplarki, zszywarki, obcinarki itp. Firma inaczej wartociowaa kady z tych elementw.
Podajniki byy waniejsze od sztaplarek, ale nic nie byo waniejsze od samych drukarek.
Kady programista pracowa nad swoim urzdzeniem. Jedna osoba pisaa kod podajnika,
inna zajmowaa si kodem przeznaczonym dla sztaplarki. Kady z nich zazdronie strzeg
swoich technologii i uniemoliwia wprowadzanie zmian do swojego kodu. Polityczne
znaczenie, jakie mieli poszczeglni programici, byo zwizane bezporednio z wartoci
przypisywan przez firm poszczeglnym urzdzeniom. Programista pracujcy nad sam
drukark by nie do ruszenia.
To bya prawdziwa katastrofa dla caej technologii drukowania. Jako konsultant byem
w stanie stwierdzi, e caa masa kodu bya duplikowana, a interfejsy czce poszczeglne
moduy byy dokumentnie wypaczone. Mimo tego aden z moich argumentw nie by
w stanie przekona programistw (i samej firmy) do zmiany sposobu pracy. W kocu ich
wypaty byy powizane z wag obsugiwanych przez nich urzdze.
Wasno kolektywna
Zdecydowanie lepiej jest, gdy zostan zburzone mury wasnoci kodu, a sam kod stanie si
wasnoci caego zespou. Wol wsppracowa z zespoami, w ktrych kady programista
moe przejrze dowolny modu i wprowadzi do niego takie zmiany, jakie uzna za stosowne.
Chc, eby kod by wasnoci zespou, a nie jego czonkw.
Profesjonalni programici nie zabraniaj innym pracy nad swoim kodem. Nie buduj na
okoo niego murw. Staraj si raczej wsppracowa ze sob nad wsplnym rozwijaniem
systemu. Ucz si nawzajem, pracujc wsplnie nad rnymi czciami systemu.
Praca w parach
Wielu programistw nie lubi pracy w parach. Osobicie uwaam, e to dziwne, poniewa
wikszo programistw pracuje w parach w sytuacjach awaryjnych. Dlaczego?
172
M DKI
Najwyraniej jest to najefektywniejszy sposb rozwizywania problemw. Sprawdza si

tutaj stare powiedzenie: co dwie gowy, to nie jedna. Jeeli jednak praca w parach jest
najskuteczniejsza przy rozwizywaniu problemw w sytuacjach awaryjnych, to dlaczego
nie jest najskuteczniejszym sposobem rozwizywania problemw w ogle?
Nie mam zamiaru cytowa tutaj rnych bada, cho istniej takie, ktre warto byoby
zacytowa. Nie mam zamiaru opowiada adnych anegdot, cho istniej takie, ktre warto
byoby opowiedzie. Nie bd nawet opowiada o tym, jak bardzo warto jest programowa
w parach. Powiem tylko tyle, e profesjonalici pracuj w parach. Dlaczego? Poniewa
w przypadku przynajmniej czci problemw jest to najskuteczniejszy sposb ich
rozwizywania. Ale to niejedyny powd.
Profesjonalici pracuj w parach rwnie dlatego, e jest to najlepszy sposb dzielenia si
wiedz. Profesjonalici nie tworz zamknitych ogrodw wiedzy, ale poznaj rne czci
systemu, pracujc w parach. Wiedz doskonale, e cho kady czonek zespou ma w nim
swoj pozycj, to jednak kady powinien by w stanie natychmiast zaj pozycj innego
czonka.
Profesjonalici pracuj w parach, poniewa jest to najlepszy sposb na dokonanie inspekcji
kodu. aden system nie powinien zawiera kodu, ktry nie zosta przejrzany przez innych
programistw. Istnieje wiele sposobw na przeprowadzenie inspekcji kodu, a wikszo
z nich jest przeraajco nieefektywna. Najefektywniejsz i najskuteczniejsz metod inspekcji
kodu jest wsppraca przy jego pisaniu.
Mdki
Pewnego ranka 2000 roku, w samym rodku szalestwa dot comw, jechaem pocigiem
w Chicago. Wyszedem z wagonu na peron, gdzie zaatakowa mnie wielki billboard wiszcy
nad drzwiami wyjciowymi. Reklamowa on doskonale znan firm softwareow, ktra
zatrudniaa programistw. Przeczytaem na nim Przyjd i zetrzyj swj mdek z najlepszymi.
Od razu uderzy mnie poziom gupoty tak sformuowanego hasa. Biedni, niemajcy
zielonego pojcia ludzie z dziau reklamy prbowali przemawia do populacji technicznych,
inteligentnych i mdrych programistw. To przecie jest rodzaj ludzi nie najlepiej
znoszcych jakiekolwiek przejawy gupoty. Reklamodawcy prbowali przywoa obraz
wiedzy wspdzielonej z innymi inteligentnymi osobami. Niestety, odwoali si do tej
czci mzgu mdku, ktra zajmuje si kontrolowaniem mini i nie ma nic
wsplnego z inteligencj. A zatem ludzie, do ktrych kierowana bya ta reklama,
miali si z powodu tak idiotycznego bdu.
W billboardzie zaintrygowao mnie jednak co innego. Sprawi on, e zaczem wyobraa
sobie grup ludzi trcych swoje mdki. Jak wiadomo, mdek znajduje si w tylnej
czci mzgu, a zatem chcc pociera mdki, trzeba odwrci si do siebie plecami.
173
R OZDZIA 12.
W SPPRACA
Wyobraziem sobie zesp programistw pracujcych w boksach, siedzcych w ktach

plecami do siebie, patrzcych na ekrany, ze suchawkami na uszach. W ten sposb wanie
ciera si mdki. Ale nie tak wyglda zesp.
Profesjonalici pracuj razem. Nie mona ze sob pracowa, siedzc w ktach i ze suchawkami
na uszach. Chciabym, ebycie siedzieli wok stou twarz do siebie. Chc, ebycie mogli
podsucha pene frustracji mamrotanie kolegi. Chc widzie spontaniczn komunikacj,
zarwno werbaln, jak i niewerbaln. Chc, ebycie komunikowali si jako jedna cao.
Moesz sdzi, e pracujesz lepiej, siedzc samotnie. To moe by prawda, ale nie musi to
znaczy, e zesp pracuje lepiej w czasie, gdy Ty pracujesz samotnie. Poza tym raczej mao
prawdopodobne jest, e samotnie bdziesz w stanie rzeczywicie pracowa lepiej.
W pewnych okolicznociach samotna praca jest najwaciwszym rozwizaniem. W pewnych
okolicznociach po prostu musisz dugo i intensywnie rozmyla nad pewnym problemem.
Niekiedy zadanie jest tak trywialne, e praca z inn osob oznaczaaby tylko strat jej czasu.
Ale oglnie znacznie lepiej jest cile wsppracowa z innymi i czy si w pary przez
wiksz cz czasu.
Wnioski
By moe programowaniem nie zainteresowalimy si po to, eby pracowa z innymi ludmi.
Niestety, mamy pecha. Programowanie oznacza nieustann wspprac z innymi. Musimy
wsppracowa ze sob, a take z ca nasz firm.
Wiem, wiem. Czy nie byoby lepiej, gdyby po prostu zamknli nas w pokoju z szecioma
wielkimi ekranami, szybkim czem, bateri superszybkich procesorw, nielimitowan
pamici RAM i miejscem na dysku oraz nieskoczonym zapasem dietetycznej koli
i pikantnych chipsw? Przykro mi, ale tego si nie da zrobi. Jeeli naprawd chcemy
cae dnie spdza na programowaniu, to musimy nauczy si rozmawia z ludmi1.
Odniesienie do ostatnich sw z filmu Zielona poywka.
174
13
Z ESPOY I PROJEKTY
Co zrobi, jeeli musisz pracowa nad wieloma maymi projektami? Jak przydziela
te projekty programistom? A co w przypadku, gdy musisz si zaj tylko jednym
gigantycznym projektem?
175
R OZDZIA 13.
Z ESPOY I PROJEKTY
Mona to zmiksowa?
Przez lata pracowaem jako konsultant w wielu bankach i firmach ubezpieczeniowych.
Jedyn rzecz wspln dla wszystkich tych firm jest dziwaczny sposb dzielenia projektw.
W banku projekt jest czsto wzgldnie niewielk prac, wymagajc udziau jednego
programisty lub dwch przez kilka tygodni. Do takiego projektu zwykle przydzielany jest
meneder, ktry jednoczenie zajmuje si innymi projektami. Dorzuca si do tego analityka
biznesowego, ktry definiuje wymagania w kilku innych projektach. Poza tym do zespou
doczanych jest kilku programistw pracujcych rwnie w innych projektach. Na koniec
dodaje si testera lub dwch, ktrzy rwnie pracuj nad kilkoma projektami.
Ju widzisz, o co chodzi? Projekt jest zbyt may, eby pracujcy nad nim ludzie mogli
powici si mu w penym wymiarze. Kady pracuje nad projektem w 50 albo nawet 25%.
A teraz wana zasada: nie istnieje co takiego jak p osoby.
Bezsensem jest nakazywanie programicie przeznaczenia poowy jego czasu na projekt A,
a pozostaej czci na projekt B, szczeglnie wtedy, gdy oba te projekty maj rnych
menederw, analitykw biznesowych, programistw i testerw. W jakim wiecie mona
takiego potworka nazywa zespoem? To nie zesp, tylko efekt pracy blendera.
Zesp zespolony
Na sformowanie si zespou potrzeba czasu. Czonkowie zespou zaczynaj tworzy midzy
sob zwizki. Ucz si wsppracy, poznaj swoje silne i sabe strony. W ten sposb zesp
zaczyna si spaja.
W zintegrowanych zespoach jest co prawdziwie magicznego. Takie zespoy mog zdziaa
cuda. Ich czonkowie przewiduj wzajemnie swoje dziaania, wspieraj si i wymagaj od
siebie tego, co najlepsze. Takie zespoy naprawd sprawiaj, e co si dzieje.
Zespolony zesp skada si zwykle z mniej wicej tuzina osb. Moe by ich nawet
dwadziecia albo mog by jedynie trzy, ale zazwyczaj liczba czonkw zespou bliska jest
dwunastu. Zesp powinien skada si z programistw, testerw i analitykw. I powinien
mie menedera projektu.
Stosunek liczby programistw do testerw i analitykw moe si bardzo rni, ale dobr
proporcj jest 2:1. Oznacza to, e dobrze zespolony zesp moe si skada z siedmiu
programistw, dwch testerw, dwch analitykw i jednego menedera projektu.
Analityk definiuje wymagania i na ich podstawie pisze zautomatyzowane testy akceptacyjne.
Testerzy rwnie zajmuj si tworzeniem zautomatyzowanych testw akceptacyjnych.
176
M ONA TO ZMIKSOWA ?
Rnic midzy nimi jest inna perspektywa. Wszyscy zapisuj wymagania, ale analityk
koncentruje si na wartociach biznesowych, natomiast tester na poprawnoci. Analitycy
tworz optymistyczne cieki w testach, a testerzy zastanawiaj si nad tym, co moe pj
le, i pisz testy obejmujce bdy i przypadki brzegowe.
Meneder projektu ledzi postpy zespou i upewnia si, e zesp zna wszystkie priorytety
i harmonogramy.
Jeden z czonkw zespou moe przej rol trenera lub mistrza, ktrego odpowiedzialnoci
jest ochrona procesw i metod stosowanych przez zesp. Taka osoba ma by sumieniem
zespou, jeeli ten chciaby porzuci istniejce procesy w wyniku zwikszajcej si presji.
Fermentacja
Taki zesp potrzebuje czasu na zapoznanie si z wewntrznymi rnicami, pogodzenie
si z nimi i rzeczywiste spojenie. Ten proces moe potrwa sze miesicy, a nawet cay
rok. Ale gdy si zakoczy, dziej si cuda. Zespolony zesp zaczyna wsplnie planowa,
rozwizywa problemy, wsplnie stawia czoa przeciwnociom i praca posuwa si naprzd.
Gdy to si w kocu zdarzy, przestpstwem byoby rozbija ten ukad tylko dlatego, e koczy
si projekt. Znacznie lepiej jest utrzyma niezmieniony skad zespou i poszuka mu
odpowiedniego projektu.
Co byo pierwsze: zesp czy projekt?

Banki i firmy ubezpieczeniowe prboway tworzy zespoy na potrzeby projektw. To jednak
jest nierozsdne podejcie. Zespou nie da si szybko zintegrowa. Poszczeglne osoby
uczestnicz w projekcie przez krtki czas, powicajc mu tylko cz swojej uwagi, i dlatego
nigdy nie ucz si, jak ze sob wsppracowa.
Profesjonalne organizacje rozwojowe przypisuj projekty istniejcym ju zintegrowanym
zespoom, ale nie formuj zespow na potrzeby projektw. Zespolony zesp moe przyj
jednoczenie kilka rnych projektw i podzieli prace zgodnie z wasnym uznaniem
i umiejtnociami. Zespolony zesp na pewno sobie z takimi projektami poradzi.
Ale jak tego dokona?

Kady zesp ma swoje tempo1, ktre jest po prostu iloci pracy, jak moe on wykona
w okrelonym czasie. Niektre zespoy mierz swoje tempo w punktach na tydzie,
a punkty s jednostkami zoonoci. Poszczeglne funkcje aktualnie rozwijanego projektu
[PPP2002], s. 2022; [COHN2006], tu szukaj w indeksie wielu wietnych odniesie do tempa prac.
177
R OZDZIA 13.
Z ESPOY I PROJEKTY
s rozbijane na czci i kadej z nich jest przypisywany szacunek wyraony w punktach.

Nastpnie zesp mierzy, ile punktw uda si przerobi w cigu tygodnia.
Tempo jest miar statystyczn. Zesp moe w jednym tygodniu zrobi 38 punktw,
w kolejnym 42, a w nastpnym 25. Z czasem uzyska si pewn warto redni.
Menederowie mog wyznacza priorytety w kadym projekcie przydzielanym zespoowi.
Na przykad jeeli rednie tempo zespou wynosi 50, a pracuje on nad trzema projektami,
to meneder moe poprosi zesp o podzielenie nakadu pracy na 15, 15 i 20.
Zalet tego rozwizania, oprcz tego, e nad projektami pracuje zespolony zesp, jest to,
e w przypadkach awaryjnych mona powiedzie: Projekt B jest w tarapatach. Przez
nastpne trzy tygodnie powicajcie mu 100% swojej uwagi.
Taka zmiana priorytetw jest praktycznie niemoliwa w przypadku zespow, ktre wyszy
z blendera. Natomiast zespoy zintegrowane, ktre pracuj nad dwoma lub trzema projektami
jednoczenie, mog tego dokona bez adnego kopotu.
Dylemat waciciela projektu

Jednym z czstych argumentw przeciwko proponowanej przeze mnie metodzie jest to,
e waciciel projektu traci cz swojej wadzy i bezpieczestwa. Waciciele projektw,
ktrzy maj zesp przypisany do danego projektu, mog liczy na swj zesp. Wiedz
o tym, poniewa formowanie i rozbijanie zespou jest operacj bardzo kosztown, dlatego
firma nie odbierze im zespou z bahych powodw.
Jednak jeeli projekt zostanie przekazany zgranemu zespoowi, a zesp ten bdzie si
zajmowa kilkoma projektami jednoczenie, to firma nie bdzie miaa oporw przed zmian
priorytetw. To moe sprawia, e waciciel projektu nie bdzie pewny swojej przyszoci.
Zasoby, z ktrych korzysta, mog zosta mu nagle odebrane.
Osobicie wol jednak t drug sytuacj. Nie powinno si wiza firmie rk z powodu
sztucznej trudnoci formowania i rozwizywania zespow. Jeeli firma zdecyduje, e jeden
projekt jest waniejszy od drugiego, to powinna mie moliwo szybkiego transferu zasobw.
Zadaniem waciciela projektu jest odpowiednie reprezentowanie go.
Wnioski
Zespoy tworzy si trudniej ni projekty. Z tego powodu lepiej jest tworzy trwae zespoy,
ktre razem pracuj nad kolejnymi projektami i mog obsugiwa w danym czasie kilka
projektw. Celem formowania zespou jest przekazanie mu wystarczajcej iloci czasu na
zintegrowanie si. Pniej taki zesp nie powinien by rozbijany, poniewa jest on gotowy
na realizacj wielu projektw.
178
B IBLIOGRAFIA
Bibliografia
[COHN2006]: Mike Cohn, Agile Estimating and Planning, Upper Saddle River, NJ:
Prentice Hall, 2006.
179
R OZDZIA 13.
Z ESPOY I PROJEKTY
180
N AUCZANIE ,
14
TERMINOWANIE
I MISTRZOSTWO
Niezmiennie byem rozczarowany poziomem absolwentw studiw informatycznych.

Nie chodzi o to, e absolwenci nie s utalentowani i inteligentni, ale o to, e nie nauczono
ich, o co waciwie chodzi w programowaniu.
Stopnie niepowodzenia
Prowadziem kiedy rozmow kwalifikacyjn z mod kobiet studiujc informatyk na
wielkim uniwersytecie. Staraa si o letnie stanowisko staysty. Poprosiem j o napisanie
dla mnie prostego kodu, a ona odpowiedziaa: Ale ja tak naprawd nie pisz kodu.
181
R OZDZIA 14.
N AUCZANIE ,
TERMINOWANIE I MISTRZOSTWO
Prosz przeczyta poprzedni akapit ponownie, a potem od razu przej do nastpnego.

Zapytaem j, ktre zajcia z programowania wybraa, skoro chce uzyska tytu magistra
informatyki. Powiedziaa, e w swoim planie nie ma adnych tego rodzaju zaj.
Moe zechcesz zacz czyta ten rozdzia od pocztku, aby si upewni, e nie znajdujesz
si w jakim alternatywnym wszechwiecie albo w innym koszmarze.
W tym momencie mona zada sobie pytanie: jak student studiw magisterskich
z informatyki moe unika zaj z programowania? Wtedy zadaem sobie dokadnie
takie pytanie. Do dzisiaj nie znam na nie odpowiedzi.
Oczywicie to najpowaniejsze z caej serii rozczarowa, jakie spotkay mnie w czasie
rozmw z absolwentami uniwersytetw. Oczywicie nie wszyscy absolwenci s tak
rozczarowujcy, daleki jestem od tego stwierdzenia! Zauwayem jednak, e osoby
niesprawiajce rozczarowa maj pewn wspln cech: niemal wszystkie nauczyy si
programowa jeszcze przed rozpoczciem nauki na uniwersytecie i uczyy si tego nadal
mimo opuszczenia murw uczelni.
Prosz mnie le nie zrozumie. Uwaam, e na uniwersytecie mona uzyska doskonae
wyksztacenie. Uwaam jednak te, e mona przelizgn si przez ten system, uzyskujc
dyplom i nic ponad to.
Jest jeszcze jeden problem. Nawet najlepsze uniwersytety nie przygotowuj swoich
absolwentw na to, co spotka ich w naszej brany. Nie chc tu nikogo oskara, poniewa
jest to stan obejmujcy niemal wszystkie kierunki studiw. To, czego nauczysz si w szkole
i czego dowiadczysz w pracy, to dwie zupenie rne rzeczy.
Nauczanie
Jak mona si nauczy programowa? Opowiem Ci historyjk o byciu nauczanym.
Digi-Comp I, mj pierwszy komputer

W 1964 roku na moje dwunaste urodziny mama daa mi plastikowy komputer. Nazywa
si on Digi-Comp I1. Mia trzy plastikowe przeczniki i sze plastikowych bramek I.
Mona byo poczy wyjcia przecznikw z wejciami bramek, a nawet poczy wyjcia
bramek z wejciami przecznikw. W skrcie: pozwala on tworzy trjbitow, nieskoczon
maszyn stanw.
Jest wiele stron internetowych udostpniajcych symulatory tego maego stymulujcego komputera.
182
N AUCZANIE
W zestawie by te podrcznik prezentujcy kilka programw, ktre mona byo uruchamia.

Maszyn programowao si, wsuwajc mae rurki (kawaki rurek do napojw) na niewielkie
bolce wystajce z przecznikw. Podrcznik informowa, gdzie dokadnie naley umieci
poszczeglne rurki. Nie wspomina jednak o tym, co te rurki waciwie robiy. Byo to dla
mnie strasznie frustrujce!
Patrzyem na maszyn caymi godzinami, prbujc dowiedzie si, jak dziaa na poziomie
podstawowym. Nie byem jednak w stanie wykombinowa, jak zmusi j do robienia tego,
czego bym od niej chcia. Na ostatniej stronie podrcznika znalaza si informacja, e za
dolara przel mi podrcznik z informacj, jak programowa maszyn2.
Wysaem zatem dolara i czekaem z niecierpliwoci godn dwunastolatka. W dniu, gdy
w kocu zosta dostarczony, po prostu go pochonem. Bya to prosta rozprawka na temat
algebry Boolea opisujca podstawowe formy rwna, prawa cznoci i rozdzielnoci oraz
twierdzenia De Morgana. Podrcznik uczy, jak wyrazi dany problem w postaci sekwencji
rwna Boolea. Mwi te o tym, jak zredukowa te rwnania tak, eby pasoway do szeciu
bramek I.
Napisaem zatem swj pierwszy program. Nadal pamitam, jak go nazwaem: Komputerowa
brama Pana Pattersona. Napisaem rwnania, zredukowaem je i odwzorowaem na rurkach
i bolcach maszyny. I to dziaao!
Napisanie tych trzech sw sprawio, e przeszed mnie dreszcz. Taki sam, jaki przeszed
tego dwunastolatka prawie p wieku temu. Poknem haczyk. Moje ycie ju nigdy nie
bdzie takie jak dawniej.
Pamitasz moment, gdy Twj pierwszy program w kocu zadziaa? Czy to zmienio
Twoje ycie, umieszczajc je na kursie, z ktrego nie byo ju odwrotu?
Sam niczego tutaj nie rozgryzem. Zostaem tego nauczony. Jacy bardzo mili i bardzo
zdolni ludzie (wobec ktrych mam ogromny dug wdzicznoci) powicili czas na
napisanie rozprawy o algebrze Boolea, ktra bya zrozumiaa dla dwunastolatka. Poczyli
matematyczn teori z pragmatyk prostego, plastikowego komputera i pomogli mi zmusi
ten komputer do wykonywania zaplanowanych przeze mnie rzeczy.
Wanie wziem do rki kopi tego niezwykego podrcznika. Trzymam go w specjalnym
foliowym woreczku, a mimo to czas odcisn na nim swoje pitno. Kartki s ju poke
i stay si kruche. Niemniej jednak sia zapisanych w nim sw nadal jest ogromna. Elegancki
opis algebry Boolea zajmuje trzy krtkie strony. Omwienie poszczeglnych rwna
uytych w pierwotnych programach nadal jest bardzo zajmujce. To bya prawdziwie
mistrzowska praca. Praca, ktra zmienia ycie przynajmniej jednego modego mczyzny.
Obawiam si jednak, e nigdy nie poznam nazwisk jej autorw.
2
Nadal mam ten podrcznik. W mojej biblioteczce zajmuje honorowe miejsce.
183
R OZDZIA 14.
N AUCZANIE ,
ECP-18 w szkole redniej

W wieku lat pitnastu trafiem wanie do szkoy redniej. Bardzo lubiem wtedy przesiadywa
w dziale matematyki. (A to zaskoczenie!) Pewnego dnia wtoczyli do niego maszyn wielkoci
piy stoowej. By to ECP-18 komputer edukacyjny zbudowany specjalnie dla szk
rednich. W naszej szkole miaa si odbywa dwutygodniowa prezentacja.
Staem sobie z boku w czasie, gdy nauczyciele rozmawiali z technikami. Ta maszyna
ma 15-bitowe sowo (co to jest to sowo?) i 1024-sowow pami bbnow. (Wiedziaem,
co to jest pami bbnowa, ale znaem tylko ogln koncepcj).
Gdy w kocu wczyli maszyn, wydaa z siebie wysoki dwik przypominajcy start
odrzutowca. Sdziem, e wanie rozpdza si bben. Gdy ju si rozpdzi, cao dziaaa
wzgldnie cicho.
Ta maszyna bya wspaniaa. Byo to waciwie zwyczajne biurko, na ktrym znajdowa si
niesamowity panel sterowania, przypominajcy mostek pancernika. Na panelu wieciy
si cae rzdy lampek, a na nacinicie czekao wiele rnych klawiszy. Siedzenie przy tym
biurku byo jak zasiadanie w fotelu kapitana Kirka.
Przygldajc si technikom obsugujcym maszyn, zauwayem, e po naciniciu klawisza
zapala si on, a ponowne nacinicie powodowao gaszenie wiateka. Zauwayem te,
e naciskali pewne specjalne klawisze, ktre byy opisane deposit i run.
Klawisze w kadym wierszu zostay podzielone na pi grup po trzy. Mj Digi-Comp
rwnie by trzybitowy, wic mogem odczytywa wyraone dwjkowo cyfry semkowe.
Zrozumienie, e chodzi tu o pi cyfr semkowych, nie zajo mi duo czasu.
Syszaem, e technicy mamrocz co do siebie, wciskajc klawisze. Gdy wpisywali
liczby 1, 5, 2, 0, 4 do bufora pamici, mwili do siebie: Zapisz w 204. Wciskali klawisze
1, 0, 2, 1, 3 i mamrotali: aduj 213 do akumulatora. Jeden z rzdw klawiszy by nazywany
akumulatorem!
Po dziesiciu minutach dla mojego pitnastoletniego umysu stao si jasne, e liczba
15 oznaczaa zapisz, a liczba 10 zaaduj, e to wanie do akumulatora mona byo
zapisywa albo adowa wartoci, a pozostae liczby oznaczay jedno z 1024 sw na bbnie.
(A wic to tym jest sowo!)
Bit za bitem (tutaj cakiem dosownie) mj chtny umys zauwaa coraz wicej kodw
instrukcji i poj. W momencie, gdy technicy sobie poszli, znaem ju podstawy dziaania
maszyny.
Tego popoudnia, w czasie na samodzieln nauk, zakradem si do laboratorium
matematycznego i zaczem bawi si komputerem. Ju duo wczeniej nauczyem si,
184
N AUCZANIE
e lepiej prosi o wybaczenie ni o pozwolenie! Napisaem may program, ktry mnoy

warto akumulatora razy dwa i dodawa do niego jeden. Wpisaem do akumulatora liczb
5, uruchomiem program i zobaczyem w akumulatorze warto 138! Zadziaao!
Wpisaem kilka innych prostych programw tego rodzaju i wszystkie dziaay zgodnie
z planem. Byem panem wszechwiata!
Kilka dni pniej uwiadomiem sobie, jak gupi byem i ile miaem szczcia. Znalazem
w laboratorium instrukcj lec na stole. Podawaa ona wszystkie polecenia i kody
operacyjne, w tym i takie, ktrych nie poznaem, podgldajc technikw. Byem szczliwy,
e prawidowo zinterpretowaem te polecenia, ktre ju znaem, ale pozostae wprawiy
mnie w ekscytacj. Jedn z nowych instrukcji byo HTL. Jak si okazao, kodem tej instrukcji
zatrzymania byy same zera. I cakiem przypadkiem na kocu kadego mojego programu
umieszczaem sowo skadajce si z samych zer, tak eby mc wpisa je do akumulatora
i tym samym go wyczyci. Pomys na instrukcj zatrzymujc w ogle nie przyszed mi
do gowy. Sdziem, e program po prostu zatrzyma si, gdy si skoczy.
Pamitam, e pewnego dnia siedziaem w laboratorium i obserwowaem, jak jeden
z nauczycieli prbowa uruchomi jaki program. Chcia wprowadzi dwie liczby dziesitne
za pomoc podczonego dalekopisu i wypisa ich sum. Kady, kto prbowa napisa
taki program w jzyku maszynowym minikomputera, wie, e nie jest to cakiem trywialne.
Trzeba odczyta znaki, zmieni je w cyfry, te z kolei przeksztaci do postaci binarnej,
doda je, przeksztaci w posta dziesitn i ostatecznie zapisa jako znaki. I uwierz mi,
cao jest jeszcze gorsza, gdy wprowadzasz taki program w postaci binarnej za pomoc
panelu komputera!
Patrzyem, jak wprowadza do swojego programu instrukcj zatrzymania i uruchamia go,
a ten dziaa a do wyznaczonego instrukcj miejsca. (Rany! To dopiero pomys!) Ten
prymitywny punkt wstrzymania pozwala mu sprawdzi zawarto rejestrw i skontrolowa
to, czego program dokona do tej pory. Pamitam, e mamrota do siebie: Wow, ale to
szybkie!. C, mam dla niego ciekawe wiadomoci!
Nie mam pojcia, jakiego algorytmu uywa. Ten rodzaj programowania to bya dla mnie
nadal czarna magia. Nauczyciel nigdy si do mnie nie odezwa w czasie, gdy patrzyem mu
przez rami. Co wicej, nikt nie rozmawia ze mn na temat komputera. Sdz, e uznawali
mnie za latajcy po laboratorium niczym ma drobny szczeg, ktry naley ignorowa.
Wystarczy powiedzie, e ani ucze, ani nauczyciele nie rozwinli szczeglnie swoich
zdolnoci towarzyskich.
W kocu udao mu si uruchomi program. Obserwowanie go byo niesamowite. Powoli
wprowadza dwie liczby, poniewa mimo zachwytw komputer wcale nie by szybki (pomyl
tylko o odczytywaniu kolejnych sw z obracajcego si bbna, w 1967 roku). Gdy nacisn
klawisz Return po wprowadzeniu drugiej liczby, komputer zaczyna szaleczo byska,
185
R OZDZIA 14.
N AUCZANIE ,
a po chwili wypisywa ju wynik oblicze. Zajmowao mu to mniej wicej po jednej cyfrze

na sekund. Wypisywa wszystkie cyfry z wyjtkiem ostatniej, ponownie szaleczo byska
przez pi sekund i wtedy pojawiaa si ostatnia cyfra, a program si zatrzymywa.
Skd braa si ta przerwa przed ostatni cyfr? Nigdy si tego nie dowiedziaem.
Ale uwiadomio mi to, e sposb rozwizania problemu moe mie ogromny wpyw
na uytkownika. Mimo e program generowa prawidow odpowied, wiedziaem,
e nadal co w nim nie dziaa dobrze.
Tak wygldao nauczanie. Z pewnoci nie by to wymarzony jego rodzaj. Byoby mio, gdyby
jeden z nauczycieli wzi mnie pod swoje skrzyda i zacz ze mn pracowa. Ale nie miao
to znaczenia, poniewa mogem ich obserwowa i uczy si w straszliwym tempie.
Nauczanie niekonwencjonalne
Zaprezentowaem te dwie historie, poniewa opisuj one dwa cakowicie rne rodzaje
nauczania, z ktrych aden nie mia wiele wsplnego z tym, co kojarzy si ze sowem
nauczanie. W pierwszym przypadku uczyem si od autorw doskonale przygotowanego
podrcznika. W drugim obserwujc osoby, ktre bardzo staray si mnie ignorowa.
W obu przypadkach zdobyta wiedza bya gboka i niezwykle wana.
Oczywicie miaem te innych nauczycieli. Choby miy ssiad, ktry pracowa w firmie
Teletype i przynis mi do domu pudeka z 30 przecznikami telefonicznymi, ktrymi
mogem si bawi. Powiem tylko: dajcie chopakowi kilka przecznikw i transformator
z kolejki elektrycznej, a bdzie prbowa podbi wiat!
By te inny miy ssiad radiooperator, ktry pokaza mi, jak korzysta z multimetru
(bardzo szybko go jednak zepsuem). By te waciciel sklepu z materiaami biurowymi,
ktry pozwala mi przychodzi i bawi si jego drogim programowalnym kalkulatorem.
Byo te biuro firmy DEC, ktre pozwalao mi bawi si ich komputerami PDP-8 i PDP-10.
By te wielki Jim Carlin, programista jzyka BAL, ktry ocali mnie przed wyrzuceniem
z pierwszej pracy zwizanej z programowaniem uczy mnie debugowa program
w COBOL-u, ktry wykracza poza moje wczesne moliwoci. Nauczy mnie czyta zrzuty
jdra i formatowa kod sprytnie wstawianymi pustymi wierszami, rzdami gwiazdek
i komentarzami. To on pierwszy popchn mnie w kierunku dobrego rzemiosa. auj,
e nie mogem mu pomc rok pniej, gdy spad na niego gniew naszego szefa.
Ale tak naprawd to ju wszystko. Na pocztku lat 70. nie byo zbyt wielu starszych
programistw. Wszdzie, gdzie pracowaem, to ja byem tym starszym. Nie byo nikogo,
kto powiedziaby mi, czym naprawd jest profesjonalne programowanie. Nie byo wzorca,
ktry nauczyby mnie, jak naley si zachowywa i co naley ceni. Tego wszystkiego
musiaem nauczy si samodzielnie i zdecydowanie nie byo to atwe.
186
T ERMINOWANIE
Mocne ciosy
Jak wspominaem ju wczeniej, w 1976 roku zostaem zwolniony z pracy przy automatyzacji
fabryki. Mimo e pod wzgldem technicznym byem bardzo kompetentny, to jednak
nie nauczyem si jeszcze zwraca uwagi na firm i jej cele. Niewiele znaczyy dla mnie
wyznaczone terminy. Zapomniaem o wielkim poniedziakowym pokazie, w pitek
zostawiem system w nieuywalnym stanie, a w poniedziaek spniem si i wszyscy si
na mnie wciekali.
Mj szef wysa mi list z ostrzeeniem mwicym, e mam si natychmiast zmieni albo
zostan zwolniony. To by dla mnie powany wstrzs. Przemylaem swoje ycie oraz
karier i zaczem wprowadza w zachowaniu daleko idce zmiany. Niestety, to wszystko
byo za mao i za pno. Wczeniej nabraem ju rozpdu w niewaciwym kierunku i teraz
szczegy, ktre wczeniej nie miayby znaczenia, urosy do ogromnych rozmiarw. Chocia
staraem si naprawd mocno, ostatecznie i tak zostaem odeskortowany poza budynek.
Nie musz chyba wspomina, e przyniesienie takich wiadomoci ciarnej onie
i dwuletniej crce nie jest niczym przyjemnym. Pozbieraem si jednak i do nastpnej
pracy zabraem kolejn wan nauczk. Pamitaem o niej i o innych przez nastpnych
15 lat, dlatego stay si one podstaw mojej aktualnej kariery.
Ostatecznie przeyem i dalej si rozwijaem. Istniej jednak znacznie lepsze metody. Lepiej
dla mnie byoby, gdybym mia prawdziwego mentora, ktry nauczyby mnie odrnia
dobro od za. Kogo, kogo mgbym obserwowa podczas prac nad drobnymi zadaniami,
kto sprawdzaby moj wczesn prac i kierowa ni. Kogo, kto byby dla mnie wzorem
i uczy mnie waciwych reakcji i wartoci. Sensei. Mistrza. Mentora.
Terminowanie
Co robi lekarze? Sdzisz, e szpitale zatrudniaj absolwentw szk medycznych i ju
pierwszego dnia pracy kieruj ich na sale operacyjne? Oczywicie, e nie.
W zawodzie lekarza wypracowano metody intensywnej nauki, zwizane z ustanowionym
rytuaem i zanurzone w tradycji. wiat medyczny kontroluje uniwersytety i upewnia si, e ich
absolwenci maj jak najlepsze wyksztacenie. Na to wyksztacenie niemal po rwno skadaj
si zajcia w murach uczelni i dziaania kliniczne w szpitalach pod okiem profesjonalistw.
Po ukoczeniu szkoy, ale jeszcze przed przyznaniem licencji nowi lekarze musz spdzi
cay rok na kontrolowanej praktyce i wiczeniach nazywanych staem. W istocie jest
to bardzo intensywne szkolenie przez prac. Kady staysta jest otoczony nauczycielami
i wzorcami do naladowania.
187
R OZDZIA 14.
N AUCZANIE ,
Po zakoczeniu stau kada ze specjalizacji medycznych wymaga kolejnych trzech do

piciu lat nadzorowanych praktyk i wicze, ktre tym razem nazywane s rezydentur.
Rezydenci nabieraj pewnoci siebie, przejmujc coraz wiksz odpowiedzialno, cho
nadal s obserwowani i nadzorowani przez starszych lekarzy.
Wiele specjalnoci wymaga jeszcze kolejnych lat wsppracy, w czasie ktrych uczniowie
kontynuuj specjalizowan nauk i nadzorowane wiczenia.
Dopiero wtedy s gotowi, eby przystpi do egzaminw i otrzyma certyfikat.
Taki opis zawodu lekarza jest troszeczk wyidealizowany i by moe nie cakiem dokadny.
Istotne jest jednak to, e gdy stawka jest wysoka, nie wysya si absolwentw do dziaania,
oczekujc doskonaych rezultatw. Dlaczego zatem dokadnie tak postpujemy przy
tworzeniu oprogramowania?
To prawda, e bdy w oprogramowaniu powoduj wzgldnie niewielk liczb zgonw.
Ale powoduj powane straty finansowe. Firmy trac ogromne kwoty z powodu
niedostatecznego wyszkolenia swoich programistw.
Z jakiego powodu brana oprogramowania wymylia sobie, e programici staj si
programistami zaraz po ukoczeniu szkoy i od razu umiej programowa. Naprawd
firmy bardzo czsto zatrudniaj dzieci koczce szkoy, formuj z nich zespoy i ka
im tworzy najwaniejsze systemy. To przecie szalestwo!
Nie robi tak malarze. Nie robi tak hydraulicy. Nie robi tak elektrycy. Nawet kucharze
w fast foodach tak nie robi. Wydaje mi si, e firmy zatrudniajce absolwentw
informatyki powinny inwestowa w ich wyksztacenie nieco wicej ni McDonald
inwestuje w swoich kelnerw.
Nie oszukujmy si, e to nie ma znaczenia. Ma, i to ogromne. Nasza cywilizacja jest
napdzana oprogramowaniem. To oprogramowanie porusza i manipuluje informacj
wpywajc na nasze ycie. Oprogramowanie steruje silnikami naszych samochodw,
ich skrzyniami biegw i hamulcami. Zarzdza saldami naszych kont bankowych, wysya
nam rachunki i przyjmuje patnoci. Oprogramowanie pierze nasze ubrania i informuje
nas o aktualnej godzinie. To oprogramowanie wywietla obrazy w telewizji, wysya nam
SMS-y, pozwala na rozmowy telefoniczne i bawi nas, gdy czujemy si znudzeni.
Oprogramowanie jest wszdzie.
Skoro wpuszczamy programistw do kadego zaktka naszego ycia, od tych
najdrobniejszych po najistotniejsze, to sdz, e pewien okres szkolenia i nadzorowanych
praktyk byby cakiem wskazany.
188
T ERMINOWANIE
Terminowanie programisty
Jak zatem naleaoby w zawodzie programisty wprowadza modych absolwentw w szeregi
profesjonalistw? Jakie kroki naley podejmowa? Jakie wyzwania przed nimi stawia?
Zacznijmy rozwaania od tyu.
Mistrzowie
Mistrzowie s programistami, ktrzy prowadzili ju niejeden powany projekt
programistyczny. Zwykle maj ju ponad 10 lat dowiadczenia i pracowali nad rnymi
rodzajami systemw, w rnych jzykach i systemach operacyjnych. Wiedz, jak prowadzi
i koordynowa wiele zespow, s sprawnymi projektantami i architektami, bez adnego trudu
s w stanie napisa dowolny kod. Oferowano im ju stanowiska zwizane z zarzdzaniem,
ale odmwili albo po ich zaakceptowaniu szybko si wycofali, albo poczyli nowe zadania
z pierwotnymi pracami technicznymi. Nadal utrzymuj swoje umiejtnoci techniczne,
czytajc, uczc si, wiczc, pracujc i nauczajc. To wanie takim mistrzom firmy bd
przypisywa odpowiedzialno za techniczn stron projektu. Pomyl o Scottym.
Czeladnicy
To programici o odpowiednim wyszkoleniu, kompetencjach i chciach. W tym okresie
swojej kariery ucz si dobrze wsppracowa z zespoem i staj si liderami. Doskonale
orientuj si w aktualnych technologiach, ale zwykle brak im dowiadczenia z rnorodnymi
systemami. Zwykle znaj jeden jzyk, jeden system, jedn platform, ale cigle si ucz.
Poziom dowiadczenia moe by bardzo rny, ale najczciej jest to jakie pi lat. Na
jednym kocu tej redniej mamy rodzcych si mistrzw, na drugiej niedawnych
praktykantw.
Czeladnicy s nadzorowani przez mistrzw albo starszych czeladnikw. Modym czeladnikom
rzadko tylko pozwala si na jakkolwiek autonomi. Ich praca zawsze jest cile nadzorowana.
Ich kod jest przegldany. Wraz z zyskiwanym dowiadczeniem zwiksza si te ich
autonomia. Nadzr przestaje by tak bezporedni, a jego gorset jest powoli luzowany.
Ostatecznie ogranicza si do krtkich recenzji.
Praktykanci i stayci
Absolwenci zaczynaj swoj karier jako praktykanci. Praktykanci nie maj adnej
autonomii i s cile nadzorowani przez czeladnikw. Pocztkowo nie otrzymuj adnych
zada, a jedynie wspomagaj czeladnikw w pracy. To powinien by dla nich czas bardzo
intensywnego programowania w parach. To wanie wtedy ucz si rnych metodologii.
To wanie wtedy tworzone s w nich podstawowe wartoci.
189
R OZDZIA 14.
N AUCZANIE ,
Czeladnicy s nauczycielami. Upewniaj si, e praktykanci znaj zasady projektowania,

wzorce projektowe, metodologie i rytuay. Czeladnicy ucz ich TDD, refaktoryzacji,
szacowania itd. Podsuwaj praktykantom rne ksiki i artykuy do czytania, nakazuj
wykonywanie wicze i sprawdzaj ich postpy.
Praktyka powinna trwa okoo roku. Po tym czasie, jeeli czeladnicy zechc przyj
praktykantw w swoje szeregi, powinni przekaza mistrzom swoje rekomendacje. Mistrzowie
powinni sprawdzi praktykantw zarwno w bezporedniej rozmowie, jak i przegldajc
ich osignicia. Jeeli mistrzowie si zgodz, to praktykant staje si czeladnikiem.
Rzeczywisto
Tutaj rwnie wszystko zostao wyidealizowane i pozostaje w sferze hipotez. Jeeli jednak
pozmienia kilka nazw i przymkn oko na pewne okrelenia, to cay opis nie bdzie bardzo
odlegy od tego, czego bymy oczekiwali. Absolwenci s nadzorowani przez modych
liderw zespow, ktrzy z kolei s nadzorowani przez prowadzcych projekty itd. Problem
polega na tym, e w wikszoci przypadkw takie nadzorowanie nie ma nic wsplnego
z technik! W wikszoci firm nie istnieje co takiego jak nadzr techniczny. Programici
dostaj podwyki i ewentualne awanse, poniewa tak si postpuje z programistami.
Rnica midzy tym, co naprawd robimy, a moim wyidealizowanym programem
terminowania polega na koncentracji na nauczaniu, wiczeniach, nadzorze i recenzjach.
Rnic stanowi pogld, e wartoci stanowice o profesjonalizmie i techniczna doskonao
musz by uczone, wpajane, pielgnowane, pieszczone i hodowane. W naszym aktualnym
podejciu brakuje nakazu dla starszych, eby uczyli modych.
Rzemioso
Teraz moemy ju zdefiniowa to sowo: rzemioso. Czym ono waciwie jest? Chcc je
zrozumie, musimy przyjrze si sowu rzemielnik. Sowo to przywodzi na myl kwalifikacje
i jako. I jeszcze dowiadczenie, i kompetencj. Rzemielnik jest kim, kto pracuje szybko,
ale bez popiechu, kto podaje rozsdne szacunki i dotrzymuje zobowiza. Rzemielnik wie,
kiedy naley odmwi, ale z caych si stara si tego unika. Rzemielnik jest profesjonalist.
Rzemioso jest stanem umysu waciwym dla rzemielnikw. Rzemioso jest memem
zawierajcym w sobie wartoci, metody, techniki, nastawienie i odpowiedzi.
Jak jednak rzemielnicy przyjmuj do siebie ten mem? Jak osigaj ten stan umysu?
Mem rzemiosa jest przekazywany z jednej osoby na drug. Starsi ucz go modszych.
Jest dzielony przez wsppracujce osoby. Mona go obserwowa i ponownie si go uczy,
190
W NIOSKI
tak jak starsi obserwuj modszych. Rzemioso jest zaraliwe, to swego rodzaju wirus,
ktry mona zapa, obserwujc innych i pozwalajc memowi zagniedzi si w sobie.
Przekonywanie
Nie mona nikogo przekona do bycia rzemielnikiem. Nie mona nakoni nikogo
do przyjcia memu rzemiosa. Tutaj nie dziaaj adne argumenty, adne dane nie maj
znaczenia, a studia przypadkw s pustymi historiami. Przyjcie tego memu nie jest decyzj
racjonaln, ale emocjonaln. To bardzo ludzkie.
Jak zatem sprawi, eby ludzie zaakceptowali mem rzemiosa? Pamitaj, e ten mem jest
zaraliwy, ale tylko wtedy, gdy jest obserwowany. Trzeba zatem sprawi, eby kto chcia
go obserwowa. Musisz sta si dla innych wzorcem. Najpierw to Ty musisz sta si
rzemielnikiem i sprawi, eby Twoje rzemioso byo widoczne. Potem pozwl memowi
wykona reszt pracy.
Wnioski
W szkoach mona nauczy si teorii programowania komputerw. Szkoa nie jest jednak
w stanie naucza dyscypliny, praktyki i umiejtnoci niezbdnych rzemielnikom. Te
rzeczy nabywa si przez lata wypenione osobist kuratel i uczeniem si. Musimy sobie
uwiadomi, e wprowadzenie nastpnych pokole programistw w zawodow doroso
bdzie naszym zadaniem, a nie zadaniem uniwersytetw. Nadszed dla nas czas przyjcia
programu praktyk, staw i dugoterminowego prowadzenia modych.
191
R OZDZIA 14.
N AUCZANIE ,
192
N ARZDZIA
W 1978 roku pracowaem w firmie Teradyne nad systemem testujcym telefony, o ktrym
ju wczeniej opowiadaem. System skada si z mniej wicej 80 000 wierszy kodu
w asemblerze komputera M365. Cay kod rdowy by przechowywany na tamach.
Same tamy byy podobne do kasetek do magnetofonw 8-ciekowych, tak popularnych
w latach 70. Tama bya niekoczc si ptl, a napd mg przewija j tylko w jednym
kierunku. W kasetkach byy dostpne tamy o dugoci 3, 7, 15 i 30 metrw. Im dusza
bya tama, tym duej trwao jej przewijanie, poniewa napd musia j przesuwa
naprzd a do napotkania punktu adowania. W przypadku tam 30-metrowych procedura
193
D ODATEK A
N ARZDZIA
poszukiwania takiego punktu trwaa 5 minut, dlatego zawsze dobieralimy odpowiednio

tam do aktualnego zadania1.
Kada tama bya logicznie dzielona na pliki. Na jednej tamie mona byo zapisa tyle
plikw, ile si na ni zmiecio. Chcc odszuka konkretny plik na tamie, trzeba byo
j zaadowa i przewija po jednym pliku do momentu znalezienia tego poszukiwanego.
List zawartoci katalogu z kodem rdowym mielimy zapisan na cianie, dziki temu
wiedzielimy, ile plikw omin, eby dosta si do potrzebnego.
Na pce w laboratorium mielimy te gwn kopi kodu rdowego na tamie 30-metrowej.
Miaa ona etykiet Master. Chcc edytowa jaki plik, adowalimy rdow tam gwn
do jednego napdu, a czyst tam trzymetrow wkadalimy do drugiego. Na tamie
rdowej pomijalimy poszczeglne pliki, a znalelimy aktualnie potrzebny. Nastpnie
znaleziony plik kopiowalimy na czyst tam. Potem obie tamy byy przewijane, a tama
gwna wdrowaa z powrotem na pk.
Na specjalnej tablicy w laboratorium znajdowaa si lista katalogu tamy Master.
Po wykonaniu kopii pliku, ktry mia by edytowany, umieszczalimy kolorow pinesk
przy jego nazwie. Tak wygldao wymeldowanie plikw!
Pliki edytowalimy na ekranie. Nasz edytor ED-402 by naprawd dobry i troch
przypomina synnego vi. Odczytywalimy z tamy stron, edytowalimy jej zawarto,
nastpnie j zapisywalimy i przechodzilimy do nastpnej. Na stron skadao si zwykle
50 wierszy kodu. Nie dao si obejrze dalszych stron ani skontrolowa stron poprzednio
edytowanych, dlatego zawsze stosowalimy listingi.
Co wicej, w istniejcych listingach zaznaczalimy zmiany, ktre chcielimy wprowadzi,
a potem edytowalimy pliki zgodnie z wczeniej przygotowanymi oznaczeniami. Nikt nie
pisa ani nie modyfikowa kodu na terminalu! To byoby samobjstwo.
Po wprowadzeniu zmian we wszystkich wymagajcych tego plikach czylimy je z gwn
tam, tworzc tym samym tam robocz. Wykorzystywalimy j do przeprowadzenia
kompilacji i testw.
Po zakoczeniu testowania i upewnieniu si, e wprowadzone zmiany dziaaj, sprawdzalimy
tablic w laboratorium. Jeeli nie pojawiy si na niej adne nowe pineski, to po prostu
1
Tamy przewijay si tylko w jednym kierunku. Jeeli przy odczycie zdarzy si bd, napd nie mia
ju moliwoci cofnicia si i odczytania danych jeszcze raz. Trzeba byo przerwa procedur,
przewin tam do punktu adowania i rozpocz wszystko on nowa. Zdarzao si to dwa lub
trzy razy dziennie. Powszechne byy te bdy zapisu, a napd nie mia adnych moliwoci ich
wykrywania. Dlatego wanie zawsze zapisywalimy tamy parami, a po zakoczeniu zapisu kad
z nich kontrolowalimy. Jeeli jedna z tam zawieraa bdy, to natychmiast robilimy kopi. Jeeli
obie tamy byy uszkodzone, co nie zdarzao si czsto, ca operacj zaczynalimy od pocztku.
Tak wanie wygldao ycie w latach 70.
194
N ARZDZIA
nadawalimy tamie roboczej etykiet Master, a z tablicy zdejmowalimy pineski. Jeeli

jednak w midzyczasie pojawiy si nowe pineski, to usuwalimy wasne i przekazywalimy
tam robocz osobie, ktrej pineski nadal znajdoway si na tablicy. To ona musiaa
poczy wszystkie zmiany.
Byo nas trzech i kady uywa pinesek innego koloru, wic atwo byo sprawdzi, kto jeszcze
pracowa nad kodem. A dziki temu, e wszyscy pracowalimy w tym samym laboratorium
i cigle ze sob rozmawialimy, status z tablicy moglimy atwo zapamita. Okazywao si
zatem, e tablica bya niepotrzebna i dlatego czsto jej nie uywalimy.
Narzdzia
Dzisiaj programici mog wybiera z wielkiego zasobnika rnych narzdzi. Wikszo
z nich nie jest warta zainteresowania, ale jest kilka takich, ktre kady programista powinien
doskonale zna. W tym rozdziale przedstawi aktualn zawarto mojego narzdziownika.
Nie sprawdzaem dokadnie wszystkich dostpnych narzdzi, dlatego nie mona uzna tego
opisu za wyczerpujcy. Po prostu tych narzdzi uywam.
Kontrola kodu rdowego

Jeeli chodzi o kontrol kodu rdowego, to narzdzia o otwartych rdach zwykle s
najlepszym wyborem. Dlaczego? Z tego prostego powodu, e s pisane przez programistw
dla programistw. Narzdzia otwartordowe tworz programici dla samych siebie zawsze
wtedy, gdy potrzebuj czego, co naprawd dziaa.
Na rynku dostpnych jest kilka dosy drogich, komercyjnych systemw kontroli wersji
klasy enterprise. Uwaam, e takie narzdzia nie s sprzedawane samym programistom,
ale raczej menederom, dyrektorom i innym grupom narzdziowym. Lista funkcji takich
systemw jest imponujca, ale niestety zazwyczaj nie maj one tego, co jest najbardziej
potrzebne programistom. A najwaniejsza jest szybko.
System kontroli wersji klasy enterprise

By moe Twoja firma zainwestowaa ma fortun w system kontroli wersji klasy
enterprise. W takiej sytuacji skadam swoje kondolencje. Zapewne nie byoby politycznie
poprawne chodzenie teraz po firmie i woanie: Wujek Bob twierdzi, e tego nie mona
uywa. Na szczcie istnieje pewne proste rozwizanie.
Moesz wprowadza kod rdowy do firmowego systemu kontroli wersji pod koniec
kadej iteracji (na przykad raz na tydzie), a w midzyczasie lokalnie korzysta z jednego
z systemw otwartordowych. W ten sposb kady bdzie szczliwy, adne firmowe
zasady nie zostan naruszone, a Twoja produktywno si zwikszy.
195
D ODATEK A
N ARZDZIA
Blokowanie pesymistyczne i optymistyczne

Blokowanie pesymistyczne byo cakiem dobr metod gdzie w latach 80. W kocu
najprostszy sposb kontrolowania jednoczesnych aktualizacji to ich poszeregowanie. A zatem
skoro ja edytuj plik, to ty trzymaj si od niego z daleka. Co ciekawe, system z kolorowymi
pineskami, ktrego uywaem w latach 70., by takim wanie rodzajem pesymistycznego
blokowania. Jeeli przy nazwie pliku bya pineska, to nie wolno byo go edytowa.
Oczywicie blokowanie pesymistyczne rodzio inne problemy. Jeeli zablokowaem plik,
a potem poszedem na urlop, to kto, kto chciaby go te edytowa, nie mg wykona
swojej pracy. Co wicej, nawet jeeli blokuj plik tylko przez dzie lub dwa, to i tak mog
opni prac innych, ktrzy te chcieli co do tego pliku dopisa.
Od tamtej pory bardzo rozwiny si narzdzia pozwalajce na czenie jednoczenie
edytowanych plikw rdowych. Jeeli si nad tym zastanowi, to jest to naprawd
niesamowite. Narzdzia te analizuj dwa rne pliki, porwnuj je z plikiem wyjciowym
i stosuj rne strategie czenia pozwalajce na waciwe poczenie ze sob dwch
osobnych zmian. I efekt jest naprawd wietny.
A zatem era blokowania pesymistycznego si zakoczya. Nie musimy ju blokowa plikw,
ktre chcemy edytowa. W ogle nie musimy pamita o wyciganiu z repozytorium
poszczeglnych plikw. Po prostu pobieramy cay system i edytujemy wymagajce tego pliki.
Gdy jestemy ju gotowi wprowadzi nasze zmiany do repozytorium, wystarczy wykona
operacj aktualizacji. W ten sposb dowiadujemy si, czy kto inny nie wprowadzi
przed nami zmian, ktre s automatycznie czone z naszymi poprawkami, wyapywane
s te wszelkie konflikty. Mimo e te ostatnie musimy rozwiza sami, to jednak narzdzia
nadal nas w tym wspomagaj. Na koniec wystarczy ju tylko umieci w repozytorium
poczony kod.
W dalszej czci dodatku bd mia wiele do powiedzenia na temat roli, jak w tym
procesie odgrywaj zautomatyzowane testy i ciga integracja. Na razie ogranicz si do
stwierdzenia, e do repozytorium nigdy nie wysyamy kodu, ktry nie przeszed wszystkich
testw. Absolutnie nigdy!
CVS i SVN
Najstarszym znanym systemem kontroli wersji jest CVS. W swoich czasach by doskonaym
rozwizaniem, ale nie sprawdza si ju w dzisiejszych projektach. Mimo e wietnie radzi
sobie z pojedynczymi plikami i katalogami, to jednak operacje jak zmiana nazw plikw albo
usuwanie katalogw go przerastaj. A poza tym moe lepiej pomin to milczeniem.
Z kolei Subversion dziaa naprawd przyjemnie. Umoliwia pobranie caego systemu
w jednej tylko operacji. Moliwe jest atwe aktualizowanie, czenie i wstawianie. Dopki
nie zaczniesz bawi si w tworzenie rozgazie, system SVN jest bardzo prosty w obsudze.
196
K ONTROLA KODU RDOWEGO
Rozgazianie
Do 2008 roku stosowaem jedynie najprostsze formy tworzenia rozgazie. Jeeli programista
utworzy nowe rozgazienie, to musiao ono zosta wczone do gwnej linii jeszcze przed
zakoczeniem iteracji. Naprawd tak bardzo nie lubiem rozgaziania, e w projektach,
w ktrych uczestniczyem, praktycznie ich nie uywano.
Nadal sdz, e stosujc SVN, naley trzyma si z daleka od rozgazie. Na szczcie
istnieje kilka nowych narzdzi, ktre diametralnie zmieniaj zasady gry. S nimi rozproszone
systemy kontroli wersji. Moim ulubionym jest Git i o nim chciabym pokrtce opowiedzie.
Git
Systemu Git zaczem uywa w 2008 roku i od razu zmieni on wszystko w moim sposobie
wykorzystywania mechanizmw kontroli wersji. Wyjanienie, dlaczego to narzdzie powoduje
tak ogromn zmian, wykracza poza ramy tej ksiki. Jednak porwnanie rysunku A.1
z rysunkiem A.2 powinno zastpi wiele wyjanie, ktre pozwol sobie zatem pomin.
Rysunek A.1. FitNesse w Subversion
197
D ODATEK A
N ARZDZIA
Rysunek A.2. FitNesse w systemie Git
Na rysunku A.1 przedstawiono kilka tygodni prac nad projektem FitNesse w czasie,
gdy pracowaem jeszcze z systemem SVN. Dokadnie wida tu efekty mojej zasady
niestosowania adnych rozgazie. Po prostu ich nie tworzylimy. Zamiast tego bardzo
czsto dokonywalimy aktualizacji gwnej linii kodu, czylimy j i wprowadzalimy
do niej zmiany.
Na rysunku A.2 przedstawiono kilka tygodni prac nad tym samym projektem, ale ju
w systemie Git. Jak wida, przez cay czas tworzymy i czymy rne rozgazienia. Nie
wynika to z faktu, e nie stosuj si cile do zasady braku rozgazie. Po prostu okazao
si, e jest to cakiem oczywisty i wygodny sposb pracy. Poszczeglni programici mog
tworzy bardzo krtkie rozgazienia, a potem bardzo prosto czy je ze sob.
Zwr uwag, e nie da si tu zauway gwnej linii kodu. Wynika to z faktu, e takiej nie ma.
Korzystajc z systemu Git, nie masz czego takiego jak centralne repozytorium ani gwna
linia kodu. Kady programista przechowuje na swoim komputerze wasn kopi caej
historii projektu. Operacje pobrania i wstawienia kodu s wykonywane na tej wanie
lokalnej kopii, a potem czy si je z kopiami pozostaych programistw.
198
IDE I EDYTOR
Prawd jest, e utrzymuj specjalne, zote repozytorium, do ktrego przesyam

poszczeglne wydania i porednie wersje projektu. Jednak nazwanie tego repozytorium
centralnym nie byoby zgodne z prawd. Jest to tylko bardzo wygodna migawka caej
historii projektu, ktr kady programista przechowuje lokalnie.
Jeeli tego nie rozumiesz, to si nie przejmuj. Na pocztek Git naprawd potrafi zabi klina.
Trzeba si po prostu przyzwyczai do nowego sposobu pracy. Ale mog powiedzie to:
Git i podobne do niego narzdzia s przyszoci systemw kontroli kodu rdowego.
IDE i edytor
Programici wikszo swojego czasu powicaj na czytanie i edytowanie kodu. Narzdzia,
ktrych uywamy do tego celu, przez dziesiciolecia bardzo si zmieniy. Niektre z nich
stay si niezwykle wszechstronne, ale inne praktycznie nie zmieniy si od lat 70.
vi
Mona by sdzi, e dni wykorzystywania vi jako edytora do rozwoju oprogramowania
powinny ju dawno min. Dzisiaj mamy narzdzia przewyszajce moliwociami vi
i inne, podobne do niego proste edytory tekstu. Prawda jest jednak taka, e vi znowu
zaczyna zyskiwa na popularnoci dziki swojej prostocie, atwej obsudze, szybkoci
i elastycznoci. By moe nie jest on a tak rozbudowany jak Emacs albo Eclipse, ale nadal
jest bardzo szybkim i wszechstronnym edytorem.
Po tym wstpie mog si przyzna, e nie jestem ju zaawansowanym uytkownikiem vi.
By taki czas, kiedy byem znany jako bg vi, ale to ju zamierzcha przeszo. Nadal
jednak od czasu do czasu uywam vi, jeeli musz szybko wprowadzi jak zmian
do pliku tekstowego. Ostatnio uyem go nawet, gdy musiaem szybciutko poprawi
co w pliku rdowym Javy w zdalnym rodowisku. Jednak oglna ilo kodu, jak
w ostatnim dziesicioleciu napisaem za pomoc vi, jest przeraajco niewielka.
Emacs
Emacs to nadal jeden z najbardziej rozbudowanych edytorw, jakie znam.
Najprawdopodobniej nie zmieni si to jeszcze przez co najmniej dekad, co gwarantuje
wewntrzny model Lispu. Nic nie moe si z nim rwna w kategorii edytora oglnego
przeznaczenia. Uwaam jednak, e Emacs nie moe konkurowa z dominujcymi
aktualnie IDE tworzonymi pod konkretne zadania. Pisanie kodu nie jest niestety
zadaniem dla edytora o oglnym przeznaczeniu.
W latach 90. byem prawdziwym wyznawc Emacsa. Nawet nie mylaem o uywaniu
czegokolwiek innego. Edytory typu wska-i-kliknij z tamtego czasu byy miesznymi
199
D ODATEK A
N ARZDZIA
zabawkami, ktrych aden programista nie mg traktowa powanie. Jednak po roku

2000 poznaem IDE o nazwie IntelliJ, ktrego uywam do dzisiaj, i nigdy nie tskni
za starymi czasami.
Eclipse/IntelliJ
Jestem uytkownikiem rodowiska IntelliJ. Po prostu je kocham. Uywam go do pisania
programw w Javie, Ruby, Clojure, Scali, JavaScripcie i wielu innych jzykach. To narzdzie
zostao napisane przez programistw, ktrzy dokadnie wiedz, czego potrzebuje programista
tworzcy kod. Przez te wszystkie lata tylko rzadko mnie rozczarowywali, a prawie zawsze
speniali moje oczekiwania.
Jeeli chodzi o moliwoci, to Eclipse jest bardzo podobny do IntelliJ. W kontekcie
edytowania kodu Javy oba IDE pod kadym moliwym wzgldem przewyszaj Emacsa.
Oczywicie istniej te inne podobne IDE, ale nie bd o nich wspomina, poniewa nie
mam adnego dowiadczenia w pracy z nimi.
Funkcje, dziki ktrym te IDE tak bardzo wyprzedzaj Emacsa, dotycz przede wszystkim
ogromnej rnorodnoci metod manipulacji kodem. Na przykad w IntelliJ za pomoc
jednego polecenia mona wydoby superklas z wybranej klasy. Wrd innych wanych
funkcji mona wymieni zmian nazw zmiennych, wydobywanie metod i przeksztacanie
dziedziczenia w kompozycje.
Dziki takim narzdziom edytowanie kodu nie ogranicza si do wierszy i znakw, ale
pozwala te na wykonywanie zoonych manipulacji. Zamiast myle o kolejnych kilku
znakach i wierszach, ktre musisz wprowadzi, moesz myle o kilku przeksztaceniach,
jakie bd jeszcze konieczne. W skrcie: taki model programowania jest zdecydowanie
bardziej produktywny.
Oczywicie takie moliwoci maj swoj cen. Poznanie tych narzdzi wymaga czasu,
a i skonfigurowanie caego projektu to dodatkowa praca. Tych narzdzi nie mona nazwa
lekkimi. Do dziaania potrzebuj sporo zasobw komputera.
TextMate
TextMate jest rozbudowanym i jednoczenie lekkim edytorem. Oczywicie nie mona
w nim robi tych wspaniaych manipulacji na kodzie, na ktre pozwalaj IntelliJ i Eclipse.
Nie jest te wyposaony w potne mechanizmy Lispu i biblioteki Emacsa. Nie ma te
szybkoci i pynnoci dziaania vi. Jednake prawie nie trzeba si uczy jego obsugi, ktra
jest zadziwiajco intuicyjna.
Edytora TextMate uywam od czasu do czasu, szczeglnie do rzadkiego ju pisania
programw w C++. Do wikszych projektw w tym jzyku uybym Emacsa, ale do krtkich
zada, jakie na mnie spadaj, TextMate w zupenoci mi wystarcza.
200
LEDZENIE PROBLEMW
ledzenie problemw
Aktualnie uywam systemu Pivotal Tracker, ktry w codziennym uytkowaniu jest bardzo
elegancki i prosty. Doskonale wpasowuje si w rozwizania iteracyjne i zwinne. Umoliwia
szybk komunikacj midzy programistami a udziaowcami projektu. Mog powiedzie,
e jestem z niego bardzo zadowolony.
W przypadku bardzo maych projektw czasami korzystam z systemu Lighthouse. Jest bardzo
szybki i prosty zarwno w konfiguracji, jak i w uytkowaniu, ale pod wzgldem moliwoci
nie moe si rwna z Pivotal Trackerem.
Dawniej uywalimy te po prostu wiki, ktre doskonale sprawdzaj si w projektach
wewntrznych. Umoliwiaj przygotowanie dowolnego schematu postpowania. Nie
zmuszaj nas do stosowania okrelonych procesw albo sztywnych struktur. Mona
je atwo pozna i jeszcze atwiej si ich uywa.
Czasami najlepszym systemem ledzenia problemw jest zestaw kartek powieszonych
na tablicy. Tak tablic dzieli si na trzy czci: Do zrobienia, W toku i Gotowe.
Programici musz tylko przenosi karty z jednej do drugiej kolumny. Taki system
ledzenia problemw jest prawdopodobnie najpowszechniej uywany w zespoach
stosujcych metodologie zwinne.
Klientom zalecam na pocztek prac z rcznymi systemami, takimi jak kartki na tablicy,
i dopiero pniej dokupienie konkretnego narzdzia. Gdy naucz si wykorzystywa taki
rczny system, zdobd te dowiadczenie niezbdne do wybrania waciwego rozwizania.
A nierzadko jest te tak, e najlepszym rozwizaniem jest pozostanie przy systemie rcznym.
Licznik problemw
Zespoy programistw z pewnoci musz mie listy problemw, nad ktrymi trzeba
pracowa. Do takich problemw zaliczaj si zarwno nowe zadania i funkcje, jak i zwyczajne
bdy. W przypadku zespow o rozsdnej wielkoci (od 5 do 12 programistw) na takiej
licie mog znajdowa si dziesitki lub setki pozycji. Nie tysice.
Jeeli masz tysice bdw, to co na pewno dziaa le. Jeeli masz tysice nowych funkcji
lub zada, to rwnie co jest nie tak. Oglnie rzecz biorc, lista problemw powinna by
wzgldnie krtka, tak eby mona byo j opanowa za pomoc lekkich narzdzi, jak wiki,
Lighthouse lub Tracker.
Dostpne s te narzdzia komercyjne, ktre sprawiaj cakiem dobre wraenie. Widziaem
uywajcych ich klientw, ale nigdy nie miaem okazji pracowa z nimi osobicie. Nie jestem
przeciwnikiem takich narzdzi, o ile liczba problemw bdzie pozostawa krtka i przejrzysta.
201
D ODATEK A
N ARZDZIA
Gdy narzdzia do ledzenia problemw s zmuszone do obsugiwania tysicy zgosze,

to sowo ledzenie traci tu znaczenie. Staj si tylko mietniskami problemw
(i czsto bardzo podobnie mierdz).
Ciga kompilacja
Ostatnio jako mechanizmu cigej kompilacji uywaem systemu Jenkins. Jest naprawd
niewielki, prosty i prawie nie wymaga nauki. Wystarczy go pobra, uruchomi, szybko
i atwo skonfigurowa, i gotowe. Sama przyjemno.
Moja filozofia dotyczca cigej kompilacji jest bardzo prosta. Podcz system do systemu
kontroli wersji kodu rdowego. Gdy tylko kto wprowadzi zmiany do kodu, kompilacja
powinna zosta uruchomiona automatycznie, a jej wynik przesany do zespou.
Zadaniem zespou jest cige utrzymywanie bezproblemowej kompilacji systemu. Kada
nieudana kompilacja powinna by sygnaem krytycznym, a zesp powinien stara si jak
najszybciej rozwiza ten problem. Pod adnym pozorem nie mona pozwoli, eby taka
sytuacja trwaa dzie lub duej.
W przypadku projektu FitNesse nakazuj kademu programicie uruchomienie skryptu
cigej kompilacji jeszcze przed wprowadzeniem zmian do repozytorium. Caa kompilacja
trwa poniej 5 minut, a zatem nie jest to bardzo uciliwe. Jeeli pojawi si jakie problemy,
to programista musi je rozwiza, zanim przekae kod do repozytorium. Dziki temu
automatyczna kompilacja prawie nigdy nie zgasza bdw. Najczstszym powodem takich
bdw okazuj si problemy zwizane ze rodowiskiem, poniewa rodowisko automatycznej
kompilacji rni si od rodowiska stosowanego przez poszczeglnych programistw.
Narzdzia do testw jednostkowych

Kady jzyk ma swoje wasne narzdzia do testw jednostkowych. Moimi ulubionymi s JUnit
dla Javy, RSPEC dla Ruby, NUnit dla .NET, Midje dla Clojure i CppUTest dla C i C++.
Bez wzgldu na to, ktre narzdzie wybierzesz, wszystkie maj pewien zestaw wsplnych
funkcji.
1. Powinny pozwala szybko i atwo uruchamia testy. Niezalenie od tego, czy odbywa
si to przez wtyczk do IDE, czy proste narzdzia wiersza polece, programista musi
mie moliwo uruchomienia testw w dowolnym momencie. Praca potrzebna do
ich uruchomienia musi by minimalna.
Na przykad testy w CppUTest uruchamiam, wpisujc w TextMate polecenie
command-M. Skonfigurowaem je tak, eby uruchamiao plik makefile, ktry
automatycznie przeprowadza testy i wypisuje raport, gdy wszystkie testy zostan
202
N ARZDZIA DO TESTW KOMPONENTW
zaliczone. IntelliJ obsuguje zarwno JUnit, jak i RSPEC, dlatego wystarczy nacinicie
tylko jednego przycisku. Do testw NUnit wykorzystuj wtyczk Resharper, ktra
rwnie udostpnia przycisk uruchamiania testw.
2. Narzdzie powinno jasno przedstawia informacj, czy testy zostay zaliczone, czy te
nie. Nie ma znaczenia, czy bdzie to graficzny zielony pasek, czy konsolowy komunikat
Testy zaliczone. Wane jest to, e musisz by w stanie szybko i jednoznacznie
stwierdzi, czy testy udao si zaliczy. Jeeli musisz w tym celu czyta wielowierszowy
raport albo co gorsza porwnywa zawarto dwch plikw, to narzdzie nie
wykonuje swojego zadania.
3. Narzdzie powinno jasno prezentowa postp w wykonywaniu testw. Nie ma znaczenia,
czy bdzie to prosty graficzny miernik, czy cig kropek. Wane jest, aby jasno byo
wida, e testy nadal s wykonywane, a nie zatrzymay si lub zostay przerwane.
4. Narzdzie powinno utrudnia komunikacj midzy poszczeglnymi testami. JUnit
robi to, tworzc nowy egzemplarz klasy testowej przed uruchomieniem kadej metody
testowej. W ten sposb nie pozwala testom na wykorzystywanie zmiennych obiektw
do komunikacji. Inne narzdzia wykonuj testy w losowej kolejnoci, tak e nie mona
zakada uruchomienia jednego testu przed drugim. Bez wzgldu na zastosowany
mechanizm narzdzie powinno wspomaga tworzenie testw cakowicie niezalenych
od siebie. Testy uzalenione od siebie s puapk, w ktr nikt nie chce wpa.
5. Narzdzia powinny uatwia pisanie testw. JUnit na przykad udostpnia wygodne
API do tworzenia zaoe. Wykorzystuje te refleksj i atrybuty Javy, aby odrnia
funkcje testujce od normalnych. Pozwala to dobrym IDE na automatyczne
wyszukiwanie testw i eliminowanie tym samym problemw wynikajcych z czenia
ze sob poszczeglnych zestaww testw oraz tworzenia ich list.
Narzdzia do testw komponentw

Te narzdzia s przeznaczone do testowania komponentw na poziomie ich API. Ich
zadaniem jest sprawdzanie, czy zachowanie komponentu jest opisane w jzyku zrozumiaym
dla menederw i dziau kontroli jakoci. Co wicej, w idealnym przypadku to wanie
analitycy biznesowi i testerzy mog pisa specyfikacj, wykorzystujc wspomniane narzdzia.
Definicja gotowego
Za pomoc narzdzi do testw komponentw mona bardzo atwo okrela, co znaczy
gotowe. Jeeli analitycy biznesowi i testerzy wsppracuj ze sob, tworzc specyfikacj
opisujc zachowanie komponentu, i specyfikacj t mona uruchamia jako zestaw testw,
to gotowe moe mie tylko jedno znaczenie: wszystkie testy zostay zaliczone.
203
D ODATEK A
N ARZDZIA
FitNesse
Moim ulubionym narzdziem do testw komponentw jest FitNesse. Napisaem spor cz
tego systemu i jestem jego gwnym programist. Mog powiedzie, e to moje dziecko.
FitNesse jest systemem wykorzystujcym wiki, ktry umoliwia analitykom biznesowym
i testerom pisanie testw w prostej, tabelarycznej formie. Tabele te s podobne do tablic
Parnasa zarwno w formie, jak i przeznaczeniu. Poszczeglne testy mona szybko czy
w zestawy, a same zestawy mona bardzo atwo uruchamia.
FitNesse jest tworzony w Javie, ale moe testowa systemy pisane w dowolnym jzyku,
poniewa komunikuje si z podstawowym systemem testowym, ktry moe powsta
w innym jzyku. Na licie obsugiwanych jzykw znajduj si Java, C#/.NET, C, C++,
Python, Ruby, PHP, Delphi i inne.
U podstaw FitNesse znajduj si dwa systemy testowe: Fit i Slim. Fit zosta napisany przez
Warda Cunninghama i sta si inspiracj do powstania FitNesse i podobnych narzdzi.
Slim to znacznie prostszy i przenony system testowy, z ktrego chtniej korzystaj
uytkownicy FitNesse.
Inne narzdzia
Znam te kilka innych narzdzi, ktre mona zakwalifikowa do kategorii testw
komponentw.
RobotFX jest narzdziem przygotowanym przez inynierw firmy Nokia. Stosuje
tabelaryczny format podobny do uywanego w FitNesse, ale za podstaw nie suy mu

wiki. Wykorzystuje zwyczajne pliki przygotowywane za pomoc Excela lub podobnych
aplikacji. Samo narzdzie zostao napisane w Pythonie, ale moe suy do testowania
dowolnego innego jzyka za porednictwem odpowiednich mostkw.
Green Pepper to narzdzie komercyjne, o wielu podobiestwach do FitNesse. Bazuje
na popularnym wiki Confluence.

Cucumber to proste narzdzie tekstowe powstajce w Ruby, ale umoliwiajce
testowanie rnych platform. Jzykiem stosowanym w Cucumberze jest popularny

styl Majc/Gdy/To (ang. Given/When/Then).
JBehave to narzdzie podobne do Cucumbera, jako e jest jego logicznym rodzicem.
System zosta napisany w Javie.
Narzdzia do testw integracyjnych

Narzdzia do testw komponentw mog by te uywane do wielu testw integracyjnych,
ale sabo nadaj si do wykonywania testw sterowanych poprzez interfejs uytkownika.
204
UML/MDA
Szczerze mwic, nie chcemy przeprowadza wielu testw sterowanych interfejsem

uytkownika, poniewa takie interfejsy cay czas si zmieniaj. Ich ulotno sprawia,
e wykorzystujce je testy s bardzo wraliwe.
Istnieje jednak pewien rodzaj testw, ktry musi uywa UI. Najwaniejsze s w tej grupie
same testy interfejsu uytkownika. Oprcz tego niektre testy musz angaowa zoony
w cao system, a to oznacza, e musz te uwzgldnia UI.
Narzdzia, ktrych najczciej uywam podczas testw interfejsw uytkownika,
to Selenium i Watir.
UML/MDA
Na pocztku lat 90. miaem wielk nadziej, e narzdzia typu CASE cakowicie zmieni
sposb, w jaki rozwijane jest oprogramowanie. Patrzc w przyszo, sdziem, e dzisiaj
kady bdzie tworzy oprogramowanie za pomoc diagramw na wysokim poziomie
abstrakcji, a kod skadajcy si z tekstu bdzie nalee do przeszoci.
Straszliwie si pomyliem. Nie chodzi nawet o to, e moje marzenie si nie spenio, ale
e kada prba jego realizacji skoczya si katastrofalnym fiaskiem. Oczywicie istniej
narzdzia i systemy bdce demonstracj moliwoci tej technologii, ale niestety nie s
one faktycznym spenieniem marzenia, a na dodatek wyglda na to, e nikt nie ma zamiaru
ich uywa.
Moje marzenie zakadao, e programici porzuc szczegowo kodu tekstowego i zaczn
tworzy systemy za pomoc wysokopoziomowych jzykw zbudowanych z diagramw.
Co wicej, mogoby si okaza, e wcale nie potrzebujemy programistw. Architekci mogliby
tworzy cae systemy za pomoc diagramw UML. Nastpnie zastpujce programistw
potne, cho zimne mechanizmy przeksztacayby te diagramy w wykonywalny kod. Tak
wanie wygldao wielkie marzenie o architekturze sterowanej modelami (MDA Model
Driven Architecture).
Niestety, w tym wspaniaym marzeniu bya maa skaza. MDA zakada, e to kod jest
problemem. Ale kod problemem nie jest. Nigdy nim nie by. Prawdziwym problemem
s szczegy.
Szczegy
Programici zarzdzaj szczegami. Dokadnie tak! Definiujemy zachowanie systemu
w najdrobniejszym detalu. Wykorzystujemy przy tym jzyki tekstowe (kod), poniewa
taka ich forma jest niezwykle wygodna (pomyl na przykad o jzyku polskim).
Jaki rodzaj szczegw musimy obsugiwa?
205
D ODATEK A
N ARZDZIA
Znasz rnic midzy znakami \n i \r? Pierwszy z nich (\n) oznacza wysunicie wiersza.
Drugi (\r) to powrt karetki. Ale czym jest karetka?
Na przeomie lat 60. i 70. najpowszechniejszym urzdzeniem wyjciowym komputerw
by teletekst. Najczciej uywany by model ASR-332.
Urzdzenie do miao gowic drukujc zdoln do wydrukowania dziesiciu znakw na
sekund. Skadaa si ona z maego cylindra, na ktrym wygrawerowane byy poszczeglne
znaki. By on przesuwany i obracany tak, eby w stron papieru skierowany by waciwy
znak. Pomidzy cylindrem a papierem bya umieszczona wstka z atramentem, ktry by
nakadany na papier w ksztacie wybranego znaku.
Caa gowica drukujca poruszaa si na karetce. Po wydrukowaniu kadego znaku karetka
bya przesuwana o jedn pozycj w prawo, przenoszc przy okazji gowic. Gdy ostatecznie
docieraa do koca 72-znakowego wiersza, trzeba byo nakaza jej powrt do pocztku,
wysyajc znak powrotu karetki (\r = 0x0D). Bez tego gowica wypisywaaby kolejne znaki
w 72. kolumnie, tworzc paskudny, czarny prostokt.
Oczywicie nie byo to wystarczajce. Powrt karetki na pocztek wiersza nie powodowa
podniesienia papieru o jeden wiersz. Jeeli po powrocie karetki nie zosta wysany znak
wysunicia wiersza (\n = 0x0A), to nowe znaki byy wypisywane w ju raz zapisanym wierszu.
Oznacza to, e w przypadku teletekstu ASR-33 sekwencj znakw koczc wiersz byo
"\r\n". Trzeba byo na to zwraca uwag, poniewa czas powrotu karetki mg by
duszy ni 100 ms. Jeeli wysaoby si sekwencj "\n\r", to kolejny znak mgby zosta
wydrukowany jeszcze w czasie, gdy karetka wracaa na pocztek wiersza, co utworzyoby
rozmazany znak gdzie na rodku strony. Na wszelki wypadek do sekwencji koczcej
wiersz czsto dodawalimy jeszcze jeden znak wymazywania3 (0xFF) lub dwa.
W latach 70. teleteksty zaczy wychodzi z uycia, a systemy operacyjne takie jak UNIX
skrciy sekwencj znakw koca wiersza do prostego "\n". Niestety, inne systemy
operacyjne, takie jak DOS, nadal stosoway star konwencj "\r\n".
Kiedy ostatnio podczas pracy z plikami tekstowymi zdarzyo Ci si zastosowa niewaciw
konwencj? Z problemem tym stykam si przynajmniej raz do roku. Dwa takie same pliki
tekstowe nie s identyczne, nie generuj tej samej sumy kontrolnej, poniewa maj inne
zakoczenia wierszy. Edytory tekstu nie zawijaj poprawnie wierszy albo tworz podwojone
http://en.wikipedia.org/wiki/ASR-33_Teletype.
Znaki wymazywania bardzo przydaway si podczas edytowania tam papierowych. Zgodnie

z konwencj znaki te byy ignorowane, ale ich kod 0xFF oznacza, e na tamie zostaway wybite
wszystkie dziurki. Oznaczao to, e kady znak dao si zmieni w znak wymazywania przez wybicie
dodatkowych dziurek. Dziki temu w przypadku popenienia bdu w czasie wpisywania programu
mona byo cofn si do tego znaku, nacisn klawisz wyma (ang. rubout) i pisa dalej.
206
W NIOSKI
odstpy midzy nimi, gdy zakoczenia wierszy s nieprawidowe. Programy, ktre nie
dopuszczaj pustych wierszy, odmawiaj dziaania, poniewa interpretuj znaki \r\n jako
dwa wiersze. Niektre programy rozpoznaj sekwencj \r\n, ale nie znaj ju \n\r. Mona
tak dugo opowiada.
Dlatego wanie wspomniaem o szczegach. Sprbuj zapisa straszliw logik algorytmu
sortowania za pomoc UML!
Bez nadziei, bez zmian

Nadziej zwizan z przejciem na MDA byo to, e wielk cz szczegw bdzie mona
wyeliminowa przez zastpienie kodu diagramami. Ta nadzieja zostaa jednak porzucona.
Okazuje si, e w kodzie nie ma zbyt wielu szczegw, ktre mona by wyeliminowa za
pomoc obrazkw. Co wicej, obrazki wprowadzaj swoj wasn grup szczegw. Maj
swoj gramatyk, skadni, reguy i ograniczenia. A zatem nie ma adnej rnicy.
Nadziej zwizan z MDA byo to, e diagramy stan si wyszym poziomem abstrakcji
kodu, tak jak Java jest na wyszym poziomie w stosunku do asemblera. I ponownie ta
nadzieja okazaa si le ulokowana. Rnica w poziomie abstrakcji jest w najlepszym razie
minimalna.
Zamy na koniec, e pewnego dnia komu uda si wymyli naprawd przydatny jzyk
diagramowy. Rysowaniem tych diagramw nie bd si zajmowa architekci, ale programici,
poniewa stan si one po prostu now form kodu, ktr programici bd rysowa, a nie
pisa. Ostatecznie wszystko sprowadza si do szczegw, a to wanie programici zajmuj
si szczegami.
Wnioski
Od czasu gdy zaczem zajmowa si oprogramowaniem, narzdzia programistyczne zyskay
wiele moliwoci i stay si bardziej rnorodne. Osobicie uywam tylko niewielkiego
podzbioru tej caej menaerii. Do kontroli wersji kodu rdowego uywam Gita, Trackera
do zarzdzania problemami, Jenkinsa do cigej kompilacji, IntelliJ jest moim IDE, XUnit
suy mi do testw, a FitNesse do testowania komponentw.
Moim komputerem jest MacBook Pro, 2,8 GHz Intel Core i7, z 17-calowym matowym
ekranem, 8 GB pamici RAM, 512-gigabajtowym dyskiem SSD i dwoma dodatkowymi
ekranami.
207
D ODATEK A
N ARZDZIA
208
S KOROWIDZ
A
algebra Boolea, 183
algorytm sortowania, 111
analityk biznesowy, 124, 132, 169, 176, 177, 204
analiza
strukturalna, 45
trzech zmiennych, 154
API, 127, 128
testowanie, Patrz: test API
aplikacja mobilna, 61
architekt, 45, 135, 205, 207
architektura sterowana modelami, Patrz: MDA
artefakt, 45
B
backlog, 140, 141
Beck Kent, 98, 141
biblioteka zewntrzna, 101
biznesmen, 116, 117
Blanco John, 60
blokowanie pesymistyczne, 196
bdy, 39, 80, 131, 201
regresyjne, 133
Boehm Barry, 157
Boolea algebra, 183
Bossavit Laurent, 109
Bowling game, Patrz: Gra w krgle
C
Carlin Jim, 186
CASE, 205
CDS, 70
cele, 52
CI, Patrz: system cigej integracji
cig Fibonacciego, 158, 159
Coding Dojo, Patrz: dojo kodowania
Conrad Tim, 167
continuous integration system, Patrz: system cigej
integracji
CppUTest, 202
Craft Dispatch System, Patrz: CDS
Cucumber, 93, 124, 134, 204
cuke4duke, 124
Cunningham Ward, 204
CVS, 196
Czynnik pierwszy, 46
wiczenia, 46, 105, 108, 113, 187, 190
D
De Morgana twierdzenie, 183
debugowanie, 87, 98
czas, 89
DeMarco Tom, 118
209
S KOROWIDZ
DFD, 45
diagram
przej stanw, 45
przepywu, 45
przepywu danych, 44
UML, 205
Digi-Comp, 182
dojo kodowania, 109, 110
dokument wymaga systemu, 118
dokumentacja, 101, 127
niskopoziomowa, 102
E
Eclipse, Patrz: edytor Eclipse
ECP-18, 184
edytor, 116
Eclipse, 199, 200
Emacs, 199
IntelliJ, 200
TextMate, 200, 202
vi, 199
efekt obserwatora, 117
elektroniczny recepcjonista, 69
Emacs, Patrz: edytor Emacs
Emma, 41
Extreme Programming, Patrz: XP
F
Fibonacciego cig, 158, 159
Finder Ken, 69
FitNesse, 40, 41, 93, 100, 108, 124, 134, 198, 204
Fitzpatrick Jerry, 69
flow, Patrz: przepyw
funkcja, 102
G
Git, 197, 198
gra ping-pong, Patrz: ping-pong
Gra w krgle, 46, 109
gracz zespoowy, 55, 57, 59
Green Pepper, 204
Grenning James, 158
GUI, Patrz: interfejs uytkownika
210
H
hierarchia dziedziczenia, 43
hiperproduktywno, Patrz: przepyw
Hipokrates, 38
Hoffa Jimmy, 49
I
IDE, Patrz: edytor
idiom nawigacyjny, 110
instrukcja wyboru, 43
IntelliJ, Patrz: edytor IntelliJ
interfejs uytkownika, 127, 128, 205
iteracja, 140, 195
retrospektywa, 141
J
JBehave, 134, 204
Jenkins, 202
jzyk
makr, 116
skryptowy, 116
zobowiza, 71, 72, 74, 75
JUnit, 202, 203
K
karetka, 206
kariera, 43, 44
kata, 46, 109
kod
edytowanie, 199
gotowy, 92, 120, 203
inspekcja, 173
pokrycie testami, 99
struktura, 41, 79
tworzenie, 79, 80, 82, 85, 86, 87, 90, 91, 92, 93, 98,
146, 164
czas, 89
wasno, 172
kompilacja, 98, 107
ciga, 202
nieudana, 99
kontrola jakoci, 39, 41, 132
S KOROWIDZ
L
latajce palce, 157, 158
Lighthouse, 201
Lindstrom Lowell, 159
O
odpowiedzialno, 36, 39, 43, 47, 72, 164
zasada, Patrz: SRP
odwrcenie priorytetw, 145
oprogramowanie, 188
optymalizacja, 168
Osherove Roy, 70, 71
acuch dowodzenia, 43
M
manna skupienia, 142, 143
maszyna stanu, 44
MDA, 205, 207
Mealy George, 44
medytacja, 83
meneder, 115, 118, 169, 176, 177, 195
mentor, 95, 187, 189
metodologia, 189
analizy strukturalnej, 45
Kanban, 45
Lean, 45
projektowania strukturalnego, 45
Scrum, 45, 97
wodospadu, 45
XP, 45
zwinna, 97, 140, 201
Midje, 202
mikrozarzdzanie, 54
mistrz, Patrz: mentor
Model Driven Architecture, Patrz: MDA
Moore Gordon, 44
Moore Michael, 107
Murphy'ego prawo, 153
muzyka, 84, 108, 110
N
narzdzia, 195, 196, 197, 201, 202
CASE, 205
edytowanie kodu, Patrz: edytor
o otwartych rdach, 195
test
integracyjny, 204
jednostkowy, 202
komponentw, 203, 204
Nassi Ike, 44
NUnit, 202
P
PERT, 157
Petriego sie, 45
ping-pong, 111
Pivotal Tracker, 201
planning poker, Patrz: planujcy poker
planujcy poker, 158
poczta gosowa, 69, 70
polimorfia, 43
pomodoro technique, Patrz: technika pomidora
powrt karetki, 206
prawdopodobiestwo, 153
rozkad, 153, 154, 155
prawo
Murphy'ego, 153
wielkich liczb, 159
Prime factor, Patrz: Czynnik pierwszy
problem
pnej wieloznacznoci, 118
przedwczesnej dokadnoci, 118
profesjonalizm, 36
program, Patrz: projekt
Program Evaluation and Review Technique,
Patrz: PERT
programista, 45, 52, 60, 61, 65, 101, 115, 118, 120,
125, 127, 133, 149, 169, 176, 190, 195, 205, 207
czeladnik, 189, 190
gracz zespoowy, Patrz: gracz zespoowy
mistrz, Patrz: mentor
pod presj, 162, 163, 165
praktykant, 189, 190
rzemielnik, 190, 191
szkolenie, 189
wsppraca, 46, 160, 167, 169, 172, 173, 176, 177
zesp, Patrz: programowanie w zespole
programowanie, 48, 80, 86, 89, 90, 93, 98, 142, 144, 146
blokada, 85, 86, 196
ekstremalne, Patrz: XP
211
S KOROWIDZ
programowanie
lista problemw, 201
czenie edytowanych plikw, 196
metod cigej integracji, 45
narzdzia, Patrz: narzdzia
nauczanie, 182, 186, 187
obiektowe, 61
rozgazienie, Patrz: rozgazienie
sterowane testami, Patrz: TDD
strukturalne, 45
szacowanie, 118, 149, 151, 152, 153, 154, 157, 158,
159, 160, 190
ledzenie problemw, 201
tempo, 177
w parach, 45, 47, 84, 85, 164, 166, 172, 173, 189
w systemie wodospadu, 44
w zespole, 167, 172, 174, 176, 177
projekt
elastyczno, 42
funkcja, 41
iteracja, Patrz: iteracja
otwartordowy, 40
struktura, 41, 45
waciciel, 178
zmiany, 41
projektant, 45
gracz zespoowy, Patrz: gracz zespoowy
projektowanie, 65
fakty, 54
koszty, 54
obiektowe, 45, 150
strukturalne, 45
zasady, 45
SOLID, 45
przeklestwo Santayany, 45
przepyw, 83, 84
przerwy, 85
przysiga Hipokratesa, 38
R
randori, 111
raport Emma, 41
refaktoryzacja, 42, 46, 83, 107, 165, 190
regua
biznesowa, 128, 129
dziury, 146
skauta, 42
rezydentura, 188
212
Robot Framework, 124

RobotFX, 93, 204
rozgazienie, 197
RSPEC, 202
rzemioso, 190, 191
S
Santana Carlos, 108
Santayany przeklestwo, 45
scenariusz, 125
Schneiderman Ben, 44
Selenium, 93, 124, 134, 205
sie Petriego, 45
Single Responsibility Principle, Patrz: SRP
skrt klawiszowy, 110
spotkanie
cel, 140
demonstracja produktu, 141
koszt, 138
na stojco, 140
plan, 140
planujce iteracje, 140, 141
retrospektywa iteracji, 141
selekcja, 138
wychodzenie, 139
SRP, 128
staysta, 187
strefa, 83, 84, 85
strona trzecia, 62
struktury wykres, 45
SVN, 196, 197, 198
system
cigej integracji, 110, 129
konstrukcja, 136
kontroli wersji, 129, 195, 202
CVS, Patrz: CVS
Git, Patrz: Git
klasy enterprise, 195
rozproszone, 197
Subversion, Patrz: SVN
SVN, Patrz: SVN
przydzielajcy zadania, Patrz: CDS
testowanie, Patrz: test systemu
szacunek
normalny, 155
optymistyczny, 154
pesymistyczny, 155
szkolenia, 43
S KOROWIDZ
T
tabela
decyzji, 45
przej stanw, 45
tablica Parnasa, 44, 204
TDD, 41, 45, 83, 85, 89, 97, 98, 99, 100, 101, 103, 109,
110, 133, 136, 164, 165, 190
Teamsters, 49
technika
oceny i rozwoju programw, Patrz: PERT
PERT, Patrz: PERT
pomidora, 144
test, 42, 131, 133
akceptacyjny, 41, 93, 100, 120, 125, 127, 129, 133,
134, 141
automatyzacja, 123, 124, 130, 176
bdy, 126
GUI, Patrz: test akceptacyjny interfejsu
uytkownika
interfejsu uytkownika, 128, 129
komunikacja, 122
tworzenie, 124
API, 128
automatyzacja, 133
badawczy, 132
choreografii, 135
hydrauliczny, 135
integracyjny, 135
narzdzia, Patrz: narzdzia test integracyjny
interfejsu uytkownika, 128, 129, 205
jednostkowy, 40, 41, 63, 99, 102, 127, 129, 133, 165
narzdzia, Patrz: narzdzia test jednostkowy
komponentw, 134, 141
narzdzia, Patrz: narzdzia test komponentw
manualny, 123, 136
optymistyczny, 132
pesymistyczny, 132
systemowy, 135
zestaw zautomatyzowany, 42
Test Driven Development, Patrz: TDD
tester, 169, 176, 177, 204
testowanie, 131, 133
TextMate, Patrz: edytor TextMate
Thomas Dave, 109
twierdzenie De Morgana, 183
U
UML, 45, 205
W
warunki kracowe, 132, 134
wasa, 111
Watir, 134, 205
wideband delphi, 157, 158, 159
waciciel projektu, 178
wykres
Nassiego-Schneidermana, 44
struktury, 45
wypalenie zawodowe, 44
wzorzec projektowy, 45, 61, 190
X
XP, 97
Z
zaangaowanie, 72
zarzdzanie czasem, 137, 144, 145, 147
zasada
niepewnoci, 117
pojedynczej odpowiedzialnoci, Patrz: SRP
zesp, Patrz: programowanie w zespole
zobowizanie, 71, 72, 73, 74, 75, 151, 154, 160, 163
ukryte, 153
zone, Patrz: strefa
213

MistrzCzystegoKodu PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MistrzCzystegoKodu PDF

Transféré par

Droits d'auteur :

Formats disponibles

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.

Pole ksik na Facebook.com

Kup w wersji papierowej

Lubi to! Nasza spoeczno

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Pochway dla Mistrza czystego kodu

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

W latach od 1986 do 2000 cile wsppracowaem z Jimem Newkirkiem, koleg z firmy

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Uwaaj, czego sobie yczysz

Kiedy mwi nie

Kiedy mwi tak

Kontrola jakoci nie powinna nic znale

Nauczanie, terminowanie i mistrzostwo

Skoro ta ksika wzbudzia w Tobie zainteresowanie, to zakadam, e mam do czynienia

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Byem technicznym menederem projektu, awansowanym z dziau rozwojowego. Moim

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Oj, to moe potrwa troch duej.

Matt: Przecie maj cay weekend. To masa czasu. Do roboty!.

No tak, ale tutaj mwimy o zawodowcach.

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

W tym czasie uwaaem, e zesp techniczny skada si z zawodowcw w najlepszym

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

W niektrych przypadkach takie przykady s absolutnie dosowne.

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

nieskoordynowane siy spowodoway, e leccy z prdkoci 1,5 macha prom zacz

W tych pragmatycznych poradach znajdziesz te rodzc si postaw. Jest to postawa pena

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Robert C. Martin (Wujek Bob) by programist od 1970 roku. Jest zaoycielem

Extreme Programming in Practice

Niesamowity obraz umieszczony na okadce (przypomina oko Saurona) to M1 lub mgawica

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Obrazek umieszczony na okadce jest zoeniem obrazw wiata widzialnego oraz

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Zakadam, e masz w rce t ksik, poniewa jeste programist i zaintrygowaa Ci

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

na najnowoczeniejszych, osadzonych systemach sprztowo-programowych, ale te na

Easycoder by jzykiem asemblera komputerw Honeywell H200, bardzo podobnym do jzyka

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Swj program napisaem na formularzach do programowania. Byy to wielkie prostoktne

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

danych zapisywanych na tamie. Moim zadaniem byo adowanie papieru do drukarek,

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Dobrze rozumiem, e chcesz by zawodowym programist? Chcesz unie wysoko gow

Uwaaj, czego sobie yczysz

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Naszymi klientami byli menederowie serwisu najwikszych firm telekomunikacyjnych.

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

Zadzwoniem to Toma, mwic mu, e udao mi si odtworzy problem. Odpowiedzia,

Po pierwsze nie szkodzi

Ebookpoint.pl kopia dla: Jaroslaw Babijczuk siarsko@gmail.com

P O PIERWSZE NIE SZKODZI

Nie szkodzi funkcji