Architektura

Jak programista może stwierdzić czy systemowi coś dolega patrząc wyłącznie na jego wejście i wyjście? Jeśli chcesz to wiedzieć (i za bardzo nie nie przeszkadza Ci standup), przyjdź i zobacz. Terapia jest bezpieczna! ;-)

Jedną ze szkół zapoznawania się z systemem jest długie i namiętne czytanie dokumentacji, przerywane rzucaniem okiem do kodu. Inną szkołą jest zanurkowanie w model danych (często w bazie) i posurfowanie po interfejsie użyszkodnika. Są to dwa naturalne końce systemu, legendarne wejście i wyjście. Poprzez oglądanie stanu tychże końców można sprawdzić, czy w środku jest zdrowe trawienie, czy niezdrowy proces gnilny. Wnikliwa egzaminacja pozwala stwierdzić obecność “DDDozy pospolitej”, “stringozy złośliwej”, “biegunki regexowej” czy też “syndromu nie-zrobione-u-nas”. Niestety, czasem do infekcji dochodzi już na etapie życia płodowego programisty (czytaj: w szkole). Zapraszam na kurację. Przeczyszczającą. (Czyli naturalny ciąg dalszy “Passwords. Do you keep them safe?”)

“Najlepszy algorytm do sortowania to quick sort.”
“Indeksy przyspieszają działanie bazy.”
“Dane sortuje się przy pomocy ORDER BY.”
“Dziedziczenie be, kompozycja cacy.”
“Windows to system operacyjny.”
“W bazie musisz mieć transakcje.”
“Java jest wolna.”
“Nie jedz żółtego śniegu.”
“Nie należy samemu podpisywać certyfikatów.”
“Interrupt w Javie jest skopane.”

Świat IT jest pełen mantr/prawd objawionych, przekazywanych (często w tradycji ustnej) w plemionach programistów. Bezmyślnie powtarzane z pokolenia na pokolenia (często już od uczelni) powodują bezrefleksyjne stosowanie, które może wywołać w najlepszym przypadku więcej szkody niż pożytku. W najgorszym: totalną klapę za wagony dolarów. Kontekst jest nieodzowną otoczką każdej mantry. Pozwala bez pudła odróżnić właściwe użycie od nadchodzącej plajty.