Joel on Software   Joel o programowaniu

Inne artykuły serwisu "Joel on Software" po polsku

Inne artykuły serwisu "Joel on Software" po angielsku

Napisz do autora (tylko po angielsku)

Język BASIC Level-I komputera TRS-80 pozwalał na jednoczesne przechowywanie jedynie dwóch zmiennych znakowych - A$ i B$. Podobnie ja urodziłem się z dwoma miejscami do przechowywania błędów w głowie. W danej chwili mogę pamiętać tylko o dwóch. Jak mi ktoś każe zapamiętać trzy, jeden z nich ląduje na podłodze i zostaje zamieciony pod dywan.

Utrzymywanie bazy błędów jest jedną z podstawowych zasad dobrego zespołu programistycznego. Nigdy nie przestaje mnie zadziwiać jak niewiele zespołów faktycznie to robi. Chyba najbardziej błędnym przekonaniem wśród programistów jest to, że mogą spamiętać wszystkie błędy lub zapisać je na żółtych karteczkach poprzylepianych do monitora.

Poświęć mi chwilę swojej uwagi, a postaram się przedstawić dość prostą i bezbolesną, według mnie, metodę śledzenia błędów, w duchu moich poprzednich artykułów o bezbolesnych harmonogramach i bezbolesnym tworzeniu specyfikacji.

Po pierwsze więc, potrzebna jest prawdziwa baza danych. W dwuosobowych zespołach, tworzących po pięć linijek kodu w czasie długiego weekendu, pewnie wystarczy plik tekstowy zamiast bazy. Jeżeli jednak ma to być coś większego, to będziesz potrzebować prawdziwej bazy danych do śledzenia błędów. Są setki tego typu systemów dostępnych na rynku. (Bezwstydna autoreklama: system, który stworzyliśmy w Fog Creek, FogBUGZ, działa w oparciu o przeglądarkę WWW, jest dość łatwy w użyciu, a zarazem ma duże możliwości.)

Dla celów ilustracji, prześledzimy życie jednego błędu od momentu jego narodzin, do chwili kiedy ktoś litościwie zakończył jego męki. Zrobimy to na przykładdzie słynnego Błędu 1203. Oto co o tym błędzie mówi baza błędów:

Oto co się stało.

Mikey Programista pracuje nad nowym zintegrowanym klientem FTP dla swojego oprogramowania na Macintosha. W pewnym momencie, w przypływie kreatywności, tworzy swoją własną funkcję string-copy. To nauczy tych pierońskich specjalistów od reusability! Buahaha!

Złe rzeczy się dzeją, Mikey, jeżeli nie wykorzysujesz gotowego kodu. I dzisiaj właśnie stała się zła rzecz, kiedy Mikey zapomniał zakończyć nullem kopiowany string. Ale nigdy nie zauważył błędu, bo akurat zawsze kopiował stringi do "wyzerowanej" pamięci.

Poźniej w tym samym tygodniu Jill Bardzo, Bardzo Dobry Tester torturuje właśnie kod tłukąc głową w klawiaturę, albo stosując inną, podobnie okrutną, metodę testowania.  (Tak na marginesie, to wszyscy dobrzy testerzy mają na imię Jill, lub jakoś podobnie, np. Gillian.) Nagle dzieje się coś bardzo dziwnego: demon ftp, na którym przeprowadzała testy, padł. Tak, wiem że to jest Linuksowa maszyna, a maszyny Linuksowe nigdy nie padają, (bez prychania panowie i panie z slashdot, proszę) ale ta cholerna rzecz właśnie padła. A ona nawet nie dotykała serwera. Przesyłała tylko FTPem pliki wykorzystując kod Mikiego.

Ponieważ Jill jest bardzo, bardzo dobrym testerem, ma dokładny zapis wszystkich czynności które wykonała (na przykład dokładny kąt nachylenia głowy, w momencie uderzenia w klawiaturę, jest w jej notesie). Restartuje więc wszystko, powtarza wszystkie kroki i -- nie do wiary -- sytuacja się powtarza! Linuksowy demon ftp znowu padł! To już drugi raz w ciągu jednego dnia! Co ty na to, Linus?

Lista kroków koniecznych do powtórzenia błędu ma jakieś 20 pozycji. Niektóre z nich wydają się Jill niezwiązane z problemem. Po paru próbach udaje się jej zawęzić problem do czterech kroków, które zawsze powodują ten sam efekt. Teraz już może zgłosić błąd.

Jill wprowadza znaleziony błąd do systemu. Ale samo wprowadzanie błędu do bazy wymaga pewnej samodyscypliny: są dobre i złe zgłoszenia.

Trzy kroki do Dobrego Zgłoszenia Błędu

