W kontekście tworzenia oprogramowania często mówimy o dobrych praktykach. O tym, jak coś powinno wyglądać, jakie zasady muszą zostać wprowadzone aby coś zostało uznane za DOBRE. Używamy podświadomie pozytywnych, powtarzalnych fraz – Clean Code, Dependency Injection, Design Patterns, Single Responsibility Principle, Agile i wymieniać mógłbym dalej, zajmując pół artykułu buzzwordami.
Otaczamy się wianuszkiem pięknych i miłych słów – serio, nie mam tu na myśli tylko KISS. Zasady które staramy się wprowadzać, tworząc kod z reguły mają właśnie ten pozytywny wydźwięk, prowadzący po prostu do ZRÓB TO DOBRZE. Nie neguję takiego podejścia, wręcz przeciwnie. Ubolewam nad tym, że czasem zbyt arogancko podchodzę do rozwiązań co najmniej dziwnych, a z moich ust pada kolejne „co to kurwa jest?„. Dobra, kto tak nie mówi, pierwszy pisze komentarz na dole 😉
Do czego dążę – pomimo, że „na jachcie się nie narzeka” pewne rzeczy należy nazwać po imieniu. Kod, z którym pracujemy, nie raz (lub też w większości) bywa najzwyczajniej w świecie STUPID.
STUPID
O co mi się rozchodzi? Dlaczego obrażam efekty czyjejś pracy? Wyjaśniam. Posługuję się akronimem, który niesie nie tylko negatywny wydźwięk, ale dotyczy także konkretnych aspektów kodu. Również negatywnych bo negatywnie oddziałuje na całość oprogramowania. Nie mam na celu obrażania kogokolwiek, efekt pracy, który można skomentować w powyższy sposób jest wynikiem wielu składowych – m.in.: wiedzy, doświadczenia, czasu, nawyków czy też odgórnej presji. To temat na zupełnie inny wywód.
Dobra, ale co to znaczy, że kod jest STUPID? Oznacza to, że w kodzie mamy do czynienia z następującymi, sześcioma anomaliami:
S jak Singleton
Wzorzec projektowy Singleton jest nadużywany. Teraz już wiemy, że ten zdefiniowany przez Gang Of Four wzorzec, przysparza problemów i blokuje rozszerzalność oprogramowania. Czy jego wykorzystanie jest zasadne? Zależy od kontekstu. W 99% przypadków problem może zostać rozwiązany w bardziej racjonalny sposób.
Prawdą jest jednak, że pchaliśmy go wszędzie gdzie się dało. Rozwiązywał każdy nasz problem. Taki Super Hero. Ostatnio nawet ktoś widział jak Singleton wrzucał ubrania do pralki.
T jak Tight coupling
Silne powiązania na poziomie klas i modułów. Nie ma wstrzykiwania zależności, ponieważ zależności tworzone są wewnątrz klasy lub wykorzystany został Singleton z punktu powyżej. Klasy, a dokładniej konkretne implementacje są ze sobą mocno powiązane – rozbudowa oprogramowania o nowe funkcje staje się problematyczna.
U jak Untestability
Kod jest trudny do przetestowania. Ale co to znaczy? To np.:
- duża metoda, która wymaga kilkunastu przypadków testowych aby w pełni zweryfikować jej działanie,
- tworzenie obiektów wymaga dostarczenia niezliczonej ilości obiektów zależnych,
- bezpośrednie odwołania do bazy danych, systemu plików czy też zewnętrznych usług nie mogą być zastąpione przez Test Double.
Gdy pytasz „gdzie testy?„, otrzymujesz odpowiedź „nie ma, bo się nie da tego przetestować„. Nie da lub stworzenie i utrzymanie testów wymaga ogromnego nakładu pracy i czasu.
P jak Premature Optimization
Optymalizacja kodu w wielu przypadkach wiąże się z ze skomplikowaniem rozwiązania. Optymalizacja to nie tylko zmiana zapytania SQL, iterowania po kolekcji czy wykorzystania Hash Table. To również niskopoziomowe operacje na dysku, rozpraszanie zasobów po serwerach na całym świecie, wykorzystywanie złożonych algorytmów, które poznaje się poprzez wielogodzinne studiowanie opracowań, redundancja danych, wprowadzanie systemu kolejek czy systemu cache, którego walidacja jest jednym z najtrudniejszych elementów w informatyce.
Przedwczesna optymalizacja traktowana jest jako antywzorzec, tak jak w przypadku nieszczęsnego Singletona. Aby było jasne – nie mówię o problemie N+1, usprawnieniach drobnych jak właśnie zapytania SQL – to nie jest zaciemnianie kodu. Ale o rozwiązaniach, które nad wyrost są skomplikowane i mają zapobiegać problemom w przyszłości, których na horyzoncie nie widać.
I jak Indescriptive Naming
Nazwy zmiennych i metod mają odzwierciedlać ich zastosowanie. Zwięzłe, reprezentujące rzeczywistość. Ktoś się z tym nie zgodzi? Nazewnictwo jest ciężkim kawałkiem chleba, nie bez powodu jest drugim najtrudniejszym elementem informatyki (patrz wyżej). Jednak każda mniej lub bardziej opisująca nazwa będzie lepsza od metody get() występującej bez kontekstu albo stylu: u, u1, u2. Nazwy pojawiają się wszędzie – to namespace, nazwa klasy, metody, zmiennej, stałej. Programowanie to między innymi umiejętne nazywanie rzeczy.
Pracowałem kiedyś z systemem gdzie poszczególne akcje systemu były zapisane w funkcji o nazwie c1(), c2() itd. Jak myślicie, akcja odpowiadająca za rejestrację użytkownika, znajdowała się w jakiej funkcji? Stawiam piwo temu kto odpowiedział c16() (chyba, że pracowałeś ze mną nad tym systemem 🙂 ). Czaisz? c16(). Brzmi jak nazwa pewnego androida (#IYKWIM).
To działa do momentu kiedy dzień w dzień pracujesz nad tym systemem, w pojedynkę. Wróć do kodu za tydzień lub dwa. Wprowadź nową osobę w ten kod. Wytłumacz, że funkcja c2() odpowiada za uwierzytelnianie użytkownika. Ja spaliłbym się ze wstydu, że nie poświęciłem 30 sekund na nazwanie tej funkcji w rzetelny sposób.
To nie absurd. Takie projekty istnieją.
D jak Duplication
Duplikacja kodu jest zła. Koniec kropka. Jedna zmiana która musi być wielokrotnie powtórzona jest błędogenna. Po co wykonywać te same czynności? Można przecież wykorzystać swoje nadprzyrodzone umiejętności programowania i skorzystać z funkcji, klasy czy całego modułu aby nie powielać kodu – słowo klucz reużywalność.
Ktoś kiedyś powiedział: „(…) the best programmers are lazy„.
Nie jestem the best, ale leniwy fest. Lubię ułatwiać sobie życie, a w tym przypadku pracę.
Co dalej?
Chcesz aby Twój kod był STUPID? Wątpię. Programiści których znam, chcą uchodzić za profesjonalistów, ich wizytówką nie jest ładnie odstrzelony layout na stronie domowej. Ich wizytówką jest kod, udostępniany często na GitHubie, będący nie raz składową rozwiązań Open Source.
Jak w takim razie postępować, aby kod stawał się lepszy?
Rozpocząć chociażby od stosowania przy programowaniu obiektowym zasad SOLID. Czyli zastosować zasady o wydźwięku pozytywnym, tak aby Twój kod zaczynał być odbierany w sposób pozytywny przez innych programistów. Pamiętaj Twój kod to Twoja wizytówka.
Dla chcących zagłębić bardziej temat akronimu STUPID polecam dwie publikacje:
