More

    #IThotStory, czyli największe wpadki programistów

    Co prawda programista to nie saper i może pomylić się więcej niż raz, ale każda wpadka niesie za sobą jakieś ryzyko. Zaliczyliście już jakąś? Podzielcie się z nami swoją historią tak, jak zrobili to inni programiści.

    Programista też człowiek, a mylić się jest rzeczą ludzką. Każdemu zatem może przydarzyć się przysłowiowa wtopa. Przykładów daleko szukać nie trzeba, jeśli przez chwilę pomyślimy o ostatnich testach na produkcji znanego banku 😉 Za niektóre błędy, jak np. deploy w piątek można pójść do programistycznego piekła, inne mogą wzbudzić rozbawienie wśród kolegów po fachu, a jeszcze inne przejść do historii internetu. Dlaczego o tym mówimy?

    #IThotStory

    Postanowiliśmy zapytać znajomych programistów i programistki o największe wpadki, które zanotowali w trakcie swojej koderskiej kariery. Przy czym hasło “największe” rozumiemy dość swobodnie – śmieszne, przykre, spektakularne, albo niedostrzegalne. 

    Ciekawe jest to, że właściwie każdy, kto zawodowo zajmuje się kodowaniem, bez zastanowienia potrafi wymienić co najmniej jedną taką własną wpadkę (i z dziesięć, które popełnił kolega). I mimo to każdy z nich wciąż w zawodzie pracuje i chce to robić nadal, jednocześnie mając świadomość, że dawne błędy nie były ostatnimi i w każdej chwili znów się coś może przydarzyć.

    Jeszcze jedno, nasi znajomi, po tym, jak opowiedzieli swoją historię, zaczęli wywoływać kolegów i zachęcać do podzielenia się ich własną. I tak z naszego pytania, urządzili sobie małe wyzwanie z nominacjami. Poznajcie zatem największe wpadki programistów 🙂

    Gdy programista się spieszy… – wpadka Patryka

    W mojej pierwszej firmie dostaliśmy zlecenie na stronkę eksponatów jednej z kopalni. Projekt jak każdy inny. Ten różnił się tym, że linki do każdego produktu miały być wydane zleceniodawcy w postaci QR kodów. Byłem najmłodszy w firmie, więc praca przy projektach stanowiła 10% mojej ogólnej pracy. Czując oddech ponaglającego szefa (stał za mną), wygenerowałem na szybko QR kody w przerwie od rozwożenia faktur i wieszania banerów. Oczywiście temat na wczoraj. Wygenerowane kody wysłałem klientowi do testów i akceptacji. Akceptacja przyszła po jakimś tygodniu proszenia się.

    Kilka miesięcy później klient zadzwonił, informując, że dziś ma otwarcie nowej części muzeum, która wykorzystuje naszą apkę i QR kody na tablicach przy eksponatach, ale niestety te nie działały. Pomyślałem, że skoro dawniej wszystko było ok, to pewnie serwer robi psikusy.

    Wszystko było jednak ok.

    Poprosiłem o próbkę QR kodu od klienta. Gdy ten przesłał zdjęcie, okazało się, że ten kieruje do:

    localhost:3000/DOMENA_KLIENTA.pl/eksponat_1

    Tak, adres kierował do nieistniejącej wersji roboczej na moim komputerze, a nie na serwer z istniejącym produktem. 

    Niegrzeczne QR kody – historia Grzegorza

    Historia z QR kodami miała jeszcze jeden ciekawy incydent, o którym opowiedział nam Grzegorz. 

    Pierwszy kod QR jaki kolega grafik przygotował, aby wysłać szefowi do testów zawierał link do znanego portalu z treściami dla dorosłych… szef nie sprawdził i wysłał do klienta z informacją „chcemy dodać coś takiego do Waszych katalogów”. Klient był „zachwycony”, bo otwierał link wieczorem przy dzieciach i żonie 

    Backup ważna rzecz 

    W swojej historii Andrzej zwrócił uwagę na kluczową w projektach developerskich rzecz, czyli backup. 

    Dawno temu kolega robił backup całej bazy danych systemu hurtowego – tzn. kopiował pliki. W połowie zreflektował się że kopiuje w złą stronę… Poczekał już te pół godziny aż się skopiuje do końca. To była baza produkcyjna. 12 tysięcy faktur z ostatniego tygodnia zniknęło. W tamtych latach backup był robiony raz na tydzień.

    Uważaj na komunikaty! – anegdota Mateusza

    No więc… true story – serio, serio… opowiadam to dosyć często. W poprzedniej firmie zadaniem jednego z kolegów było przygotowanie niedużego systemu webowego w PHP. Było środowisko lokalne i serwer deweloperski dostępny publicznie. Warto zaznaczyć, że adres znał tylko on i programiści, którzy pomagali w testowaniu. 

    Pewnego dnia zadzwonił do niego handlowiec/menadżer projektu i zapytał jaki jest status, bo zbliża się termin oddania. Kolega powiedział, że w zasadzie wszystko jest zrobione, obecnie system jest testowany i wdrażane są poprawki. PM zapytał czy w takim razie może to gdzieś przeklikać i potestować. Otrzymał więc link do systemu DEV, z zaznaczeniem, że nie jest to jeszcze super stabilne. 

    Po pobieżnym przeklikaniu systemu PM postanowił zaszpanować przed klientem i przesłał mu posiadany link, nie informując o tym nikogo. Klient (starszy prezes) natomiast stwierdził, że prześle to do przeklikania swojej 17-letniej siostrzenicy uczącej się w technikum informatycznym. 

    Siostrzenica kliknęła więc w jeden z odnośników, po czym wyskoczyło okno dialogowe (alert), a na nim komunikat o wulgarnej treści. Siostrzenica oczywiście zadzwoniła do wujka ze skargą, ten do PMa, a ten z kolei do naszego kolegi z wielką awanturą… Okazało się, że handlowiec poklikał pobieżnie i w jego mniemaniu działało wszystko OK. 

    Wcześniej jednak koledzy z zespołu znaleźli błąd, którego nie umieli odtworzyć na środowisku lokalnym i testowali na DEV z użyciem różnego rodzaju komunikatów (w tym wulgarnych). 

    Historia podobna do pewnie kilku historyjek z komunikatami „dupa!”… Morał z tego taki, że lepiej dawać neutralne komunikaty „debugowania” poprzez alert/println.

    Kod z żądaniem okupu 

    Kolejną historię o komunikatach przywołał Paweł.

    Dawno temu w aplikacji pisanej w Clipperze (taki język pod DOSa) nazwy funkcji i procedur były domyślnie obcinane do 10 znaków.

    Były funkcje „ustawSetkeye” i „wywalSetkeye” (przypisywały klawisze funkcyjne do funkcji).

    Jak to się czasem zdarza, program posypał się w trakcie użytkowania i rzucił komunikatem „wywalSetke”. Korzystająca z aplikacji kobieta myślała, że to roszczenie o jakiś okup, co nieźle ją przeraziło. To pokazuje jak ważne jest sprawdzanie pisowni w trakcie debugowania. W przeciwnym razie można mniej techniczne osoby przyprawić o zawał serca 😉

    Kontrola osobista – opowieść Marcina

    Znam tę historię tylko z opowieści… Pewna firma z Polski wdrażała system dla Straży Granicznej. W fazie testów systemu pewnemu obywatelowi na granicy zrobiono kontrolę osobistą łącznie z wizytą u urologa, samochód zaś rozebrano do 0. Po jakimś czasie go wypuszczono bo niczego nie znaleźli… 

    Okazało się, że inteligentny system sklasyfikował człowieka jako terrorystę ze względu na nazwisko „BRONiewski”, ponieważ tak skonstruowano klucz. 

    Wniosek z tego taki, by zawsze dobrze przemyśleć warunki działania systemu, szczególnie w przypadku takich systemów.

    Czas to pieniądz – “dziadek-dobry-bimber”

    Klient wynajął kiedyś na pół roku zespół z software house’u, w którym pracowałem. Naszym zadaniem było dopisanie modułu filtrowania potencjalnych transakcji wchodzących do wielkiego systemu analizującego dane „handlowe”. Zgodnie z ich obliczeniami, algorytm zaaplikowany w module filtrującym miał zmniejszyć ruch wpływający do systemu o 40% (te 40% i tak nie przyniosłoby udanej transakcji). To były dziesiątki tysięcy requestów na sekundę. W tym czasie zespół klienta miał filtrować ruch wychodzący z systemu do innego serwisu. Oszczędności były wyliczone na dziesiątki tysięcy dolarów miesięcznie.

    Po pół roku implementacji i podłączeniu wersji MVP okazało się że analitycy na samym początku dali ciała i ich algorytmy filtrowały te same zlecenia co filtr wychodzący. Oszczędności z naszego filtra wynosił mniej niż 1% i więcej kosztowała infrastruktura, na której stał 😃

    Tak więc kasa i czas w błoto.

    TEST123 – historia Oskara

    W mojej pierwszej pracy byłem PHPDeveloperem. W pierwszym miesiącu robiłem integrację z UPS. Przez przypadek dodałem w SQL średnik i nie zadziałał WHERE. Na produkcyjnej bazie do ponad miliona faktur dodałem numer listu przewozowego na TEST123321Oskar XD

    Lenistwo ma krótkie nogi – anegdota Katarzyny

    W pewnej firmie pomysłowy administrator bez zgody szefa wynajął sobie pracownika z Azji, który robił wszystko za niego. Sprawa wyszła na jaw, gdy sprawdzono, dlaczego jest tak duży ruch sieciowy z Chin do ich bazy danych. Jeśli już więc chcesz sobie uprościć pracę, to naucz się dobrze zacierać ślady 😉 

    Jaka jest Twoja wpadka? 

    Choć dzisiaj firmy bardzo dbają o to, żeby dostarczyć produkty jak najlepsze, jak widać, błędy nadal się zdarzają. Legendarne jest już tzw. „testowanie na produkcji”, czyli praktyka, że „jakoś to będzie” i oddawanie na produkcję kodu, który nie był dobrze przetestowany. Jak również odpalanie deploymentu w piątek o 16:00 przez co w weekend podnoszony jest alarm, kiedy coś nie działa, a programiści zrywani są z łóżek lub przerywa im się weekendowy relaks czy imprezę. A Ty jaką wpadką możesz się “pochwalić”?


    Marek Zoellner
    Specjalista ds. contentu i znawca rynku IT. Absolwent filologii polskiej, wieloletni dziennikarz prasowy, radiowy iinternetowy. Swoje doświadczenie zawodowe związane z pracą nad słowem wykorzystuje obecnie w branży IT.

    Latest articles

    Automatyzacja z Pythonem – pobieranie kolekcji filmów z YouTube

    Automatyzacja czynności, które są czasochłonne, to według mnie największa zaleta nauki programowania. Często zadania wymagające od nas klikania, czekania i przepisywania captchy...

    Programowanie funkcyjne w JS

    Jeśli bierzesz udział w rozmowach rekrutacyjnych na stanowisko regular lub senior developera, to pewnie niejednokrotnie miałeś lub miałaś do czynienia z takimi...

    Własny plugin do Figmy w React.js

    Jeśli udało Ci się kiedykolwiek pracować z Figmą, istnieje spora szansa, że narzędzie przypadło Ci do gustu. Tak przynajmniej było w moim...

    Wykorzystanie Virtual DOM na przykładzie Reacta

    Virtual DOM to bardzo popularne rozwiązanie znane z Reacta. Co to dokładnie jest? W jaki sposób działa w Reactcie? O tym opowie...

    Leave a reply

    Please enter your comment!
    Please enter your name here

    Related articles

    X