I Pan powiedział: "Wpierw wyjąć musisz świętą zawleczkę. Potem masz zliczyć do trzech, nie mniej, nie więcej. Trzy ma być liczbą do której liczyć masz i liczbą tą ma być trzy. Do czterech nie wolno ci liczyć, ani do dwóch, masz tylko policzyć do trzech. Pięć jest wykluczone. Gdy liczba trzy jako trzecia w kolejności osiągnięta zostanie, wówczas rzucić masz święty Granat Ręczny z Antiochii w kierunku wroga, co naigrawał się z ciebie w polu widzenia mego, a on kity odwali".

-- Monty Python i Święty Graal

Zapamiętać zasady dobrego zgłaszania błędów jest bardzo łatwo. Każde takie dobre zgłoszenie musi zawierać dokładnie trzy elementy.

Proste, nie? Wygląda na to, że nie. Jako programiście, niejednokrotnie już ludzie przydzielali mi błędy, w których opisie brakowało jednego z wymienionych elementów.

Jeżeli np. nie powiesz mi jak powtórzyć błąd, wtedy prawdopodobnie nie będę miał pojęcia o czym mówisz. "Program się wywalił i pozostawił śmierdzące coś na biurku." Super, skarbie. Ale nic na to nie poradzę, jeżeli nie powiesz mi co dokładnie zrobiłeś. No dobra, przyznaje, że są dwa przypadki, kiedy trudno jest podać dokładne kroki konieczne do powtórzenia błędu. Czasami po prostu nie pamiętasz, albo tylko wprowadzasz błąd "z terenu". Inny przypadek, kiedy można nie podać kroków, to gdy błąd pojawia się czasami ale nie za każdym razem. Ale w takim przypadku także powinno się je podać tyle tylko, że z krótką adnotacją informującą, że błąd nie pojawia się zbyt często. W takich przypadkach może jednak być bardzo trudno znaleźć błąd, ale spróbować można.

Jeżeli nie podasz jaki był spodziewany efekt, mogę nie zrozumieć dlaczego to jest błąd. Na oknie startowym widać krew. No i co z tego? Zraniłem się w palec, kiedy to kodowałem. A czego się spodziwałeś? Aha, twierdzisz, że specyfikacja wymaga, aby na oknie startowym nie było krwi! No, to teraz rozumiem dlaczego uważasz, że to jest błąd.

Krok trzeci. Jaki był rzeczywisty efekt. Jeżeli nie powiesz mi tego, to nie będę wiedział na czym polega błąd. To jest raczej oczywiste.

Ciąg Dalszy Naszej Historii

No dobra. Jill wprowadza błąd. W dobrym systemie śledzenia błędów błąd ten jest automatycznie przypisywany do głównego developera projektu. I tu druga ważna rzecz: każdy błąd musi być przez cały czas, aż do momentu kiedy zostanie zamknięty, przypisany dokładnie do jednej osoby. Błąd jest jak gorący ziemniak: jak jest przypisany do ciebie, to jesteś odpowiedzialny za rozwiązanie go (w jakiś sposób), albo do przypisania go do kogoś innego.

Willie, główny developer, patrzy na błąd, stwierdza, że prawdopodobnie coś jest nie tak z serwerem ftp i oznacza błąd jako "won't fix" (nie do poprawienia). W końcu to nie oni napisali serwer ftp.

Kiedy błąd jest rozwiązany, zostaje przypisany z powrotem do osoby, która go wprowadziła. I to jest bardzo ważna rzecz. Błąd nie znika tylko dlatego, bo programista uważa, że powinien. Główna zasada jest taka, że tylko osoba, która wprowadziła błąd, może go zamknąć. Programista może rozwiązać błąd, czyli powiedzieć "hej, wydaje mi się, że to jest gotowe". Ale aby błąd mógł faktycznie zostać zamknięty, ta sama osoba, która błąd wprowadziła, musi potwierdzić, że został faktycznie poprawiony lub zgodzić się, że z jakiegoś powodu nie powinien być w ogóle poprawiany.

Jill dostaje emaila z wiadomością, że błąd jest znowu na jej głowie. Zagląda do niego i czyta komentarz Williego Głównego Developera. Coś tu się jednak nie zgadza. Ludzie używają tego serwera ftp od lat i nigdy się nie wywracał. Wywraca się tylko jeżeli używasz kodu Mikiego. Jill reaktywuje więc błąd, wyjaśnia swoje wątpliwości i błąd wraca do Williego. Tym razem Willie przypisuje błąd Mikiemu do poprawienia.

Mikey ogląda błąd ze wszystkich stron, myśli długo i ciężko, a potem znajduje kompletnie błędną przyczynę. Poprawia jakiś całkiem inny błąd, a jako rozwiązany zaznacza ten, który zgłosiła Jill.

Błąd wraca do Jill, tym razem oznaczony jako "RESOLVED-FIXED" (rozwiązany-poprawiony). Jill jeszcze raz powtarza wszyskie kroki używając nowej wersji i - uwaga - serwer ftp ponownie się wywraca. Reaktywuje więc błąd ponownie i tym razem przypisuje go bezpośrednio Mikiemu.

