Debugowanie. Jak wyszukiwać
Idz
do
i naprawiać błędy w kodzie
" Spis treści oraz im zapobiegać
" Przykładowy rozdział
Autor: Paul Butcher
Tłumaczenie: Andrzej Grażyński
Katalog książek ISBN: 978-83-246-2760-8
Tytuł oryginału: Debug It!: Find, Repair,
and Prevent Bugs in Your Code
" Katalog online
Format: 158´ð235, stron: 240
" Zamów drukowany
katalog
Mistrz debugowania w akcji!
" Jak tworzyć oprogramowanie, które łatwo się debuguje?
Twój koszyk
" Jak wykrywać potencjalne przyczyny problemów?
" Jak ominąć pułapki czyhające na programistów?
" Dodaj do koszyka
Zapewne niejednokrotnie podczas pracy przy komputerze musiałeS
użerać się z wadliwymi
aplikacjami. Doskonale wiesz, jak to jest, kiedy kolejne łatki usuwają stare błędy,
równoczeS
nie generujÄ…c nowe, programiS
ci zaS
nie kwapią się do zmiany niewłaS
ciwych
Cennik i informacje
założeń. A przecież jednym z najbardziej niedocenianych aspektów profesjonalnego
programowania jest zdolnoS
ć do rozpoznawania i usuwania błędów kryjących się
" Zamów informacje
w każdej większej partii stworzonego kodu. JeS
li tworzysz niebanalne aplikacje,
o nowościach
najprawdopodobniej zajmiesz się ich debugowaniem chwilę po zakończeniu ich pisania.
To zajęcie w zdecydowanie większym stopniu niż inne aspekty tworzenia oprogramowania
" Zamów cennik
jest działalnoS
cią intelektualną  ponieważ jego areną jest umysł programisty.
Znajdowanie i wyjaS
nianie przyczyn problemów powinno być pierwszą czynnoS
ciÄ… na
Czytelnia
drodze do ich zwalczania.
Ta książka poS
więcona jest właS
nie arkanom sztuki debugowania. Jej lektura pozwoli
" Fragmenty książek
Ci znacznie ograniczyć liczbę popełnianych błędów, a te, które się pojawią, będą
online
łatwiejsze do wykrycia i usunięcia. Podręcznik wyjaS
ni Ci, jak pisać kod, który łatwo
debugować, przeprowadzi Cię przez proces wykrywania błędów, ich reprodukcji,
diagnozowania, aż do wprowadzania i wycofywania poprawek w oprogramowaniu.
Poznaj empiryczną metodę wykrywania błędów. Dowiedz się, jak ważne jest zapewnienie
sobie pewnych sposobów reprodukowania błędnych zachowań. Naucz się unikać
pułapek czyhających zarówno na programistów, jak i testerów. Stosuj powszechnie
używane narzędzia i metody zapewniające automatyczne wykrywanie potencjalnych
przyczyn problemów, zanim jeszcze się one pojawią! Naucz się tworzyć samodebugujące
oprogramowanie, które automatycznie informuje o swoim stanie, a także sprawdx
, co
możesz zrobić, aby szybko wykrywać sytuacje będące potencjalną przyczyną problemów.
" Metoda empiryczna
" Reprodukcja błędów
Kontakt
" Diagnozowanie
" Wyszukiwanie błędów
" Wprowadzanie i wycofywanie poprawek
Helion SA
ul. Kościuszki 1c " Testowanie
44-100 Gliwice
" Przyczyny błędów
tel. [phone]
" Oprogramowanie samodebugujÄ…ce
e-mail: [e-mail]
" Narzędzia wspomagające
© Helion 1991 2010
Spis tre ci
Od t umacza s ów kilka .................................................................................... 9
Przedmowa ...................................................................................................... 13
Cz I. Istota problemu
Rozdzia 1. W tym szale stwie jest metoda ................................................ 19
1.1. Debugowanie to co wi cej ni eksterminacja b dów ................................................ 20
1.2. Metoda empiryczna ................................................................................................ 22
1.3. Struktura procesu debugowania .............................................................................. 23
1.4. Przede wszystkim rzeczy najwa niejsze .................................................................... 24
1.5. Do dzie a! ............................................................................................................. 28
Rozdzia 2. Reprodukcja ................................................................................. 29
2.1. Najpierw reprodukcja, potem pytania ...................................................................... 29
2.2. Kontrolowane zachowanie aplikacji ......................................................................... 32
2.3. Kontrolowane rodowisko ....................................................................................... 32
2.4. Kontrolowane dane wej ciowe ................................................................................. 34
2.5. Ulepszanie reprodukcji ........................................................................................... 43
2.6. Gdy b d nie chce si ujawni ................................................................................. 52
2.7. Podsumowanie ...................................................................................................... 55
Rozdzia 3. Diagnoza ....................................................................................... 57
3.1. Gdy debugowanie staje si nauk ............................................................................ 57
3.2. Sztuczki i chwyty .................................................................................................... 63
3.3. Debuggery ............................................................................................................. 70
6 Debugowanie
3.4. Pu apki ................................................................................................................. 71
3.5. Gry umys owe ........................................................................................................ 76
3.6. Zweryfikuj swoj diagnoz ...................................................................................... 80
3.7. Podsumowanie ...................................................................................................... 81
Rozdzia 4. Poprawki ...................................................................................... 83
4.1. Czysta tablica ........................................................................................................ 84
4.2. Testowanie ............................................................................................................ 85
4.3. Eliminowanie przyczyn, nie objawów ....................................................................... 87
4.4. Refaktoryzacja ....................................................................................................... 89
4.5. Kontrola wersji ...................................................................................................... 91
4.6. Inspekcja kodu ....................................................................................................... 92
4.7. Podsumowanie ...................................................................................................... 93
Rozdzia 5. Refleksja ....................................................................................... 95
5.1. Jak to w ogóle mog o dzia a ? ................................................................................. 95
5.2. Co posz o nie tak? .................................................................................................. 97
5.3. Nigdy wi cej tego samego b du .............................................................................. 99
5.4. Zamykanie p tli ................................................................................................... 102
5.5. Podsumowanie .................................................................................................... 102
Cz II. Szersza perspektywa
Rozdzia 6. Chyba mamy problem& ........................................................... 105
6.1. Tropienie b dów ................................................................................................. 106
6.2. Wspó praca z u ytkownikami ................................................................................ 109
6.3. Wspó dzia anie z innymi zespo ami ....................................................................... 116
6.4. Podsumowanie .................................................................................................... 117
Rozdzia 7. Pragmatyczna nietolerancja .................................................... 119
7.1. B dy maj pierwsze stwo .................................................................................... 119
7.2. Debugowanie a psychologia .................................................................................. 122
7.3. Zasypywanie przepa ci jako ciowej ....................................................................... 125
7.4. Podsumowanie .................................................................................................... 129
Cz III. Debug-Fu
Rozdzia 8. Przypadki szczególne ................................................................ 133
8.1. atanie istniej cego oprogramowania .................................................................... 133
8.2. Kompatybilno wersji .......................................................................................... 134
8.3. Wspó bie no ..................................................................................................... 139
Spis tre ci 7
8.4. B dy heisenbergowskie ........................................................................................ 142
8.5. Problemy z wydajno ci ....................................................................................... 144
8.6. Systemy osadzone ................................................................................................ 147
8.7. B dy w obcym oprogramowaniu ........................................................................... 150
8.8. Podsumowanie .................................................................................................... 154
Rozdzia 9. Idealne rodowisko debugowania .......................................... 155
9.1. Automatyczne testowanie ..................................................................................... 155
9.2. Kontrola wersji .................................................................................................... 158
9.3. Automatyczne budowanie binariów ....................................................................... 163
9.4. Podsumowanie .................................................................................................... 171
Rozdzia 10. Naucz swe oprogramowanie samodebugowania ................ 173
10.1. Za o enia i asercje ............................................................................................. 174
10.2. Binaria debugowalne .......................................................................................... 184
10.3. Wycieki zasobów i b dna obs uga wyj tków ........................................................ 189
10.4. Podsumowanie .................................................................................................. 195
Rozdzia 11. Antywzorce .............................................................................. 197
11.1. Inflacja priorytetów ............................................................................................. 197
11.2. Primadonna ....................................................................................................... 198
11.3. Zespó serwisowy ............................................................................................... 200
11.4. Gaszenie po aru ................................................................................................ 202
11.5. Pisanie od nowa ................................................................................................. 203
11.6. Bezpa ski kod ................................................................................................... 205
11.7. Czarna magia .................................................................................................... 206
11.8. Podsumowanie .................................................................................................. 207
Dodatki
Dodatek A Materia y .................................................................................... 211
A.1. Systemy kontroli wersji i ledzenia problemów ....................................................... 211
A.2. Narz dzia zarz dzania generowaniem binariów i integracj ci g .......................... 215
A.3. Przydatne biblioteki ............................................................................................ 216
A.4. Inne narz dzia .................................................................................................... 218
Skorowidz ...................................................................................................... 223
Rozdzia 1. " W tym szale stwie jest metoda 19
Rozdzia 1.
W tym szale stwie
jest metoda
ego mo na si by o spodziewa : stworzony program nie chce dzia a , a je eli
ju dzia a, to w sposób dziwaczny. I co teraz?!
T
Niew tpliwie po yteczny okazuje si wówczas nawyk systematyczno ci, czyli
d enie do znalezienia prawdziwej przyczyny (przyczyn) tak dziwacznego zachowania
(starannie przecie napisanego) programu, wielu programistów jednak zdaje si
wykazywa objawy chaotycznego  by nie rzec rozpaczliwego  miotania si po
kodzie programu, bez wyra nego celu i (co zrozumia e) bez widocznych rezultatów.
Có jednak odró nia obie te grupy od siebie?
W tym rozdziale przyjrzymy si dok adnie metodom debugowania kodu, sprawdzo-
nym w warunkach profesjonalnego wytwarzania oprogramowania. Nie da si ich, co
prawda, porówna do kamienia filozoficznego, zamieniaj cego powszedni materi
 czyli owoc niedoskona ych dzia a omylnych programistów  w z oto, czyli kod
