Uopšteno o debagovanju

[Dragi]

Šta je debugging (debagovanje)?

Otklanjanje grešaka iz programskog koda se među programerima uobičajno naziva debagovanje (engl. debugging). Doslovni prevod engleskog termina na srpski jezik bi mogao da bude dezinsekcija ili uklanjanje buba, ali su ipak uobičajeni termini otklanjanje grešaka i debagovanje.

Kao i svaki drugi složen posao, debagovanje je mnogo lakše ako mu se pristupi sistematično. Iako ponekad može da se stekne utisak da je neko ,,pravi talenat", a neko ,,potpuni antitalenat" za debagovanje, te da sam proces debagovanja u velikoj meri zavisi od intuicije i osećaja, stvari ipak stoje malo drugačije. Tačno je da lične sposobnosti mogu imati nezanemarljiv uticaj na kvalitet i efikasnost debagovanja, ali je značaj sistematičnog pristupa i obučenosti razvijalaca ipak daleko veći.

Osobe kojima debagovanje ide od ruke su obično one koje su (svesno ili nesvesno) usvojile i primenjuju osnovna pravila debagovanja.

Najvažnije aktivnosti u okviru debagovanja su:

• uočavanje da propust postoji;
• analiziranje i razumevanje propusta;
• lociranje propusta i
• ispravljanje propusta

Osnovno sredstvo za rad su znanje o rešavanom problemu i napisanom programskom kodu i intuicija. Opis postupka čine samo dva koraka:

• Pokušati sa sasvim jednostavnom popravkom.
• Sve dok program ne proradi, ponavljati korak 1.

Kada nam je trebalo mnogo vremena da pronađemo neku grešku, to je bilo zato što smo zanemarili neko od osovnih pravila debagovanja – jednom kada smo ga primenili, brzo smo pronašli problem.

Pravila debagovanja su veoma jednostavno i razumljivo formulisana:

• Razumeti sistem
• Navesti sistem na grešku
• Najpre posmatrati pa tek onda razmišljati
• Podeli pa vladaj
• Praviti samo jednu po jednu izmenu
• Praviti i čuvati tragove izvršavanja
• Proveravati naizgled trivijalne stvari
• Zatražiti tuđe mišljenje
• Ako je nismo ispravili, onda greška nije ispravljena

Pravilo 1 - Razumeti sistem
Neophodna pretpostavka za dobro razumevanje računarskog sistema je dovoljno široko i temeljno poznavanje teorijskih i praktičnih osnova računarstva. Iskustvo pokazuje da u ovom kontekstu ,,dovoljno" nikada nije dovoljno.
Dokumentacija služi da se čita i to je potrebno raditi što je ranije moguće. Ako smo iz bilo kog razloga propustili čitanje dokumentacije već pri započinjanju pisanja softvera, onda se njome moramo pozabaviti već na početku debagovanja.

Pravilo 2 – Navesti sistem na grešku
Da bi neki problem mogao da se reši, najpre je potrebno da bude pažljivo posmatran i analiziran. Omogućavanje posmatranja problema je jedan od najvažnijih razloga za ponavljanje greške, ali ne i jedini. Tek kada poznajemo mehanizam za ponavljanje greške, možemo da razmatramo i različite potencjalne uzroke i da pristupimo postepenoj lokalizaciji problema.

Kada god mora da se eksperimentiše, neophodno je da dokumentujemo sve pokušaje i ishode (takođe i detaljan opis), zato što u suprotnom vrlo lako može da se dogodi da se isti pokušaji ponavljaju po više puta i dragoceno radno vreme troši uzalud.
Ako se problem pojavljuje jedanput u 1000 izvršavanja, možemo da smatramo da smo ga otklonili sa određenom verovatnoćom, ako se ne pojavi nijedanput u npr. 50.000 izvršavanja. Takv metod proveravanja nije savršen, ali je često prihvatljiv.