Mikey jest zakłopotany, ale w końcu znajduje prawdziwą przyczynę błędu. (Już wiesz jaka jest przyczyna? Pozostawię to jako ćwiczenie dla czytelnika. Było już wystarczająco dużo podpowiedzi!) Poprawia błąd, testuje i -- Eureka! Powtórzenie wszystkich kroków nie powoduje już padu serwera ftp. Ponownie oznacza więc błąd jako FIXED (poprawiony). Jill też powtarza wszystkie kroki, stwierdza, że błąd jest poprawiony i zamyka go.

10 Przykazań Śledzenia Błędów

1. Dobry tester będzie się zawsze starał zredukować ilość kroków do minimalnej ich liczby koniecznej do powtórzenia błedu; jest to niezmiernie pomocne dla programisty, który musi znaleźć błąd.
2. Pamiętaj, że jedyną osobą, która może zamknąć błąd jest ta sama osoba, która go wprowadziła. Każdy może rozwiązać błąd, ale tylko osoba która go znalazła może być pewna, że to co znalazła zostało poprawione.
3. Jest wiele sposobów rozwiązania błędu. FogBUGZ pozwala na rozwiązanie błędu jako fixed (poprawiony), won't fix (nie będzie poprawiony), postponed (odłożony na później), not repro (nie da się powtórzyć), duplicate (duplikat), lub by design (według projetku).
4. Not Repro oznacza, że nikt nie dał rady nigdy powtórzyć opisanego błędu. Programiści często używają tego oznaczenia, jeżeli w opisie błędu brakuje kroków koniecznych do jego powtórzenia.
5. Musisz prowadzić dokładny zapis wszystkich wersji. Każda wersja oprogramowania przekazana testerom musi mieć numer ID, aby biedacy nie musieli ponownie testować błędu na wersji, w której nawet nie miał być poprawiony.
6. Jeżeli jesteś programistą i masz kłopoty ze skłonieniem testerów do używania bazy błędów, to po prostu nie przyjmuj do wiadomości zgłoszeń dokonanych inną drogą. Jeżeli testerzy są przyzwyczajeni do przesyłania ci emaili ze złoszeniami, odsyłaj je do nich z powrotem z adnotacją: "Proszę wprowadź to zgłoszenie do bazy. Nie dam rady śledzić wszystkich emaili."
7. Jeżeli jesteś testerem i masz kłopot ze skłonieniem programistów do używania bazy, to po prostu nie mów im o błędach - dodaj ich do systemu i pozwól aby ten przesyłał im automatycznie powiadomienia.
8. Jeżeli jesteś programistą i tylko niektórzy z twoich kolegów używają bazy błędów, to zacznij im przypisywać błędy w bazie. W końcu załapią o co chodzi.
9. Jeżeli jesteś manadżerem i wydaje ci się, że nikt nie używa bazy błędów, którą zainstalowałeś dużym kosztem, to zacznij przypisywać poprzez bazę nową funkcjonalność do zaimplementowania. Baza błędów jest doskonałym narzędziem także do zarządzania niezaimplementowaną funkcjonalnością.
10. Unikaj pokusy, aby dodawać nowe pola do bazy. Prawdopodobnie mniej więcej raz w miesiącu ktoś będzie wpadał na jakiś genialny pomysł na nowe pole w bazie. Będziesz dostawał dziesiątki nowych propozycji, np. na śledzenie w jakim % błąd jest powtarzalny, ile razy się pojawił, jakie dokładnie wersje jakich bibliotek były zainstalowane na maszynie, na której błąd się pojawił, etc. Bardzo ważne jest, aby nie ulegać tym pokusom. Bo jeżeli tak zrobisz, to twój formularz zgłaszania błędów będzie miał tysiące pól, które trzeba będzie wypełnić, i nikt nie będzie chciał więcej wprowadzać nowych zgłoszeń błędów. Aby baza błędów dobrze działała każdy musi jej używać. A jeżeli "formalne" zgłaszanie błędów będzie zbyt pracochłonne, to ludzie będą omijać system.

Jeżeli tworzysz kod, nawet w jednoosobowym "zespole", bez zorganizowanej bazy wszystkich błędów, to po prostu będziesz dostarczał kod niskiej jakości. W dobrych zespołach programistów nie tylko powszechnie używa się bazy błędów, ale nawet ludzie wyrabiają sobie nawyk wykorzystywania jej do przechowywania własnych list "do zrobienia". Ustawiają też domyślną stronę w swojej przeglądarce na stronę z listą przypisanych do siebie błędów, a najchętniej wykorzystaliby system do zgłoszenia administracji biura zamówienia na dostarczenie większej ilości Mountain Dew.

Fog Creek Software makes an easy-to-use bug tracking package called FogBUGZ.