Pierwsza zasada programowania: to zawsze Twoja wina

Oryginalny post: The First Rule of Programming: It's Always Your Fault

Autor: Jeff Atwood

Z pewnością znasz to uczucie. Każdemu z nas kiedyś przytrafiło się coś takiego: analizujesz kod od kilku godzin i wciąż nie możesz znaleźć błędu. Ale on tam jest, tylko jakoś nie możesz się go pozbyć. Myślisz sobie, że chyba jednak coś musi być nie tak z komputerem, na którym kodujesz, albo z systemem operacyjnym, albo z bibliotekami bądź narzędziami, których używasz. Coś musi być nie w porządku!

Choćbyś nie wiem jak bardzo był zdesperowany, nie podążaj tą ścieżką. Jedyne co możesz tam znaleźć to programowanie voodoo albo programowanie przez przypadek. W skrócie, szaleństwo.

Ciągłe walenie głową w mur, walka z trudnymi, dziwnymi bugami -- to może być frustrujące. Ale nie pozwól, by desperacja Cię zwiodła. Istotną częścią bycia skromnym programistą jest zdanie sobie sprawy z tego, że jeśli jest jakiś problem z kodem, który napisałeś, to jest to zawsze Twoja wina. Zasada ta została krótko podsumowana w książce Pragmatyczny Programista i ochrzczona nazwą "Select Isn't Broken" ("select nie jest zepsuty").

W większości projektów kod, który przyjdzie Ci debugować, będzie mieszanką kodu aplikacyjnego pisanego przez Ciebie i innych członków Twojego zespołu, produktów z zewnątrz (systemy bazodanowe, biblioteki sieciowe czy graficzne, specjalizowane algorytmy itp.) oraz środowiska (system operacyjny, biblioteki systemowe i kompilatory).

Może się zdarzyć, że w systemie operacyjnym, w kompilatorze albo w zewnętrznym produkcie siedzi jakiś bug -- ale nie taka powinna być Twoja piewsza myśl. Jest dużo bardziej prawdopodobne, że bug znajduje sie w kodzie aplikacyjnym, który właśnie tworzysz. Generalnie, bardziej opłaca się założyć, że to kod aplikacyjny źle korzysta z biblioteki, niż twierdzić, że z samą biblioteką jest coś nie tak. Nawet jeśli rzeczywiście problem tkwi po drugiej stronie, to i tak będziesz musiał wyeliminować możliwość, że to jednak Twój kod jest źródłem problemu, zanim będziesz mógł zgłosić informację o błędzie, np. do autora biblioteki.

Zdarzyło nam się pracować przy projekcie, w którym starszy programista był święcie przekonany, że coś jest nie tak z wywołaniem systemowym select na Solarisie. Żadne metody perswazji ani przedstawianie logicznych argumentów nie były w stanie zmienić jego zdania (fakt, że sto tysięcy innych aplikacji sieciowych działało bez problemu nie miał znaczenia). Spędził długie tygodnie, programując różne obejścia, które z jakiegoś dziwnego powodu nie rozwiązywały problemu. Gdy w końcu zmuszony siadł do dokumentacji selecta, okazało się, że popełnił błąd, którego naprawienie zajęło mu raptem kilka minut. Od tamtej pory używamy wyrażenia "select is broken" ("select jest zepsuty") jako delikatne przypomnienie w sytuacjach, gdy któryś z nas zaczyna obwiniać system o błąd, którego przyczyna leży prawdopodobnie po stronie programisty.

Konsekwencją współwłasności kodu jest odpowiedzialność za kod. Niezależnie od problemu, jaki masz z oprogramowaniem, w którego tworzeniu akurat uczestniczysz -- nawet jeśli nie jesteś pierwotnym autorem -- zawsze zakładaj, że problem leży po stronie Twojego kodu i podejmuj stosowne działania. Jeśli swoje oprogramowanie zamierzasz pokazywać światu, bierz odpowiedzialność za jego błędy. Nawet jeśli, technicznie rzecz biorąc, nie musisz tego robić. W taki właśnie sposób zdobywa się szacunek i wiarygodność. Z pewnością nie uzyskasz tego, jeśli non-stop będziesz zwalał winę za błędy i problemy na innych ludzi, inne firmy czy inne źródła.

Statystyki pokazują, iż niezwykle rzadko zdarza się, żeby bugi czy błędy w Twoim oprogramowaniu nie były spowodowane przez Ciebie. W książce Programista Doskonały (przyp. tłum.: jest już drugie wydanie, ale nie wiem, czy zostało przetłumaczone na język polski) Steve McConnell przedstawia rezultaty dwóch badań, które to potwierdzają:

Dwa badania przeprowadzone w latach 1973 i 1984 wykazały, że spośród wszystkich zgłoszonych błędów około 95% było spowodowanych przez programistów, 2% przez oprogramowanie systemowe (kompilator i system operacyjny), 2% przez inne oprogramowanie oraz 1% przez sprzęt. Oprogramowania systemowego i narzędzi programistycznych używa obecnie znacznie więcej osób, niż w latach 70. i 80. Można więc przypuszczać, że odsetek błędów powodowanych przez programistów byłby teraz jeszcze większy.

Niezależnie od tego, jaki masz problem z oprogramowaniem, które tworzysz, przejmij inicjatywę. Zacznij od analizy własnego kodu i zataczaj coraz większe kręgi, aż będziesz miał stuprocentową pewność, że wiesz, co jest przyczyną. Jeśli problem tkwi w kodzie, nad którym nie masz kontroli, to nie będzie to czas stracony. Nie tylko udoskonalisz swoje zdolności analityczne i diagnostyczne, ale będziesz także dysponował zapisem swoich działań, który w razie potrzeby potwierdzi Twoje spostrzeżenia. Takie podejście wymaga oczywiście o wiele więcej wysiłku niż wzruszenie ramionami i wskazywanie na system operacyjny, narzędzia czy framework -- ale skutkuje ono zwiększeniem zaufania i szacunku, których raczej nie zdobędziesz poprzez wytykanie palcami i wymigiwanie się.

Jeśli naprawdę aspirujesz do miana skromnego programisty, nie powinieneś mieć oporów przed powiedzeniem "hej, to moja wina -- i zrobię wszystko, żeby dowiedzieć się, gdzie tkwi problem".

3 komentarze:

pawlos pisze...

Ja tak się zastanawiam na ocenami. Jak mam je traktować? Czy jest to ocena tłumaczenia czy raczej oryginalnego tekstu?

Immortal pisze...

pawlos: Dobre pytanie :] Ale chyba powinna to być ocena tekstu. Na tę chwilę jakość tłumaczeń można komentować na sugesterze. Chociaż rzeczywiście przydałby się jakiś osobny system oceniania tych tłumaczeń - pomyślimy o tym.

Anonimowy pisze...

Skromność skromnością, ale jaka satysfakcja przychodzi, gdy zastanawiasz się godzinami co źle zrobiłeś, a okazuje się, że z powszechnie używanym/ą kompilatorem/biblioteką było coś nie tak:)

Prześlij komentarz

Related Posts with Thumbnails