Debugowanie zrobi z Ciebie lepszego programistę

Gdybym miał podsumować moją karierę programistyczną w dwóch zdaniach, byłyby one następujące:

- Wszystko, co może pójść źle, pójdzie źle.
- Kod czasem śmierdzi (tak, chodzi o Code Smells)

A jedyną umiejętnością, która jest niezbędna, aby walczyć z tymi gorzkimi realiami, jest debugowanie.

Tak, debugowanie. Nikt (lub prawie nikt!) nie zaczyna programowania z miłością do debugowania. Zamiast tego, jest ono często źródłem frustracji i lęku. Ile godzin stracę na naprawianie tego błędu? - zastanawia się wiele z nas. Wolelibyśmy wrócić do tworzenia fajnych rzeczy. (Bo kto nie lubi budować fajnych rzeczy!?)

Gdzie tkwi problem?

Ciężko jest znaleźć dobrego programistę, który nie uważa debugowania za ważnego elementu programowania. To dlatego, że wiedzą oni, iż jest to dla nich nieocenione źródło rozwoju. Istnieje kilka sytuacji, które sprawdzą twoje umiejętności programisty w zakresie, jakim jest debugowanie.

Prawdziwym problemem jest fakt, że debugowania nie można wcisnąć w z góry zaplanowane ramy czasowe.  Można to zrobić z prawie każdą czynnością w programowaniu - od projektowania do developmentu. Ale debugowanie to zupełnie inna para kaloszy. W trakcie godzinnej, dziennej, albo nawet tygodniowej sesji debugowania, dobre pomysły mogą przychodzić i oddalać się, ale z każdą chwilą będziesz coraz bliżej znalezienia i naprawienia problemu.

Dlatego powinieneś zacząć patrzeć na debugowanie jak na okazję do nauki. Oczywiście, ból nadal będzie obecny :) ale utrzymasz go pod kontrolą, podchodząc do niego we właściwy sposób.

Oto kilka sposobów, które pomogą Ci być lepszym w debugowaniu.

Najpierw zrozum system

Często popełniamy błąd, polegający na złym rozumieniu problemu, a następnie systemu. Powinno być odwrotnie.

Jakiś czas temu debugowałem problem w inteligentnym formularzu SAP. Niektóre wartości nie pojawiały się w nim poprawnie. Debugowałem cały formularz przez dwa pełne dni i nie mogłem znaleźć problemu. Nie muszę chyba dodawać, że byłem naprawdę sfrustrowany. W tym cholernym formularzu nie było nic złego. Wtedy mnie olśniło.

Zauważyłem, że formularz był wywołany jednocześnie z dwóch miejsc w kodzie głównym. Podczas dalszej analizy stwierdziłem, że problem dotyczy kodu wywołującego, a nie samego formularza. Rozwiązałem tę kwestię migiem. Mój dwudniowy wysiłek zakończyłem drobną poprawką, w całkiem innym miejscu.

Co zrobiłem nie tak?

Nie mogłem usunąć problemu, dopóki nie zrozumiałem, jak działa system. Jak tylko to zbadałem, problem stał się oczywisty.

Zawsze pamiętaj, że potrzebujesz konkretnej wiedzy na temat tego, co system ma robić, jak został zaprojektowany i, w niektórych przypadkach, dlaczego został zaprojektowany w taki, a nie inny sposób. Jeśli nie rozumiesz jakiejś części systemu, to prawie zawsze gdzieś tam będzie tkwił Twój problem.

Izoluj problemy, które będziesz rozwiązywać

Nauczyłem się tej ważnej mądrości na własnej skórze.

Jakiś czas temu pracowałem w dużym projekcie migracji danych SAP. Czas wykonania migracji był krytyczny i zbyt wiele bloków kodu działało równolegle. I w tym momencie napotkałem problem z uszkodzeniem danych.

Dotyczyło to tylko części danych. Ogromnie ważną rzeczą było to, aby dowiedzieć się, co poszło nie tak w milionach migrowanych rekordów. Widziałem dokładnie efekty nieprawidłowości, ale nie mogłem zlokalizować źródła problemu.

Wreszcie rozwiązałem problem dzięki prototypowaniu. Stworzyłem mały prototyp, który wykazywał podobne objawy z podzbiorem danych. Praca z nim doprowadziła mnie do głównej przyczyny i ostatecznie problem został rozwiązany.

Rzecz w tym, żeby zawęzić szukanie

Duże systemy są skomplikowane i wiele czynników wpływa na ich działanie. Podczas pracy z całym systemem, trudno jest oddzielić szczegóły, które mają wpływ na konkretny problem od tych, które akurat jego nie dotyczą.

Rozwiązanie? Dziel i rządź. Nie próbuj jednocześnie pracować z całym systemem. Oddziel komponent lub moduł, z którym masz problemy od reszty kodu, aby uzyskać pole do konkretnego debugowania.

Wyizolowanie problemu ma wiele zalet. Jesteś w stanie skupić się bezpośrednio na elementach, które są istotne dla problemu. Szybko “wgryziesz się” w problem, ponieważ pracujesz z małą ilością kodu.

Błąd nie zaszyje się na długo, jeśli jego “kryjówka” jest malutka.