dzia aj cy niezawodnie i bezb dnie; w dalszym ci gu nieocenione okazuj si okre-
lone kwalifikacje programisty czy testera  wiedza, do wiadczenie, intuicja, zdolno-
ci detektywistyczne, no i  oczywi cie  odrobina szcz cia. Metody te umo liwiaj
odpowiednie ukierunkowanie zainwestowanego wysi ku, pozwalaj unikn bezsen-
sownego dr enia rozmaitych hipotez, a w konsekwencji otwieraj drog  mo liwie
krótk  dotarcia do prawdziwej przyczyny problemu. Poznamy kilka konkretnych
koncepcji, sk adaj cych si na wspomnian metodologi , m.in.:
ró nic mi dzy  debugowaniem a  usuwaniem b dów ,
podej cie empiryczne, czyli niech oprogramowanie samo zademonstruje,
co si z nim dzieje,
20 Cz I " Istota problemu
podstawowe elementy procesu debugowania  reprodukowanie b dów,
diagnozowanie ich przyczyny, poprawianie kodu i wyci ganie wniosków
na przysz o ,
konieczno dok adnego rozumienia sensu podejmowanych dzia a .
1.1. Debugowanie to co wi cej
ni eksterminacja b dów
Spytajcie niedo wiadczonego programist , co oznacza termin  debugowanie , a us y-
szycie, e jest to  znajdowanie b dów czy inn podobn odpowied . Oczywi cie,
eliminowanie b dów jest jednym z elementów debugowania, nie jest to jednak
element jedyny ani nawet najwa niejszy. Efektywne debugowanie ukierunkowane
jest pod k tem istotnych celów. Oto one.
1. Znalezienie przyczyny nieoczekiwanego zachowania programu.
2. Wyeliminowanie tej przyczyny.
3. Zapobieganie sytuacjom, w których wyeliminowanie jednej przyczyny
jednej grupy b dów staje si kolejn przyczyn innych b dów.
4. Utrzymanie (a nawet ulepszenie) ogólnej jako ci kodu  jego czytelno ci,
przejrzysto ci, stopnia pokrycia przypadkami testowymi, wydajno ci, atwo ci
konserwacji i rozbudowy itp.
5. Upewnienie si , e okre lony problem zosta ca kowicie wyeliminowany
z kodu programu i nie da zna o sobie nigdy wi cej.
Nieprzypadkowo najwa niejszy okazuje si pierwszy z wymienionych celów  od
prawid owego rozpoznania rzeczywistej przyczyny problemu uzale nione jest po-
wodzenie pozosta ych dzia a .
Przede wszystkim  zrozumie
Pocz tkuj cy, niedo wiadczeni programi ci (i, niestety, wielu uwa aj cych si za
do wiadczonych) cz sto zaniedbuj rozpoznanie problemu  u ród a , ograniczaj c
si do dokonywania dora nych poprawek, które powinny przywróci 1 poprawne
1
Nie mo na, oczywi cie, przywróci czego , czego nigdy nie by o, szczególnie nie mo na przywróci
poprawnego dzia ania programu, który nigdy poprawnie nie dzia a . To prawda, nie zapominajmy
jednak, e ka dy tworzony przez nas program funkcjonuje poprawnie w naszych oczekiwaniach,
w naszej wyobra ni (a bywa i tak, e faktycznie okazuje si od razu bezb dny  najbardziej
odpowiednim pytaniem pod adresem programisty mo e by wówczas:  Co zamierzasz zrobi na bis? ).
Umówmy si wi c, i owo  przywrócenie oznacza przywrócenie adekwatno ci naszych oczekiwa
po pocz tkowo frustruj cej konfrontacji z rzeczywisto ci  przyp. t um.
Rozdzia 1. " W tym szale stwie jest metoda 21
funkcjonowanie programu. Gdy programista ma troch szcz cia, owe dora ne zabiegi
okazuj si od razu chybione, co umo liwia unikni cie marnotrawstwa czasu i wysi ku,
niekiedy jednak, niestety, faktycznie eliminuj konkretny b d lub stwarzaj pozory
jego wyeliminowania.  Niestety , poniewa w ostatecznym rozrachunku okazuje si ,
e owe nieprzemy lane i nie do ko ca zrozumiane zabiegi jedynie maskuj prawdziwe
przyczyny b dów, które niespodziewanie mog si ujawni , gdy b dziemy tego naj-
mniej oczekiwa . Co gorsza, nieprzemy lane atanie kodu mo e mie zgubne konse-
kwencje w postaci destrukcji regresywnej, czyli ponownego wprowadzenia do kodu
b dów, których przyczyny zosta y wcze niej wyeliminowane.
Zmarnowany czas i wysi ek
Kilka lat temu przysz o mi wspó pracowa z zespo em bardzo do wiadczonych
i utalentowanych programistów. Swe zawodowe umiej tno ci zdobywali oni
na bazie systemów klasy UNIX, jednak gdy do nich do czy em, dokonywali
migracji uniksowego oprogramowania na platform Windows; migracja ta
znajdowa a si ju w do zaawansowanym stadium.
Jeden z  b dów wynikaj cych z migracji ujawnia si w warunkach rów-
noleg ej pracy wielu w tków. Niektóre w tki funkcjonowa y bez zarzutu,
inne jednak zdawa y si pozostawa w stanie zag odzenia2. Poniewa
w rodowisku UNIX-a wszystko funkcjonowa o bezb dnie, przyczyna
problemu zdawa a si ewidentnie tkwi w specyfice mechanizmu zarz dzania
w tkami przez Windows. Podj to wi c decyzj o stworzeniu w asnego pod-
systemu zarz dzania w tkami, zast puj cego oferowany standardowo przez
Windows  przedsi wzi cie, owszem, bardzo ambitne i pracoch onne, nie-
mniej jednak mieszcz ce si w granicach mo liwo ci wspomnianego zespo u.
I rzeczywi cie, gdy do czy em do zespo u, wydawa o si , e wspomniany
podsystem spe nia pok adane w nim nadzieje  nie zdarza y si ju
przypadki zag odzenia w tków. Jednak tak g boka ingerencja w system
operacyjny rzadko obywa si bez skutków ubocznych i nie inaczej by o tym
razem: cen zap acon za ulepszone zarz dzanie w tkami okaza o si ogólne,
zauwa alne spowolnienie pracy ca ego systemu Windows.
Dla mnie ca a ta sytuacja by a o tyle intryguj ca, e sam w przesz o ci
musia em zmaga si z rozmaitymi problemami wynikaj cymi z wielow tkowej
architektury tworzonych przeze mnie aplikacji dla Windows. Pobie na analiza
problemu, którego konsekwencj by a g boka ingerencja w system operacyjny,
wykaza a, e jego rzeczywist przyczyn jest dynamiczne zwi kszanie priorytetu
w tków (dynamic thread priority boost), które wy czy mo na w sposób
2
Zag odzeniem (starvation) w tku lub procesu nazywamy sytuacj , w której mechanizmy szere-
gowania systemu operacyjnego konsekwentnie ignoruj ów w tek lub proces w rywalizacji o dost p
do zasobów, w tym przypadku w rywalizacji o czas procesora  przyp. t um.
22 Cz I " Istota problemu
elementarny, wywo uj c funkcj API SetThreadPriorityBoost(). Zamiast
pracoch onnego  i podatnego na b dy  tworzenia w asnego systemu
szeregowania w tków, wystarczy oby dodanie jednego wiersza kodu.
Mora ? Obserwuj c niepo dane zachowanie aplikacji, zespó programistów
dopatrzy si jego przyczyny w ogólnej architekturze Windows, bez g bszej
analizy uwik anego w to zachowanie podsystemu. Na pewno nie bez znaczenia
by y uwarunkowania kulturowe, czyli mówi c po prostu, acz delikatnie, nie
najlepsza reputacja systemu Windows w rodowisku  hakerów uniksowych .
Tak czy inaczej, gdyby programi ci z zespo u po wi cili nieco czasu na
wnikliw analiz zjawiska i tkwi cych u jego przyczyny mechanizmów oraz
dost pnych ustawie , zaoszcz dziliby znacznie wi cej czasu, jaki stracony
zosta na  niepotrzebn w gruncie rzeczy  konstrukcj w asnego
podsystemu. Unikn liby ponadto degradacji wydajno ci systemu Windows
i (bez w tpienia) wprowadzenia do nowych b dów.
Mówi c dosadnie: gdy rezygnujemy z poszukiwa prawdziwych przyczyn ujawniaj -
cych si b dów, sami wystawiamy si poza nawias in ynierii programowania, za-
puszczamy si w zdradliwy g szcz  programowania voodoo 3 lub  lub programowania
przez przypadek 4.
1.2. Metoda empiryczna
Do zrozumienia przyczyny zaistnia ych b dów, manifestuj cych si niezgodnym
z oczekiwaniami dzia aniem aplikacji, mo na dochodzi ró nymi drogami. Generalnie
ka da metoda, która przybli a do tego celu, mo e by uznana za w a ciw .
A skoro tak, to w wi kszo ci przypadków debugowania najbardziej celowe  bo
wysoce produktywne  okazuje si podej cie empiryczne.
Podej cie to zasadza si na obserwacjach i do wiad-
Eksperymentuj
czeniu, a nie na teorii czy te czysto logicznych spe-
i obserwuj wyniki.
kulacjach. Owszem, mo na studiowa kod programu
i wyci ga z niego wnioski na temat skutków wykonania
poszczególnych jego fragmentów (i czasem zdarza si , e nie ma innego wyboru),
3
argonowe okre lenie na laduj ce powiedzenie prezydenta George a Busha seniora, który mia-
nem  voodoo economics okre la niektóre gospodarcze posuni cia Ronalda Reagana. Oznacza
u ywanie w programowaniu funkcji lub algorytmów, których dzia ania nie rozumie si w pe ni,
wskutek czego program nie dzia a albo je li przypadkiem dzia a, programista i tak nie rozumie, dla-
czego tak si dzieje, cytat z pl.wikipedia.org  przyp. t um.
4
Andrew Hunt, David Thomas, The Pragmatic Programmer: From Journeyman to Master, Addi-
son-Wesley, Reading, MA, 2000.
Rozdzia 1. " W tym szale stwie jest metoda 23
A propos natury oprogramowania&
 Oprogramowanie to kategoria zas uguj ca na szczególn uwag  co dla
