Nema čovjek na prostorima bivše, komunističke Jugoslavije, a da tu i tamo ne koristi riječ bauk. No, znamo li šta je taj bauk doista?

Prema rječnicima odnosi se na drevno strašilo. Napredna verzija bauka, mnogo opasnija, posebno za neposlušnu, nečastivu djecu je Babaroga, koja je jela svu tu djecu, kako su ih stariji plašili.

Savremeni svijet još od prvog savremenog računa pogonjenog COBOL programskim jezikom nekako se gotovo odrekao i bauka i babaroge, pa nam je sve postalo bag (bug – eng. buba). Buba, doslovno moljac, koju je pronašao Admiral Dr Grejs Hoper (Grace Murray Hopper) ušla je u zapisnik (doslovno, zalijepljena u knjigu) kao razlog zašto mašina nije radila, a posljedično razvojem informatičkih uređaja u svakodnevni život.

Otklanjanje grešaka (Debugging)

Ako bismo se vodili logikom iz pamtivijeka uvidjeli bismo da se otklanjanje straha od bauka i babaroge događa odrastanjem. Međutim, u savremenom računarskom svijetu, ma koliko čovjek da je odrastao greške (bugs) ne mogu da se odstrane kao ni strah (panika, paranoja, fobija) koje one izazivaju.

Bolna je to stvar. Pogledati vlastitu nevolju i znati da je to čovjek postigao sam, niko drugi.

Sofokle

Bauci i Babaroge ne jedu naš kôd, greške, baje (bugs) još su tu. Doduše, ne lete kao nekada, ali stvaraju velike probleme i prije da će tačniji sinonim za grešku biti bauk ili Babaroga nego li baja/buba/bug.

Računarski sistemi rade upravo ono što im se kaže, a ne ono što bi mi željeli da rade. Zbog toga i sama svjesnost da se napravio propust izaziva strah, strah od Bauka ili Babaroge zvane bug.

Psihologija otklanjanja grešaka

Priznanje da kôd koji se napisao ima grešku za mnoge programere je veoma teško. Umjesto traženja opravdanja, poricanja ili šta već, na grešku treba gledati kao na izazov koji se treba riješiti. Rješenjem se stiču nova iskustva i nova saznanja, zar ne?

Međutim, slična je stvar i kod pronalaska greške u tuđem kôdu. Tada, iz niskih ljudskih poriva, likujemo nad nesposobnošću kolegice ili kolege koji su napisali kôd. I umjesto što se troši vrijeme na gunđanje i svaljivanje krivice, ponovo treba gledati na pronađenu grešku kao na izazov.

– Joj ko ti je ovo radio? Šta je ovo ovako?
– Pa vi majstore, kad ste bili prošli put!

Ustvari, ne bitno je ko je grešku izazvao (neko drugi ili lični rad), taj problem se mora riješiti. I neće ga niko riješiti s ulice, druge firme, drugog tima do onaj ko je zadužen za taj dio kôda. Pa je zato bolje, umjesto negodovanja, prioniti na otklanjanje greške.

Otklanjanje grešaka ima i neka pravila, prvo od njih je: Nema mjesta panici!

Panika, posebno ako je potpomognuta od strane nadređenih ili klijenata može da zaslijepi tražioca greške. Zbog toga je važno smireno pogledati cjelokupnu sliku. Jer, možda nije greška samo na malom dijelu koji trenuto pravi problem, nego je potrebno napraviti veću izmjenu ili čak refactoring.

Odakle početi

Kada je otklanjanje grešaka u pitanju, uvijek se postavlja pitanje odakle je ispravno početi? Nema smisla pokušavati u kôdu pronaći mjesta gdje se greška pojavljuje slučajno. To je trošenje vremena i svih drugih resursa, uz svakako podizanje nivoa frustracija.

Zbog toga se uvijek savjetuje da se ima precizan slijed, korak po korak, kako je do greške došlo. To može dolaziti od krajnjeg klijenta ili pak od kolege programera. Ako se nije u stanju pronaći, reproduktovati greška na vlastitom okruženju slijedeći korake, onda ili koraci nisu dobro napisani, ili se nemaju isti parametri okruženja, pa je stoga potrebno kako kontaktirati onoga ko je pronašao grešku i provjeriti svaki mogući korak, tako i uspostaviti radno okruženje identično onome na kome je greška pronađena.