Zmieniaj jedną rzecz na raz

Używaj karabinu, a nie strzelby. Pozwól, że Ci wyjaśnię.

Wyobraź sobie, że musisz usunąć ząb i odwiedzasz dentystę. Dentysta "próbuje" znaleźć problem i zaczyna majstrować przy wszystkich zębach. Jęczysz na próżno, gdy jeden po drugim zębie znoszą atak wiertła.

Jak się poczujesz? Co się do cholery dzieje. Czy ten gość zna się na swojej pracy?!

Złe debugowanie działa dokładnie tak samo. Zmieniaj jedną rzecz na raz. Będziesz o wiele lepszy w naprawianiu błędów. Dowiedziałem się, że programiści próbują naprawić zły kod, po prostu zamieniając lub majstrując z innymi komponentami. Mogą zmienić trzy lub cztery rzeczy i odkryć, że nagle całość zadziałała. To fajnie, ale nie mają pojęcia, która część była zła. Co gorsza, całe to hakowanie może zaburzyć inne procesy, które początkowo były w porządku.

W wielu przypadkach będziesz chciał zmienić różne części systemu, aby sprawdzić, czy mają one wpływ na Twój problem. Zwykle jest to ostrzeżenie, że zgadujesz, a nie znasz kod na tyle, żeby wiedzieć, co się dzieje. Zmieniasz całe otoczenie, zamiast szukać pojedynczego błędu, tak jak powinieneś to zrobić.

To może ukryć pierwszy problem i spowodować ich więcej. Jest to pułapka, której deweloperzy powinni unikać. Zawsze pamiętaj, że możesz dokładnie określić, który parametr miał na coś wpływ, jeśli dokonasz jednej zmiany na raz. Jeśli nic nie zmieniła, od razu ją wycofaj!

Sprawdź, czy to naprawdę Twoja poprawka rozwiązała problem

Złota zasada debugowania jest taka, że jeśli Ty nie naprawiłeś problemu, to nie jest on naprawiony.

Każdy chce wierzyć, że błąd po prostu zniknął. “Nie widzę, żeby nadal sprawiał problemy”. “To zdarzyło się kilka razy, ale czekaj, wtedy coś się stało i przestało się psuć." I oczywiście logiczny wniosek brzmi: "Może to się więcej nie powtórzy.,." Zgadnij - powtórzy się.

Przepraszam, jeśli Cię rozczarowuję, ale w prawdziwym świecie nie ma magicznych różdżek.

Kiedy myślisz, że naprawiłeś błąd, usuń poprawkę. Upewnij się, że znowu się zepsuło. Przywróć poprawkę. Upewnij się, że została ponownie naprawiona. Dopóki tego nie zrobisz, nie będziesz pewny, że naprawiłeś dokładnie to, co chciałeś, tak jak chciałeś.

Poprawki często zachowują się w zabawny sposób. Czasami po prostu "ukrywają się", a nie naprawiają problem. A zanim zdamy sobie sprawę, że poprawka nie ma nic wspólnego z problemem, który został rozwiązany, produkt zostaje wysłany do klienta, który oczywiście nie będzie zadowolony. Nie wpadnij w tę pułapkę.

I wreszcie - zachowaj dziennik rozwiązań

To może wydawać się banalne. Jest to jednak bardzo ważne narzędzie do rozwiązywania problemów, które często jest pomijane. Problemy pojawiają się i powracają w życiu, w pracy, a nawet w związkach odwiecznie na tych samych płaszczyznach. I nie ma tu sensu ponowne odkrywanie koła.

Ciężko jest przewidzieć, jakiego rodzaju informacji będą Ci potrzebne, z tych przechowywanych w dzienniku rozwiązań, biorąc pod uwagę różne wymagania. Można jednak rozważyć następujące elementy:

- Problem
- Inicjator (osoba, która zgłosiła problem)
- Kontakt do inicjatora
- Czas otwarcia
- Krótki opis
- Znaczenie problemu
- Typ błędu
- Właściciel (systemu)
- Obecny status problemu
- Kolejny krok (z datą)
- Data ukończenia
- Rozwiązanie, link do PR lub do żądania wsparcia dostawcy

Nie rób dwa razy tej samej roboty. Aby być bardziej produktywnym, prowadź dziennik napotykanych problemów i wykorzystuj znalezione już rozwiązania. Kiedy pojawia się problem, zamiast mówić: “Hej, widziałem to już wcześniej. Ale nie mam pojęcia, jak to naprawiłem”, możesz szybko sprawdzić rozwiązanie, z którego korzystałeś w przeszłości. Nie muszę chyba dodawać, że to nie tylko oszczędza czas, ale też niesamowicie zwiększa poczucie własnej wartości i pewność siebie.

Pamiętaj, że debugowanie jest okazją do nauki. Jasne, czasami zdasz sobie sprawę, że popełniłeś głupi błąd, którego nie powinieneś był robić. Ale ten proces jest równie ważny, aby stać się lepszym programistą, jak i nauczenie się fajnego udoskonalenia jakiegoś języka.

Jak powiedział Richard Pattis:

Podczas debugowania nowicjusze wprowadzają kod korekcyjny; eksperci usuwają wadliwy kod.