Pieprzyć warstwy abstrakcji

Od jakiegoś czasu zbierałem się do napisania tego tekstu, ale nie bardzo mogłem się zebrać, myślałem, że to tylko moje widzimisię, może zmęczony jestem. Ostatnio jednak najpierw trafiłem na ten wpis: What’s Wrong With Object-Oriented Programming? następnie na ten Frameworks, libraries, languages and deconstructing bullshit i to mnie jakoś zmotywowało, poukładało co bym chciał napisać, tak aby inni mogli sobie z tym podyskutować. Tak więc, miłej lektury 🙂

Dawno, dawno temu

Nie wiem jak Wam, ale mnie dawno, dawno temu robienie aplikacji w php (stron, skryptów, bibliotek) dawało niezły „fun”. Nie był to idealny kod (kto wtedy taki robił…), ale pewien poziom trzymał, tj. kompromis między obowiązującą wtedy jakością, a wygodą. Królowała wtedy KohanaPHP, można było w niej sensowne rzeczy robić w miarę prosto i szybko. Poziom abstrakcji był niewielki. Jak ktoś wiedział co robi, to framework mu nie wchodził w paradę. Kod frameworka był ograniczony przez to jak był napisany, ale nasz kod i logika domenowa (o ile takowa była) mogą mieć bardziej skomplikowaną architekturę. Ale nic na siłę – potrzeba coś prostego, proszę bardzo. Aplikacja jest bardziej wymagająca, nie ma sprawy, możesz poszaleć trochę bardziej, byle tylko to co robisz rozwiązywało problem dla którego to programujesz i dawało się potem utrzymywać jeśli to konieczne.

Upadek Kohany

Oczywiście nie chodzi mi tu w sensie dosłownym o sam moment, ale symbol zmian w kodzie, koniec pewnego formatu. Bo gdzie jesteśmy teraz? Dla części społeczności PHP teraz już nie chodzi o kod, działanie, rozwiązywanie czegokolwiek. O nie, to nie ma aż takiego znaczenia. Teraz chodzi o warstwy abstrakcji. Masz fajną bibliotekę, ale nie masz do niej testów, pomimo, że ona nie jest jakaś strasznie skomplikowana – pfff, bez testów to się nie liczy, weź się ogarnij. Korzystasz z Laravela – nie ważne jaki jest Twój kod, sam Laravel ssie, więc lepiej głośno się tym nie chwal, że w nim robisz. Twoja biblioteka to 2 klasy, bo więcej nie potrzebujesz? Stary, na jakim świecie Ty żyjesz, powinieneś to rozdzielić na 5 warstw abstrakcji i gdzie masz interfejsy i DI jak bym chciał którąś warstwę podmienić? Zrobiłeś aplikację, która jest nieco bardziej skomplikowana, fajnie działa? OMG, jest 2016, w czym Ty to zrobiłeś, trzeba było użyć Symfony i Doctrine, jak Ty robisz formularze, czemu nie używasz Twiga…

Krajobraz po bitwie

Sporo osób tak to teraz widzi: pełna profeska, DDD, masa abstrakcji, Symfony i Doctrine zawsze i wszędzie. Nie ważne jaki jest Twój kod, ważne z jakiego narzędzia korzystasz. Jak ze złego (np. Laravel) to reszta nie ma już znaczenia. Framework to już nie tylko narzędzie, które pomaga robić aplikacje. To cały kombajn, który determinuje Ciebie, Twój kod, całą stworzoną aplikację. A przynajmniej takie jest częste spojrzenie na frameworki, „dajcie mi aplikację w Laravelu, a się pośmiejemy”, ale Symfony to wiecie, szacun i merytoryczne uwagi co można zrobić lepiej. Nikt nie patrzy na samą aplikację, że fajnie działa i pokrywa 100% zapotrzebowania na funkcjonalności – Laravel albo singleton i jesteś nikim, tworzysz śmieszny kod w pseudoframeworku. Jeśli stworzysz bibliotekę, a nie jest ona idealna jeśli chodzi o abstrakcję, wzorce projektowe, DI itd to lepiej zachowaj ją dla siebie.

Nie dajmy się zwariować