Pravilo 3 – Najpre posmatrati pa tek onda razmišljati
Videli smo da je problem potrebno ponoviti da bismo ga mogli posmatrati. Posmatranje je neophodno radi prikupljanja što veće količine informacija o ispoljavanju problema i uslovima njegovog ispoljavanja. Informacije su nam neophodne zato što samo uz dovoljno informacija možemo razmišljanjem da dođemo do dobrog zaključka. Razmišljanje kome bismo pristupili bez relevantnih informacija nam ne bi bilo od velike pomoći, već bi moglo da nas zatrpa neispravnim ili beskorisnim zaključcima. Pravilo ,,najpre posmatrati pa tek onda razmišljati" ima za cilj da nam uštedi vreme na razmatranju i implementiranju pogrešnih zaklučaka

Pravilo 4 – Podeli pa vladaj
Osnovna ideja pravila ,,podeli pa vladaj" je da se postepenim aproksimacijama sužava oblast traženja greške. Najpre se postavljaju hipoteze o lokaciji greške (naravno, u skladu sa pravilom 3). Takve hipoteze ne bi trebalo da pokušavaju da sasvim precizno lociraju grešku, već da podele posmatranu oblast na dve podoblasti približnih veličina. Zatim se testovima ustanovljava tačnost ili netačnost hipoteze i u skladu sa rezultatima testiranja se sužava oblast posmatranja. Ponavljanjem ovih koraka se oblast postepeno sve više sužava, da bi se, u idealnom slučaju, došlo do sasvim precizno lociranog uzroka greške.

Pravilo 5 – Praviti samo jednu po jednu izmenu
Svaki put kada menjamo postojeći kod, moramo da imamo u vidu da naknadne izmene predstavljaju plodnije okruženje za nastajanje grešaka nego što je to slučaj sa pisanjem sasvim novog koda. Razlika je u tome što kada pišemo novi kod, onda obično imamo široku sliku o tome šta se zbog čega piše i zašto se nešto piše na konkretan izabran način, dok pri menjanju postojećeg koda postoji povećana opasnost da neki deo konteksta, u kome se nalazi ili funkcioniše programski kod koji se menja, nije u potpunosti shvaćen ili čak uopšte nije ni uzet u razmatranje.

Zbog "zaletanja" pri debagovanju potrebno da budemo uzdržani. Pre svake izmene je neophodno da dobro razmislimo:

• Da li je ta izmena neophodna?
• Da li ona sigurno rešava problem?
• Da li postoji alternativa?

Pravilo 6 – Praviti i čuvati tragove izvršavanja
Tragovi izvršavanja (engl. trace) su jedan od najvažnijih unutrašnjih alata za rešavanje problema. Oni su nezamenljivo sredstvo za obezbeđivanje informacija o toku izvršavanja u prostornoj i vremenskoj okolini greške. tragovi izvršavanja su posebno korisni u slučajevima kada je neophodno da se izvršavanje ponovi veliki broj puta da bi se greška ispoljila, ali i u slučajevima kada je praćenje sistema otežano iz bilo kojih razloga. Na primer, interaktivno praćenje izvršavanja distribuiranih sistema je veoma teško, pa se u distribuiranim okuženjima problemi po pravilu rešavaju uz pravljenje detaljnih tragova izvršavanja.

Pri pravljenju manuelnih tragova potrebno je da se zapisuju:

• detaljan opis stanja koje prethodi nizu aktivnosti
• tačan redosled preduzetih aktivnosti;
• način izvođenja svih aktivnosti, detaljno;
• sve uočene posedice preduzetih aktivnosti.

Pravilo 7 – Proveravati naizgled trivijalne stvari
Uzroci i rešenja problema su često sasvim jednostavni, ali je to često veoma teško da se ustanovi. Da bi se razumelo o kom nivou jednostavnosti se ovde radi, možda je najbolje da navedemo nekoliko trivijalnih primera:

• Ako se pita nije ispekla, da li je rerna uopšte bila uključena?
• Ako automobil ne može da se pokrene, pre nego što ga rastavimo, možda bi bilo dobro da proverimo da li ima goriva?

Da, ovi primeri zaista izgledaju kao da je u pitanju neka šala – ali nije. Čitaocima koji nemaju značajnija iskustva u debagovanju, možda je teško da poveruju da takve greške u programiranju uopšte postoje. Onima koji takva iskustva imaju, verovatno ih je izlišno predočavati. Zajedničko za obe populacije je da se pri analiziranju i rešavanju nekog problema veoma često zanemaruju potencijalno jednostavni uzroci i rešenja.