nas, maj cych z ni do czynienia na bie co, nie zawsze jest oczywiste.
Niewiele jest w ludzkiej dzia alno ci innych obszarów daj cych tak wielk oka-
zj do nieograniczonej niemal realizacji w asnej pomys owo ci, wynalazczo ci;
niewiele jest przyk adów tworzywa intelektualnego daj cego si kszta towa
w tak plastyczny sposób. Oprogramowanie ma t cenn zalet , e jest no ni-
kiem determinizmu  poza nielicznymi wyj tkami, które opiszemy w dalszej
cz ci ksi ki, kolejny stan jego realizacji wyznaczony jest jednoznacznie przez
stany poprzednie, a my uzyskujemy powtarzalny dost p do ka dego ze stanów
na ka de danie.
Nie maj tego szcz cia przedstawiciele wi kszo ci dziedzin tradycyjnej in ynierii.
Bo czy mo na wyobrazi sobie mechanika Formu y 1, przygl daj cego si sil-
nikowi obracaj cemu si z pr dko ci 19000 obrotów na minut i momentalnie
 jakby w rezultacie mentalnego zatrzymania tych obrotów  zg biaj cego
wszelkie detale rozmaitych konsekwencji tej dynamiki? Albo szczegó owo ana-
lizuj cego przebieg zap onu w komorze spalania? W konfrontacji z szybko ci
dzia ania ludzkich zmys ów wydaje si to absolutnie niewykonalne i faktycznie
takie jest.
W naszym oprogramowaniu kr c ca si z szybko ci milionów (czy nawet mi-
liardów) na sekund p tla wolna jest od owego pi tna ulotno ci. Gdy na danie
zostaje zatrzymana  w precyzyjnie okre lonym miejscu  mo emy drobiazgo-
wo, bez presji wynikaj cej z szalonego tempa, analizowa wszelkie (dost pne)
aspekty jej realizacji  przypomnijmy: aspekty deterministyczne, a wi c powta-
rzalne. I ten w a nie istotny fakt predestynuje metod empiryczn jako szczególnie
cenn i produktywn w procesie debugowania.
lecz jest to metoda po pierwsze, ma o efektywna, po drugie, zawodna. Znacznie
efektywniej mo na doj sedna problemu, konstruuj c odpowiedni eksperyment i ob-
serwuj c faktyczne zachowanie si aplikacji. Jest to nie tylko efektywne, lecz daje
tak e okazj do zweryfikowania przyj tych za o e dotycz cych oczekiwanego jej
zachowania. Tak oto skutecznym narz dziem w walce z tkwi cymi w oprogramo-
waniu b dami okazuje si & samo oprogramowanie.
W kolejnym punkcie zobaczymy, jak wykorzysta t empiryczn filozofi do utwo-
rzenia strukturalnego modelu walki z b dami w oprogramowaniu.
1.3. Struktura procesu debugowania
Pod wzgl dem strukturalnym w procesie debugowania wyró ni mo na nast pu-
j ce kluczowe elementy:
24 Cz I " Istota problemu
reprodukcj  czyli wypracowanie sposobów na niezawodn i wygodn
powtarzalno poszczególnych aspektów b dnego zachowania aplikacji;
diagnoz  formu owanie i eksperymentalne weryfikowanie hipotez,
zmierzaj ce do ostatecznego ustalenia rzeczywistej przyczyny zaistnia ych
b dów;
napraw  projektuj c i urzeczywistniaj c zmiany w kodzie ród owym
w celu wyeliminowania konkretnego b du, nale y upewni si , e nie
spowoduj one zniwelowania poprawek wprowadzonych wcze niej (a w kon-
sekwencji ponownego zaistnienia b dów ju wyeliminowanych  powszech-
nie okre la si to zjawisko mianem destrukcji regresywnej); wprowadzane
poprawki nie powinny te pogarsza wydajno ci kodu, jego czytelno ci
i atwo ci konserwacji;
refleksj  skuteczne poprawienie b du staje si swoist lekcj , z której
warto zawsze wyci gn stosowne wnioski. Co zrobili my nie tak w tym
fragmencie programu? Czy istniej inne jeszcze fragmenty nosz ce zna-
mi analogicznej pomy ki? Co mo emy zrobi w celu upewnienia si , e
tego b du ju nie powtórzymy?
Jak pokazano na rysunku 1.1, etapy te zasadniczo
Debugowanie jest
uk adaj si w prost sekwencj ; nie powinno to jednak
procesem iteracyjnym.
sugerowa , i powi zane s ze sob na zasadzie wo-
dospadu. Co prawda, trudno przyst powa do formu-
owania hipotez bez uprzedniego zapewnienia rodków do reprodukowania b du na
danie, nie ma te wi kszego sensu poprawianie kodu bez uprzedniego dog bnego
zrozumienia przyczyny wykrytego b du, niemniej jednak mi dzy wymienionymi
czterema etapami istniej silne sprz enia zwrotne powoduj ce, e debugowanie,
zamiast sekwencj etapów, staje si procesem iteracyjnym. I tak np. na etapie formu-
owania hipotez mo emy krytycznie oceni skuteczno metod reprodukowania b -
dów (i skuteczno t poprawi ), za nanoszenie poprawek w kodzie mo e sta si
okazj do zrewidowania przyj tych hipotez.
W nast pnych rozdzia ach zatrzymamy si szczegó owo na ka dym z wymienio-
nych etapów; dalsza cz tego rozdzia u niech natomiast pos u y jako niezb dne
do tego przygotowanie.
1.4. Przede wszystkim rzeczy najwa niejsze
Mimo silnej pokusy, by jak najszybciej  zacz debugowanie , warto jednak za-
stanowi si , czy jeste my do tego nale ycie przygotowani.
Rozdzia 1. " W tym szale stwie jest metoda 25
Rysunek 1.1. Struktura procesu debugowania
Czy naprawd wiesz, czego szukasz?
Zanim przyst pimy do reprodukowania problemu i sta-
wiania hipotez na temat jego przyczyny, powinni my
Co powinno si wydarzy ,
dok adnie zdawa sobie spraw z tego, có w zacho- a co wydarzy o si
waniu aplikacji wydarzy o si takiego, co sk onni jeste- naprawd ?
my uwa a za ów  problem , oraz  co niemniej
wa ne  co powinno si wydarzy , zgodnie z naszymi oczekiwaniami. Je li dys-
ponujemy formalnym raportem na temat b dów, raport ten powinien zawiera
niezb dne informacje w tym zakresie (raportami takimi zajmiemy si dok adniej w roz-
dziale 6.), na przeanalizowanie i zrozumienie których warto po wi ci troch czasu.
Je li nie ma raportu, bo b d sami wykryli my lub dowiedzieli my si o nim z niefor-
malnej rozmowy, tym wa niejsze jest stworzenie adekwatnego obrazu ca ej sytuacji.
Nie zapominajmy jednak, e formalne raporty o b dach bywaj nie mniej myl ce ni
wszelkie inne dokumenty. Je eli mianowicie stwierdzono w raporcie, e  wydarzy o
si to, a powinno si wydarzy tamto , czy zawsze stwierdzenie takie zgodne jest ze
specyfikacj aplikacji? Je eli mamy w tym wzgl dzie w tpliwo ci, nie rozpoczynajmy
konkretnych dzia a przed ich wyja nieniem, przed upewnieniem si , e wszystko
nale ycie zrozumieli my. Nie warto ryzykowa  psucia aplikacji, czyli zmiany
po danego jej zachowania na b dn , tylko dlatego, e tak sugerowa mo e tre
wspomnianego raportu.
26 Cz I " Istota problemu
Walka z niespójnymi danymi
Przysz o mi kiedy zmaga si z do prostym (wydawa oby si ) b dem:
raport transakcji, generowany przez system ewidencji sprzeda y, nie uwzgl d-
nia czasu letniego i okazywa si nieadekwatny do rzeczywisto ci w dniach,
na prze omie których nast powa a zmiana czasu. Szybko wprowadzi em
niezb dn poprawk i zaj em si nast pnym problemem.
Nied ugo potem poinformowano mnie o kolejnym b dzie: wykazana w rapor-
cie liczba transakcji nie zgadza a si z liczb transakcji faktycznie zreali-
zowanych, wskutek czego dzia ksi gowo ci nie móg sporz dzi bilansu.
ród o owej rozbie no ci od razu sta o si dla mnie oczywiste: proces reje-
strowania transakcji nie uwzgl dnia zmiany czasu, w przeciwie stwie do ge-
nerowanego raportu. Po krótkich konsultacjach dowiedzia em si , e opisany
problem da o sobie zna ju rok temu i w a nie dla unikni cia opisanej
rozbie no ci postanowiono istnienie czasu letniego po prostu ignorowa 5.
Tak oto  b dne dzia anie aplikacji, czyli rozbie no jej zachowania z ocze-
kiwaniami, nie by o wcale win aplikacji, a wynika o po prostu z nieadekwat-
no ci wspomnianych oczekiwa . Poniewa raporty sprzeda y generowane
by y w ró nych kontekstach, niektóre powinny uwzgl dnia zmian czasu,
inne raczej celowo j ignorowa . Rzetelnym rozwi zaniem problemu mog oby
by wprowadzenie do programu stosownej opcji rozró niaj cej te dwa
przypadki.
Jeden problem na raz
Poniewa problemy cz sto pojawiaj si w grupach, istnienie pokusa zajmowania si
równolegle wieloma z nich. Pokusa taka okazuje si jeszcze silniejsza, gdy wiele
b dów wydaje si by zwi zanych z tym samym obszarem kodu.
Takim pokusom nale y si zdecydowanie opiera . Debugowanie jest procesem wy-
starczaj co z o onym, by powstrzyma si od dalszej jego komplikacji. Jakkolwiek
nie byliby my ostro ni, zawsze istnieje mo liwo , i eksperyment zmierzaj cy do
wykrycia przyczyny jednego b du interferowa mo e z eksperymentami zaprojekto-
wanymi w celu wykrycia innych. To w du ym stopniu utrudnia mo e rozumienie,
co naprawd dzieje si z aplikacj . Ponadto wprowadzanie do kodu ka dej poprawki
powinno by logicznie uzasadnione, a to staje si znacznie utrudnione, gdy próbujemy
poprawia kilka b dów na raz (wrócimy do tej kwestii w punkcie 4.5).
5
Prawd mówi c, programista dokonuj cy poprawek móg zaoszcz dzi nam fatygi i umie ci w kodzie
komentarz wyja niaj cy przyczyn ignorowania czasu letniego i tym samym upewniaj cy czytelnika
kodu, e jest to dzia anie zamierzone.
Rozdzia 1. " W tym szale stwie jest metoda 27
Czasami mo e si okaza , e to, co sk onni byli my uwa a za pojedynczy b d,
spowodowane jest wieloma przyczynami. U wiadamiamy sobie wówczas, e znale li-
my si w przys owiowej  strefie mroku  z aplikacj dziej si ró ne kuriozalne
rzeczy, niedaj ce si wyja ni w wiarygodny sposób. Obszernie problem ten omówiono
w punkcie 3.4.
Zaczynaj od rzeczy prostych
Wiele b dów programistycznych ma swe ród o w zwyk ym przeoczeniu tych czy
innych rzeczy. Mimo i cz sto przychodzi nam zmaga si z b dami bardziej subtelnej
natury, nie mo na o takich prozaicznych przyczynach zapomina .
Tak si ju sta o, e my, programi ci, przekonani jeste my co do tego, e wszystko
powinni my robi we w asnym zakresie. Przekonanie to cz sto ujawnia si w postaci
syndromu  co nie moje, to niedobre (Not Invented Here), polegaj cego na ponow-
nym wynajdywaniu ko a, czyli (u omnego nieraz) implementowania rzeczy, dla których
gotowe, cz sto perfekcyjne implementacje, dost pne s na wyci gni cie r ki. W odnie-
sieniu do debugowania syndrom ten przyjmuje posta d enia do osobistego wyja-
nienia ka dego aspektu nieoczekiwanego zachowania aplikacji.
A wystarczy po prostu spyta kolegów, czy w przesz o ci zetkn li si z takim, czy
innym problemem. To niewiele kosztuje, a mo e przyczyni si do unikni cia znacz-
nego marnotrawstwa czasu i wysi ku. Szczególnie w sytuacji, gdy nie jeste my eks-
pertami w dziedzinie, któr przysz o si nam zajmowa .
Niespójno tre ci Subversion
(Sean Ellis)
Nie dalej jak kilka dni temu nasz nowy kolega zetkn si z problemem dziw-
nego dzia ania polecenia svn export. Dziwnego, bo mimo identycznych
numerów wersji, posta kodu aplikacji na serwerze Subversion ró ni a si od
kopii roboczej w jego komputerze. Nic, tylko rwa w osy z g owy.
Po bezskutecznych próbach samodzielnego uporania si z problemem kolega
podda si i zapyta mnie, czy widz jakie wyja nienie rozbie no ci, któr on
jest mi w stanie natychmiast zaprezentowa .
Odpowiedzia em twierdz co, wyja niaj c, i przyczyn problemu jest b d
w jednej z bibliotek runtime serwera Apache, manifestuj cy si pod posta-
ci nieprawid owej interpretacji cie ek zawieraj cych sekwencje ../../...
Po ostatecznym upewnieniu si , i to w a nie jest istot problemu, wystar-
czy o nam kilka minut, by zainstalowa nowsz , poprawn wersj biblioteki.
Ostatecznie okaza o si , i b d ten odkryty zosta ju wiele miesi cy
wcze niej, jednak odkrywca widocznie zapomnia podzieli si sw wiedz
z kolegami.
28 Cz I " Istota problemu
Jak wida , komunikacja jest zawsze istotna  nie tylko w kwestiach subtel-
nych, trudnych do pisania zwyk ymi s owami, lecz tak e wówczas, gdy wystar-
czy po prostu zapyta :  Czy widzieli cie ju wcze niej co podobnego? .
W nast pnych rozdziale zajmiemy si pierwszym z etapów iteracyjnego debugowania
 reprodukowaniem b dnego zachowania aplikacji.
1.5. Do dzie a!
Dla przypomnienia...
Upewnij si , e:
d ysz do poznania prawdziwej przyczyny, powoduj cej nieoczekiwane
zachowanie aplikacji,
rzeczywi cie eliminujesz okre lony b d,
nie stwarzasz zagro enia destrukcji  dobrego kodu,
nie pogarszasz jako ci kodu,
b d, który w a nie poprawiasz, nie pozostanie w innym miejscu
kodu,
nie pope nisz w przysz o ci tego samego b du.
Wykorzystuj mo liwo ci oprogramowania w zakresie demonstracji jego
zachowania.
Nie zajmuj si wieloma problemami jednocze nie.
Upewnij si , e doskonale wiesz:
jak powinna zachowywa si aplikacja?
jak zachowuje si faktycznie?
Poszukuj c przyczyn b dów, zaczynaj od rzeczy oczywistych.