Komentarz do Jak nie należy programować

Tydzień z grubsza zajęło mi doprowadzenie do używalności kodu, który otrzymałem w spadku po pewnym urlopowiczu. Dobrze, że nie mam włosów, bo z pewnością bym je dawno wyrwał, choć z — drugiej strony — na programowaniu cierpi moja broda. Kolega wypoczywa w Iranie, a my próbujemy dojść, co też podmiot liryczny miał na myśli. Kiedy czytanie źródeł dłuży się ponad lekturę Nad Niemnem, znak to, że czas na notkę.

Jak nie należy programować

Na wstępie już zaznaczę, że w ITS Ltd. zajmujemy się budowaniem aplikacji webowych w oparciu o Pythona i Django, więc niektórym poniższy tekst może wydać się płytki/nudny/pozbawiony sensu (niepotrzebne skreślić).

Poradnik niniejszy zalecany jest dla programistów, którzy w różny sposób związani są z serwisem The Daily WTF — czy to przez umiłowanie do czytania publikowanych tam historii, czy to przez bycie bohaterem tych ostatnich. Redakcja zastrzega sobie prawo do skrótów myślowych i przelotnego braku poczucia humoru.

Redundancja

Najważniejszą cechą systemów klasy Enterprise (jeden do teleportacji) jest ich wysoka dostępność (i cena). Jest to fakt tak niezaprzeczalny, jak niezaprzeczalna jest wysoka jakość produktów z rodziny Gadu-Gadu. Autorzy aplikacji klasy E (uniwersalny, automat i do tkanin czarnych) często uważają, że ich produkty z powodzeniem stawać mogą w konkury z aparaturą czasu rzeczywistego. Cóż, każdy może się mylić, ale jakież tajemne receptury zapewniają taką pewność siebie? Dziś Viagrę nabyć można na każdym bazarze, skupmy się więc na technikach programowania.

Autor aplikacji staje wielokrotnie przed trudnymi pytaniami egzystencjalnymi. Gdzie jest specyfikacja techniczna? Jak ja wczoraj wróciłem do domu? Skąd weźmiemy tyle galaretki, żeby napełnić basen? To tylko niektóre z nich. Najważniejsze pytanie, jakie zadają sobie autorzy aplikacji klasy E (E303, E301, może zawierać śladowe ilości orzechów), to jak uniknąć używania bibliotek, których sami nie napisaliśmy, wszak któregoś ranka gotowe przestać działać. Na szczęście tutaj z pomocą przychodzi dogmat Copiego-Paste'a. Wystarczy zatem skopiować kluczowe elementy frameworku do używającej go aplikacji i już możemy spać spokojnie — co dwie kopie to nie jedna, prawdopodobieństwo mówi, że obie nie popsują się jednocześnie.

Optymalizacja czasu pracy

Jeśli brać z kogoś przykłady (a klasa E czyni to niechętnie, sami wszakże stanowią elitę), to tylko z amerykańskiej marynarki. Tradycyjne pojęcia deadline'ów i zarządzania zasobami zastąpić można sprawdzonym na wielu wojnach ŻULU time. W firmie najważniejsi są ludzie, więc zawsze jest czas się napić! Pozwala to płynnie regulować stres powodowany przez pracę, a naukowcy dowodzą, że może w zupełności wyeliminować ryzyko wystąpienia nerwicy (stosujący tę metodykę rzadko dożywają czterdziestki).

Ważne jest również, by programista miał podejście analitycznie i potrafił myśleć outside the box, co w języku polskim oznacza dosłownie myśl, jak ciągle być poza kubikiem. W praktyce sprawdza się najlepiej obranie niekonwencjonalnych godzin pracy (na przykład godzin nocnych) i planowanie przestrzenne (koduję od tego kieliszka do podłogi).

Generalizacja

Generalizacja to dar patrzenia na rzeczy z dystansu. Dla przykładu pies i samochód z dystansu wyglądają podobnie. Dlaczego więc nie umieścić ich w bazie danych we wspólnej tabeli rzecz, odpowiednio pomijając kolumnę rasa w przypadku samochodu i podając zero w kolumnie liczba_drzwi w przypadku psa? Tak zbudowana baza danych jest dużo prostsza do programowania, zwłaszcza jeśli w użyciu jest szkielet ORM.

Dodatkowe punkty komisja przyzna za uproszczenie tabeli do jednego pola, w którym umieścić można zserializowany obiekt dowolnego typu.