Pravilo 8 – Zatražiti tuđe mišljenje
U razvoju softvera, kao ni drugde uostalom, ne bi trebalo da bude egoizma, sujete ili ponosa. Ali ih, kao i drugde, ima i mogu da sprečavaju programera da zatraži savet od saradnika, prijatelja ili nekog nepoznatog eksperta. Argumentacija obično liči na pravdanja poput: ,,Ovo je moj deo softvera. Ja sam ga pisao i samo ja znam šta se tu dešava. Niko osim mene ne može da reši ovaj problem." Ali, trebalo bi da se vratimo korak nazad: ,,Da, ovo jeste moj deo softvera i niko drugi ga nije pisao osim mene. Ako problem postoji, onda sam ga ja napravio." A greške izvesno postoje, zato što se inače tim delom softvera ne bismo ni bavili u procesu debagovanja. Zašto bismo verovali da onaj ko je napravio grešku jeste pozvaniji i sposobniji da je otkloni nego neko drugi?

Pravilo 9 – Ako je nismo ispravili, onda greška nije ispravljena
Moglo bi se reći da je ovo pravilo toliko jasno da je nepotrebno, no to ovde nije slučaj. Izvesno ga nije ga teško razumeti. Osnovno značenje je sasvim jasno. Ipak, ovo pravilo ima nešto šire implikacije, koje u složenim okolnostima razvoja softvera ne smeju ni da se zanemare ni da se podrazumevaju.

Jedan od razloga da ne zanemarimo ovo pravilo je što praksa potvrđuje (a i čuveni Marfijev zakon nas uverava) da će problem koji nije rešen, a koji je naprasno prestao da se ispoljava, sasvim verovatno isto tako naprasno ponovo da se ispolji onda kada nam to bude najmanje odgovaralo. Ako je problem ,,nestao" sam od sebe, to bi trebalo da nam sugeriše da zapravo nismo dvoljno dobro upoznali okolnosti u kojima se problem pojavljuje. Promena tih nepoznatih okolnosti je uticala na ispoljavanje greške. Ako se okolnosti ponovo promene, problem može ponovo da počne da se ispoljava.

Prost primer debagovanja za SA:MP:

Funkcija za izračunavanje faktorijela

stock factorial(n)
{
    print("Funkcija uspesno ucitana: factorial(n)");
    printf("Ulazna vrednost: %d", n);
	
    // Greska
    if (n < 0)
    {
	printf("Greka: Faktorijel nije definisan za negativne brojeve. (Ulaz: %d)", n);
        return -1;
    }
    // Base case: faktorijel od 0 je 1
    else if (n == 0)
    {
        return 1;
    }
    // Recursive case: n! = n * (n - 1)!
    else
    {
        return n * factorial(n - 1);
    }
}

Beskonačna petlja jer var nikad nece biti 3:

new var = 5; // Create a variable and set it to 5
while(var != 3) // If it's not 3
{
    var++; // Add one to it
}

Kao što vidite, PAWN nije baš napredan jezik što se tiče toga. Morate ručno pisati print-printf gde god ste logički ustanovili da je potrebno kako biste videli da li se program izvršava i dokle je stigao, naravno prateći prethodna uputstva. Ne možete stavljati printeve gde god vam se ćejfne.

Za sada, to bi bilo to što se debagovanja tiče. Nadam se da će nekome biti od koristi i da ćete pristupiti debagovanju na pravi i profesionalni način, pa tek onda se obratiti nama na forumu.


Potrudio sam se da izvučem i adaptiram najbitnije delove iz knjige i wikipedije kako biste barem temelj neki izgradili. Verujem da većina skriptera nije upoznata sa ovim znanjem, a početnicima zlata vredi. Srdačan pozdrav od Dragija! Ostavite lajk jedan.

Autor teme: Dragan Avdić (Dragi)

Literatura:

• Saša Malkov : Odlomak iz knjige Razvoj softvera
• https://sampwiki.blast.hk/wiki/Debugging