Da bi se bilo sigurno da je greška doista i pronađena, ali i otklonjena, dobro je slijediti principe testiranja koda. Napisati test koji će potvrditi pronađenu grešku, a zatim otkloniti grešku kako bi test pozelenio, je jedna voma dobra i korisna praksa.

Nekada problem nije u samom kôdu (odnosno kôd ne pokriva sve moguće scenarije podataka, ali suštinski nema problema u kôdu), nego u podacima koje kôd treba da obrađuje. To svakako zavisi od vrste programa i aplikacije na kojoj se radi.

Kako god, ako se bude u toj situaciji, potrebno je poslužiti se logičko-matematičkim vještinama. Prvo se set podataka podijeli na pola (ako se ne zna tačno koji podatak pravi problem), a zatim proba jedna od polovina da se utvrdi u kojoj se nalazi greška. U slijedećem koraku, ponovo se dijeli na pola i provjerava u kojoj polovici se nalazi greška. Čak i za ogroman set podataka, ovim se relativno brzo može pronaći set podataka u kojima se nalazi ono što izaziva grešku u programu.

Evidentiranje i praćenje (Logging and Tracing)

Ako se piše kôd tako da ispisuje mnogo različitih poruka o koracima koji se obavljaju unutar programa, to je mnogo lakše pratiti nit i putanju te uvidjeti gdje bi mogao biti potencijalni problem. Neki programski jezici su tako dobri da u svojim dnevnicima pucanja ispisuju i tačnu liniju kôda u kojoj se problem dogodio. Međutim, to nužno ne znači da je problem baš tu!

U svakom slučaju, voditi računa o jednolikom uobličavanju (formatiranju) poruka evidencije (logs) i njihovo čuvanje u posebnim (specijaliziranim) alatima za nadgledanje (monitoring) u mnogome će olakšati pronalaženje (detektovanje) gdje bi i zašto mogao biti (ili jeste) problem.

Ako infrastruktura na kojoj se razvija i pokreće program dozvoljava korištenje obavijesti za posebne događaje (events managers), to je moguće imati posebne kanale ili alate samo za posebne slučajeve. Na primjer, u slučaju devijacije (exception) program će uz pomoć Event manager-a slati direktnu poruku putem e-maila ili nekog drugog komunikacionog alata direktno timu zaduženom za taj dio kôda ili programa.

Također, nimalo nebitna stvar je i pomoć kolege. Kolega iz tima ili neko s kim se sarađuje može biti od izuzetne pomoći i važnosti kod pronalaženja greške u programu jer “stvar gleda drugim očima”.

Procesi eliminacije

Ako vidimo tragove u zemlji od konja, sigurno je da nećemo pomisliti na vuka. Isto je i s porukama koje dobijamo prilikom traženja gdje bi mogao biti problem. Nema potrebe okrivljivati Operativni sistem, neku vanjsku biblioteku koja se koristi ili nešto slično. Valja uvidjeti zašto i kako se dobija to što se dobija u kôdu za koji smo odgovorni.

Čak i da se greška pojavila nakon što se ažurirala verzija neke vanjske biblioteke, opet nije problem u samoj biblioteci nego u kôdu za koji se odgovorno i koji koristi tu vanjsku biblioteku. Kôd za koji se odgovorno mora biti provjeren, testiran i verifikovan da radi prije nego se pošalje u produkciju.

Zato, ako se ima povjerenje u vlastiti kôd: Ne sumnjati ni ušta vanjsko, nego (p)dokazati da to u šta se ima povjerenje doista radi.

Razgovori

Kod otklanjanja grešaka razgovori mogu biti veoma bolni, jer su emotivni i utiču na ego svakog pojedinog programera. Međutim, razgovori mogu, ali i moraju biti i nakon što se problem uspješno otkloni. Na tim razgovorima cijeli tim mora da shvati zašto je došlo do greške, šta se uradilo da se greška otkloni i ono veoma važno, šta se uradilo i želi uraditi u budućnosti kako se iste i slične greške ne bi ponovile. Da li je potrebno dodati neke nove poruke o evidencijama (logs) ili neke okidače na posebne događaje (events) ili pak voditi računa da se verzije vanjskih biblioteka ne ažuriraju same/automatski?

Programski kôd je nekada leglo larvi koje samo čekaju da se izlegu u manje ili veće baje (bauke i Babaroge) koje mogu da nanesu nemjerljive štete.

7

Hits: 59