Żargon programistów, czyli kilka słówek z programistycznego slangu, które warto znać, gdy współpracujesz z firmą technologiczną
Żargonowe określenia programistyczne na błędy (bugi!)
Common Law Feature
Common Law Feature, to rodzaj błędu, który istnieje w systemie na tyle długo, że stał się już jego nieodłączną częścią. Nikt już nie oczekuje jego naprawienia, a dział Obsługi Klienta, po prostu cierpliwie tłumaczy użytkownikom, że czasem tak się zdarza i sugeruje inną drogę.
Heisenbug
Heisenbug, to błąd programu, który zmienia swoje cechy, dając co rusz nowe rezultaty lub całkowicie znika, gdy próbujemy mu się przyjrzeć.
Określenie pochodzi od zasady nieoznaczoności Heisenberga, nazywanej też czasami zasadą nieokreśloności. W wielkim skrócie, mówi ona o istnieniu par takich wielkości, których zmierzenie jednocześnie z wielką dokładnością jest niemożliwe, ponieważ zwiększanie dokładności pomiaru jednej, zmniejsza dokładność pomiaru drugiej.
Higgs Bugson
Higgs Bugson, to dość specyficzny i tajemniczy rodzaj bug’a hipotetycznego. Przewidziany na podstawie małej liczby wpisów w dzienniku zdarzeń i nieprecyzyjnych zgłoszeń użytkowników. Mówi się o nim hipotetyczny, bo w praktyce niezwykle trudno go odtworzyć, a czasem i w ogóle. Koniec końców, nigdy nie wiesz czy ten bug tak naprawdę tam jest czy nie, a jeśli jest, to co go powoduje.
Nazwa błędu pochodzi od bozonu Higgsa — legendarnej elementarnej cząstki, która teoretycznie powinna istnieć, jednak przez całe dekady nie można było jej fizycznie znaleźć (Było! Udowodniono w końcu jej istnienie w 2012 roku).
Hindenbug
Hindenbug, to naprawdę ciężki błąd, który niszczy dane, obezwładnia system lub nawet całkowicie go wywala.
Określenie tego bugu pochodzi od katastrofy niemieckiego sterowca LZ-129 „Hindenburg”, który spłonął w trakcie cumowania na lotnisku w ’37 roku. Sterowiec dosłownie w kilka sekund stanął w płomieniach i runął. Katastrofa Hindenburga położyła kres wykorzystaniu sterowców do przewozu pasażerów w celach turystycznych.
Hydra
Hydra, to rodzaj bug’u, który przy próbie naprawienia, wywołuje dwa nowe bugi. Zupełnie jak odcięcie głowy mitologicznej Hydry, nie zabijało potwora a sprawiało, że na miejsce odciętej głowy, pojawiały się dwie nowe.
Kodu o postaci Hydry nie da się naprawić. Trzeba napisać go na nowo.
Loch Ness
Loch Ness Error, czyli błąd z Loch Ness, to bug, który raz się pojawił i nikt go więcej nie widział. Mianowicie — nie da się ponownie wywołać błędu, więc nie można go naprawić.
Mad Girlfriend Bug
Mad Girlfriend Bug, czyli błąd wkurzonej laski, to taki rodzaj bug’u, który widzisz na własne oczy, ale program mówi Ci, że wszystko jest w porządku. A jak stereotypowo się mawia, gdy kobieta mówi Ci, że wszystko w porządku, wiedz, że nic nie jest w porządku!
Żargonowe określenia programistyczne na zgłoszenia bugów
Drug Report
Drug Report, to zgłoszenie użytkownika, napisane w tak niejasny, niezrozumiały sposób, że zapewne jego autor musiał palić crack.
Chug Report
Chug Report, to lżejsza wersja Drug Report — nadal niezrozumiała i dziwnie napisana. Autor zgłoszenia może i nie palił koki, ale z pewnością musiał “dziabnąć” kilka kieliszków alkoholu.
Shrug Report
Shrug Report, to raport o błędzie, z którego niewiele wynika. Z takiego zgłoszenia programista dowiaduje się, że coś nie działa, ale opis problemu nie opisuje sytuacji. Nie wiadomo, co dokładnie się stało gdzie i w jaki sposób.
Smug Report
Smug Report, to zgłoszenie błędu przez użytkownika, które zawiera multum nieistotnych szczegółów, samozwańczych opinii, sugestii naprawienia buga i jest stosunkowo obszerne. Z uwagi na to, że wszystkie domysły użytkownika są zawsze błędne, smug report, traktowany jest jako stosunkowo irytujące zgłoszenie od kogoś, kto myśli, że wie więcej niż rzeczywiście wie.
Żargonowe określenia programistyczne na pomysły, komunikację i produktowe flow z PM’ami, zarządem i Klientem
Duck
Duck, czyli Kaczka, to funkcjonalność dodana wyłącznie w celu zwrócenia uwagi na zarządzanie produktem, która później ma zostać usunięta, unikając niepotrzebnych innych zmian w produkcie.
Innymi słowy, Ducks, to “pomysły dla pomysłów” stworzone przez PM’ów, którzy bardzo chcieli pokazać, że są potrzebni i wnoszą coś do produktu.
Fear-Driven Development
Fear-Driven Development, to określenie na takie zarządzanie produktem, które ma wprowadzić jak najwięcej strachu i paniki. Nagłe zwolnienia pracowników, przesuwanie deadline’ów na wcześniejsze daty, zmniejszanie zasobów ludzkich — Fear-Driven Development to innymi słowy, zarządzanie przez presję.
Featuritis
Featuritis, zwane też często creeping featurism (w dosłownym tłumaczeniu na polski “pełzający featuryzm”), to tendencja do dorzucania ton nowych funkcjonalności z każdą odsłoną (release’em) produktu.
W konsekwencji featuritis sprawia, że finalny produkt tak jest nimi przeładowany, że rozpoczynający swoją przygodę z produktem użytkownik, na serio może się przestraszyć, a już na pewno, nie jest w stanie ich wszystko ogarnąć. Tylko i wyłącznie wąskie grono user’ów, którzy od dawna korzystają z produktu i regularnie aktualizowali swoją wiedzę o nowych dawkach funkcjonalności, potrafi z produktu właściwie korzystać.
Protoduction
Protoduction, jest kombinatem słów prototyp+produkcja i oznacza prototyp, który w końcu trafił na produkcję.
Satisficing
Satisficing, to odpowiednik znanego doskonale “good enough” i odnosi się do rozwiązań, które nie są najbardziej ambitne czy najlepsze, ale są wystarczające dobre, by rozwiązać problem, a kosztują mniej zasobów ludzkich i czasowych.
Żargonowe określenia programistyczne na kodowanie, funkcjonalności itp.
Brute Force
Brute Force, czyli dosłownie brutalna siła, to taki styl programowania, który owszem, jest skuteczny, niemniej bardzo wolny i niefinezyjny. Polega na czystej mocy obliczeniowej (liczymy wszystko po kolei, bez żadnych algorytmów poprawiających wydajność).
DDD (Debugowanie dupą)
DDD, Debugowanie dupą, Dupa Driven Development — często stosowany sposób na znalezienie buga. Wklejasz w kod/alert/konsolę słowo “dupa” (choć oczywiście może to być każdy inny wyraz) i sprawdzasz, czy pojawia się na ekranie. Niezalecane przede wszystkim z uwagi na to, że omyłkowo może się znaleźć na produkcji.
Hooker Code
Hooker Code, czyli w dosłownym tłumaczeniu, kod prostytutki, to taki kod, który wprowadza niestabilność w aplikację (np. powoduje jej zamykanie).
- Czy strona znowu padła? Nadal jest tam ten Hooker Code?
Jenga Code
Jenga Code, to taki fragment kodu, którego usunięcie powoduje całkowite rozwalenie programu. Jak w grze Jenga — usuwamy kluczowy klocek i nagle cała budowla się rozsypuje.
Jimmy
Jimmy, to określenie nowego, świeżo upieczonego programisty lub ogólniej, bezradnej osoby.
Np. podczas prac nad nowym projektem, możemy rzucić hasłem:
A co jeśli Jimmy zapomni zaktualizować kod?
Megamoth
Megamoth, to skrót pochodzący od MEGA MOnolithic meTHod. Najczęściej określa się tak jakąś fundamentalną, mega rozbudowaną metodę, która ciągnie się przez minimum dwa ekrany.
Uwaga! Megamothy większe od 2k LOC krążą nad miastem!
Ninja Comments
Ninja Comments, to określenie na komentarze w kodzie, które są pochowane, niewidzialne lub w ogóle ich tam nie ma.
Reality 101 Failure
Reality 101 Failure, to taka funkcjonalność programu, która robi dokładnie to, o co została poproszona, ale po wdrożeniu okazuje się, że pierwotny problem został całkowicie źle zrozumiany i funkcjonalność jest zatem bezużyteczna. W żaden sposób nie rozwiązuje bowiem problemu.
Refuctoring
Refuctoring — wzięcie w programistyczne łapy kawałka czystego i dobrego kodu, i poprzez sukcesywne wprowadzanie małych, nieodwracalnych zmian, sprawienie, że nikt inny nie może już ogarnąć.
Rubberducking
Rubberducking, czyli rozmowa z gumową kaczuszką, to określenie takiego spotkania, gdy jedna osoba opowiada o problemie i zadaje pytania, a druga w zasadzie nic do tematu nie wnosi. Finalnie, wychodzisz sam odpowiadając sobie na swoje własne wątpliwości. Zupełnie jakbyś rozmawiał z gumową kaczuszką, ustawioną przy Twoim monitorze (o ile taką, masz oczywiście).
Unicorny
Unicorny, czyli jednorożcowy, to przymiotnik stosowany czasem do funkcjonalności i zmian w systemie, które są jeszcze na bardzo wstępnych etapach rozwoju (nie są jeszcze sprecyzowane ani opisane) i równie dobrze mogłyby być zmyślone/nie istnieć.
Yoda Conditions
Yoda Conditions, to jak można się łatwo domyślić, pisanie w kodzie warunków w szyku przestawnym w stylu Yody.
Przykład linijki w warunkach Yody:
niebieskie jest niebo (‘blue’ === sky)
Gdy powinno to brzmieć:
niebo jest niebieskie (sky === ‘blue’)
Inne określenia (niekoniecznie z żargonu, bo wyrażenia te istnieją, niemniej mało kto wie, co znaczą spoza świata tech)
Krotka
Krotka, to inaczej rekord w bazie albo jeden z typów danych (np. tuple w Pythonie).
Wersja Alpha i Beta
Wersja Alpha produktu, to bardzo wstępna wersja produktu, która nie zawiera wszystkich planowanych funkcjonalności. Dostęp do niej mają zwyczajowo tylko i wyłącznie użytkownicy wewnętrzni danej firmy.
Wersja Beta, zwana też testem Beta, to z kolei ostatnia wersja testowa danego produktu, kluczowa w jego rozwoju. To właśnie wówczas produkt zostaje udostępniony zewnętrznym użytkownikom — przechodzi ostateczną próbę w rzeczywistym środowisku.
