3784494523

mały, że powoduje tylko zły wynik, wtedy może być trudno określić czy do programu wkradł się robak.

Wyizolowanie źródła problemu

Jest to często najtrudniejszy krok podczas debuggowania. Jego celem jest zidentyfikowanie, która część programu powoduje błąd. Krok ten często wymaga iteracyjnego testowania. Dla programów podzielonych na moduły krok ten może być łatwiejszy dzięki sprawdzeniu poprawności danych przesyłanych pomiędzy interfejsami poszczególnych modułów. Jeżeli dane wejściowe były poprawne, a wyjściowe niepoprawne, to zlokalizowaliśmy moduł z błędem. Poprzez iteracyjne testowanie wejścia i wyjścia programista może zidentyfikować do kilku linii kodu miejsce wystąpienia błędu.

Zidentyfikowanie przyczyny błędu

Kiedy już znaleźliśmy miejsce wystąpienia błędu, kolejnym krokiem jest ustalenie przyczyny tego błędu. Dobra znajomość programu może okazać się tu niezbędna. Wyszkolony debugger może, co prawda, znaleźć miejsce wystąpienia błędu, ale już tylko osoba dobrze znająca program może precyzyjnie określić przyczynę błędu. Kiedy już znamy przyczynę błędu, dobrym pomysłem może być przejrzenie podobnych sekcji kodu celem sprawdzenia, czy ten sam błąd nie został powielony w innych miejscach.

Określenie sposobu naprawy

Następnym krokiem powinno być określenie sposobu naprawy błędu. Dokładna znajomość programu jest tu niezbędna dla wszystkich (może poza tymi najbardziej banalnymi) rodzajów błędów. Jest to spowodowane tym, że naprawa zmienia aktualne zachowanie programu i może skutkować nieoczekiwanymi rezultatami. Co więcej, naprawa pojedynczego błędu może spowodować powstanie nowych błędów lub ujawnienie się innych błędów istniejących w programie.

W niektórych przypadkach naprawa może być prosta i oczywista. Jest to dosyć proste podczas błędów natury logicznej, kiedy oryginalny projekt został nieprawidłowo zrozumiany i zaimplementowany. Z drugiej jednak strony, jeżeli jednak problem ujawnia jakiś bardziej złożoną wadę projektową, wtedy problem może być nie tylko trudny, ale nawet niemożliwy do naprawy. Może to czasem prowadzić do konieczności przepisania całego programu od nowa.

Czasem warto także zastosować szybką naprawę, która będzie poprzedzała dokładną naprawę w przyszłości. Decyzja taka powinna być podjęta