Przejrzyj swoj kod, zanim zaczniesz obwiniać innych
Oryginalny tytuł: Check Your Code First Before Looking to Blame Others
Autor: Allan Kelly
Programiści - wszyscy! - często mają problemy ze zrozumieniem, że ich kod jest zepsuty. To jest po prostu tak mało prawdopodobne, że to na pewno musi być wina kompilatora.
Ale prawda jest taka, iż to bardzo (bardzo) mało prawdopodobne, aby nasz kod nie działał z powodu kompilatora, interpretera, systemu operacyjnego, serwera aplikacyjnego, bazy danych, menadżera pamięci, czy jakiegokolwiek innego składnika systemu. Tak, te błędy istnieją, ale występują rzadziej, niż mogłoby nam się to wydawać.
Raz naprawdę miałem problem z błędem kompilatora, który powodował "wyoptymalizowanie" zmiennej z programu, ale wielokrotnie częściej tylko mi się wydawało, że mój system operacyjny albo kompilator mają bugi. Straciłem przez to dużo czasu: własnego, helpdesku i przełożonych, a na końcu czułem się nieco głupawo kiedy okazywało się, że to jednak mój błąd.
Zakładając, że narzędzia są powszechnie używane, dojrzałe i pracują w wielu systemach, mało jest powodów dla których możnaby wątpić w ich jakość. Oczywiście jeśli jest to wczesna wersja albo coś, czego używa tylko kilka osób na świecie, albo jakaś wersja 0.1 otwartego oprogramowania istnieją przesłanki, aby podejrzewać, że to ten kawałek oprogramowania. (Równie dobrze, podejrzanym może być wersja alpha komercyjnego oprogramowania.)
Skoro błędy w kompilatorze są tak rzadkie, lepiej spożytkujesz swój czas i energię na znalezienie błędu we własnym kodzie, niż na dowodzenie, że kompilator się myli. Zamiast tego zastosuj zwykłe techniki debuggowania: wyizoluj problem, stosuj zastępcze wywołania, otocz go testami, sprawdź konwencje wywoływania, biblioteki współdzielone, numery wersji. Wyjaśnij problem komuś innemu, sprawdź czy nie ma korupcji stosu albo niezgodności typów zmiennych, sprawdź kod na innych maszynach albo w innych konfiguracjach budowania, takich jak debug i release.
Kwestionuj własne założenia i założenia innych. Narzędzia różnych producentów mogą opierać się na różnych założeniach — tak samo jak te od tego samego producenta.
Kiedy ktoś zgłasza problem, którego nie możesz odtworzyć, idź i sprawdź co robią. Może robią coś o czym Ty nigdy byś nie pomyślał albo robią coś w innej kolejności.
Moja osobista zasada stanowi, że jeśli mam buga, którego nie mogę zidentyfikować i zaczynam myśleć, że to może być kompilator, wtedy czas zacząć szukać problemu z korupcją stosu. Jest to szczególnie prawdziwe, gdy dodawanie kodu mającego wyśledzić położenie problemu powoduje, że zaczyna się on przemieszczać.
Problemy z wielowątkowością to kolejne źródło bugów przez które można osiwieć i zacząć wrzeszczeć na komputer. Wszystkie rady, aby stosować prosty kod, należy wielokrotnie powtórzyć, gdy system jest wielowątkowy. Nie można polegać tym, że debuggowanie i testy jednostkowe będą konsekwentnie znajdować bugi, więc prostota projektu jest kluczowa.
Zanim więc zaczniesz winić kompilator, przypomnij sobie poradę Sherlocka Holmesa, "Kiedy wyeliminujesz niemożliwe, to co zostanie, nieważne jak nieprawdopodobne, musi być prawdą.", i stosuj się do niej zamiast do tej od Dirka Gently "Kiedy wyeliminujesz nieprawdopodobne, to co zostanie, nieważne jak niemożliwe, musi być prawdą.".
Artykuł został opublikowany na licencji Creative Commons Uznanie Autorstwa 3.0.
Komentarze (2)