Obfuskacja

Duży projekt klasy E często jest oczkiem w głowie korporacji. Nie można zatem dopuścić, by sekrety jego działania poznał niepowołany śmiertelnik. Lata doświadczenia w dziedzinie refaktoryzacji uczą, że najpewniejszym środkiem zapobiegawczym jest obszerne stosowanie obfuskacji. Stosowanie jednoliterowych nazw zmiennych i funkcji nie tylko uniemożliwia zrozumienie geniuszu kryjącego się za kodem, ale także znacznie zmniejsza miejsce, jakie kod zajmuje na dysku. Jest to zaleta nie do pominięcia w przypadku projektów, które korzystają dodatkowo z technik programowania życzeniowego (ale o tym za chwilę).

Niezwykle ważne jest też konsekwentne nieumieszczanie komentarzy w kodzie. Łatwo policzyć, że przeciętna metoda o długości dziesięciu ekranów, stałaby się nieznośnie długa, gdyby co drugi wiersz wstawić komentarz i przeprosiny dla naszego zastępcy.

Zaawansowane techniki zabezpieczania kodu

Kolejną techniką obfuskacji jest, pochodzący z literatury, synkretyzm językowy. Dla zmylenia potencjalnego przeciwnika i lepszego utrwalenia w pamięci dawno nieużywanych technik, staramy się co jakiś czas wtrącić ekran kodu napisanego na przykład w PHP. W tym celu ograniczamy się do części wspólnej składni obu języków, dodatkowo emulując zachowanie zupełnie innego frameworku.

Mało znaną, ale opanowaną do perfekcji przez elitę, metodą wprowadzania zakłóceń w kodzie jest tak zwane prawo wolnego rynku (import bez ograniczeń). Główne zastosowanie tej metody to naprawianie wadliwych języków, których autorzy złośliwie wprowadzili przestrzenie nazw. Wystarczy jednak kilka instrukcji from foo import * starannie porozrzucanych po kodzie (nie zapomnijmy części z nich umieścić w instrukcjach warunkowych) i jesteśmy z powrotem w starym, dobrym bashu. Przyjemny skutek uboczny to fakt, że nikt nigdy nie będzie w stanie odtworzyć zależności aplikacji poza naszym środowiskiem rozwojowym.

Programowanie życzeniowe i stubenci

Jedną z podstawowych prawd na temat programowania jest taka, że każdą aplikację trzeba utrzymywać, a rzadko która nie ewoluuje wraz z upływającym czasem. Pragmatyczny programista dba o to już od pierwszej linii kodu. Zanim jeszcze zajmie się implementacją wymaganej funkcjonalności, stara się przewidzieć możliwe przyszłe drogi rozwoju. Jeśli programista zna się na fachu, owocuje to umieszczeniem w kodzie rozlicznych z pozoru niepotrzebnych metod. Są one z natury zepsute bądź puste i nazywamy je stubami, sam zaś autor nosi fachowe miano stubenta.

Stubenci zapewniają aplikacji bezpieczny margines nadmiarowości, podobnej w naturze do redundancji, co z kolei zmniejsza ryzyko, że przyszły opiekun projektu w wyniku zmieszania niechcący usunie coś niezbędnego. Jedną z rzadziej spotykanych metryk jakości kodu klasy E jest właśnie procentowy udział kodu, który można usunąć bez wpływu na działanie aplikacji. Najlepsi w branży utrzymują się w przedziale od czterdziestu do sześćdziesięciu procent.

Testy jednostkowe i UMŁ

Jak sama nazwa wskazuje, są to testy, które przeprowadza się tylko raz. Dla pewności, że zbędne dane nie wpłyną na wynik ani czas trwania testu, najlepiej przeprowadzić go w środowisku rozwojowym, przy pustej bazie danych. Już samo słowo wdrożenie sugeruje, że klient musi liczyć się z dodatkowymi kosztami w celu późniejszego doprowadzenia produktu do działania w środowisku produkcyjnym. Testy jednostkowe, z natury, mogą być ciężkie do powtórzenia nawet w warunkach laboratoryjnych, stąd nie należy mieć oporów przed skorzystaniem z wygodnego narzędzia, jakim jest UMŁ (u mnie łaziło).

Cóż, na dziś to wszystko, do zobaczenia w kolejnym odcinku poradnika Jak nie należy programować, gdzie wspólnie wzbogacimy wachlarz stosowanych praktyk. Czytał Lucjan Szołajski.