No właśnie, nie dajmy się zwariować. Z jednej strony coraz więcej aplikacji online ma rozbudowany backend i tam nie ma miejsca na kompromisy, bez odpowiedniej abstrakcji i dobrego frameworka można robić zakłady kiedy będzie konieczne przepisanie tego od nowa, bo na pewno będzie. Dobry framework, który wymusza pewne praktyki i umożliwia nadpisanie różnych funkcjonalności jest bezcenny i tu nie ma co dyskutować. Podział na Bundle plus Compiler Passes daje prawie duże możliwości. Ale jest też druga strona – cała masa aplikacji, które tego nie potrzebują, klient chciał, klient dostał, wszyscy zadowoleni. Nikogo nie obchodzi to, że następna wersja Laravela będzie miała jakieś niezapowiedziane BC, ważne, że to co chciałem, to zrobiłem szybko i sprawnie, a wszystko działa tak jak trzeba. To nie system do podtrzymywania akcji serca, tylko strona dla klienta, taki tam mini sklep. Pieprzyć zbędne warstwy abstrakcji, bo one tutaj nie są do niczego potrzebne. Tak samo w tych kilku małych bibliotekach, które dla potrzeby tego projektu zrobiłem, a pewno je wykorzystam w innych projektach również. A jak będzie potrzeba, to je rozbuduję. Nie dajmy się zwariować, wmówić sobie, że wszystko zawsze musi być SOLID, najlepiej z DDD, bo inaczej to nie jest nic warte. Ale nie przesadzajmy też w drugą stronę – robię byle jaki kod, bo działa, a klient się nie czepia. Nie o to chodzi. Chodzi o pewien umiar, złoty środek. SRP, KISS, DRY (plus DI/DIC) to podstawa, którą warto w sobie wypracować, reszta to pole do dyskusji odnośnie konkretnego projektu i sytuacji (deadline).

To tylko zabawki

Framework to nie święty grall, tylko zwykłe narzędzie. Oczywiście, jak ktoś zna tylko młotek, to wszędzie widzi gwoździe, Symfony jest najlepsze do wszystkiego itd. Ale prawda jest taka, że do jednych aplikacji lepiej jest użyć Laravela, do innych Symfony, a do jeszcze innych WordPress / Presta / Joomla. A czasami jakiś micro framework. Ale nie, dla wielu to nie do pomyślenia, robić aplikacje w Symfony i Laravelu, w zależności od potrzeb. To tylko narzędzia, a nie religia, jak wyznaję jedną, to się jej trzymam i nie interesują mnie inne. Tak samo jest z warstwami abstrakcji, nie zawsze są nam potrzebne w swojej idealnej postaci, zazwyczaj wystarczy pewien kompromis. A to jaki kompromis to już zależy – jeśli robimy własny duży projekt, który będzie wymagał długoterminowego wsparcia, to miejsca na kompromis jest raczej mało 😉

Konkluzja

Nie bądźmy zakładnikami perfekcjonizmu. Wszystko co robimy ma kontekst tego po co to jest robione i co z tym się będzie dalej działo – jak zostanie zaorane po zakończeniu kampanii reklamowej, to dużo rzeczy nie ma sensu. Programowanie obiektowe jest fajne, ale niech kolejne warstwy abstrakcji nie przesłonią nam samego kodu i tego co ma on zrobić. Można uprawiać sztukę dla sztuki, tylko po co? I tak nie przewidzimy wszystkiego, jak na przestrzeni lat będzie się zmieniać nasza aplikacja, jak będzie dalej wyglądał framework na którym ją oparliśmy, jakie BC będą w zewnętrznych bibliotekach z których korzystamy (a im więcej ich mamy, tym większe piekiełko nam się szykuje w skali długoterminowej). Framework to tylko narzędzie, jak mamy coś większego swojego, to bardzo możliwe, że nadal jesteśmy na Symfony 1.x, albo 2.4 bo za dużo by nas kosztowało przepisywanie swoich i cudzych bundli na 3.0 – takie życie. Często nie wiemy jak dalej będzie się rozwijała nasza aplikacja, jakie wymagania będą mieli klienci, co będziemy musieli zaimplementować, ile obecnych koncepcji będzie musiało ulec zmianie, bo nowe wymagania. Dajmy sobie trochę luzu, takie MVP w kwestii kodowania. Na prawdę, nie musimy wszystkiego mieć by-the-book od razu i dajmy takie samo prawo innym. Nie oceniajmy tylko „a bo nie ma testów, a bo to Laravel, a bo nie jest SOLID”. Ważny jest też kontekst konkretnej aplikacji, a nie sam kod oderwany od niej.

Na zakończenie, drodzy koledzy i koleżanki – pieprzyć warstwy abstrakcji: nie dajmy się zwariować, nie zapominajmy, w kiepskich frameworkach powstało wiele kiepskich aplikacji, które dziwnym trafem działały, działają, a klienci na nich zarabiają i są zadowoleni. Pszypadek? Nie sondzem… 😉

Freelancer, programista php, wiecznie niezadowolony ze swojego kodu. Toleruje frontend, kocha backend, miłośnik integracji :)

Send this to a friend

webmastah.weekly
Cotygodniowa porcja linków ze świata WEBDEV BEZ spamu, TYLKO samo mięcho!
Zobacz poprzednie wydania. Dołącz do 2 tysięcy webdeveloperów!
HTML5, CSS3, JS (React, Angular, Ember, Vue), PHP, SQL