Wykorzystanie PHP bez frameworka?

To nie jest tyrada anty-frameworkowa…

Uwaga! To nie jest tyrada anty-frameworkowa ani tym bardziej promowanie nieszablonowego myślenia. Dla wielu czytelników bloga temat jest z pewnością znany. Na czacie Stack Overflow PHP można odnaleźć wielu developerów pytających czy framework X jest dobry, czy może Y lepszy… W większości przypadków odpowiedź brzmiała, że powinni używać PHP, a nie architektury do budowania aplikacji.

W niniejszym wpisie chciałbym zachęcić Ciebie, szanowny czytelniku, abyś dał sobie szansę na rozwój jako programista. W większości przypadków struktura aplikacji jest tak rozbudowana, że często traci swój sens. Natomiast pisanie aplikacji od zera przy pomocy open-sourcowych pakietów jest znacznie łatwiejsze, niż niektórzy myślą. Pod niektórymi względami wykorzystanie zaawansowanych frameworków jest dobre, niemniej cała nadreprezentacja obiektów jest przytłaczająca i może przeciwdziałać jego intencjom i stać się znaczącym drenażem wydajności. Dawno temu skupialiśmy się na ważnych rzeczach, czyli rozwiązywaniu problemów i logice biznesowej. Dzisiaj jesteśmy prawie całkowicie skoncentrowani na abstrakcji i generalizacji. Podczas gdy ważne obiektywnie rzeczy, które opłacają rachunki, otrzymują tylko resztki czasu, jeśli w ogóle takowe pozostają. Zwykle spędzaliśmy 90% czasu, decydując o właściwym gwoździu do użycia, odpowiednim drewnie, na którym go używamy, i gdzie najlepiej go umieścić, i tylko 10% naszego czasu na dobór i posługiwanie się młotkiem. Teraz spędzamy 90% czasu zastanawiając się, który FactoryAbstractManagerFactoryGenericInterfaceTool wywołać i jak poprawnie go użyć w taki sposób, aby zmusić go do ostatecznego wygenerowania czegoś, co ostatecznie może wygenerować coś innego i utrzyma całość razem. Zmusza to również pozostałych członków zespołu deweloperskiego do intensywnego debugu, dlaczego niniejszy obiekt został użyty, w jakim celu oraz co będzie efektem jego użycia.

Czy przesadzam? Możliwe, że odrobinę… programiści uchodzą za inteligentnych ludzi. Ustalają jak wykorzystać złożone kombinacje systemów do budowania funkcjonalnych, monstrualnych i monolitycznych aplikacji. Ale czy naprawdę redukujemy dług techniczny? Czy w rzeczywistości go dodajemy? Czy te systemy naprawdę będą łatwiejsze do utrzymania w ciągu kilku lat, gdy będą mieć kilkaset zależności, z których każda ewoluowała w czasie lub co gorsza została porzucona? Czy łatwiej przyjdzie zoptymalizować kod, kiedy oznacza to modyfikację tego, co dzieje się pod maską każdej z tych zależności? Czy łatwiej będzie je rozszerzyć, prowadząc do konfliktów z tymi zależnościami?

W związku z powyższym problemem może okazać się, że kolejna fala odkryć i szumu w tej dziedzinie skupi się na poprawie produktywności przy jednoczesnym zmniejszeniu zadłużenia technicznego poprzez usunięcie narzędzi, które teraz budujemy (lub wykorzystujemy) i zastąpienie ich czymś prostszym i bardziej precyzyjnym.

Być może największą korzyścią z pracy bez ram frameworka jest bogactwo wiedzy o tym, co dzieje się pod maską. Widać dokładnie, co się dzieje, bez polegania na jego magii, aby zająć się rzeczami w taki sposób, żeby nie było potrzeby debugować kodu i naprawdę go zrozumieć.

Niestety ramy niniejszego wpisu nie pozwalają mi przedstawić przykładu aplikacji bez frameworka, niemniej posłużę się garścią informacji, które najprawdopodobniej wszyscy developerzy znają, ale niestety zdążyły umknąć. PHP już od wersji 5 zawiera wiele struktur, których szukamy w zewnętrznych bibliotekach, a które są dostępne w ramach standardowego rozszerzenia:

Podsumowanie

Reasumując, framework stara się zaoszczędzić pracę, poprzez zdefiniowanie kompleksowej i czasochłonnej konfiguracji, która musi uwzględniać wszystkie możliwe przypadki użycia. To deklaratywne podejście do budowania aplikacji nie zawsze jest lepsze niż programowe, gdzie ręcznie tworzy się kolejne zależności obiektów. Czy jest to powód, by porzucić framework? Tylko wtedy, gdy już wiesz, że twoja aplikacja nie będzie potrzebować tak złożonej architektury. Inspiracją do stworzenia tego wpisu była książka: https://github.com/PatrickLouys/no-framework-tutorial

Autorem tekstu jest Marek Rode.

Dodaj komentarz

avatar
  Subscribe  
Powiadom o
Marcin
Gość
Marcin

„Dawno temu skupialiśmy się na ważnych rzeczach, czyli rozwiązywaniu problemów i logice biznesowej. Dzisiaj jesteśmy prawie całkowicie skoncentrowani na abstrakcji i generalizacji.” – i to wszystko wina frameworków? Czy to wina cegieł i zaprawy że murarze krzywo wybudowali mur, czy jednak problemem było nieprofesjonalne podejście fachowców, którzy ubzdryngoleni przyszli do pracy? Nie możemy zrzucać winy na narzędzia, za to że źle tworzymy aplikacje. Powinniśmy raczej starać się dostrzec fakt, że problem leży w nas samych i spróbować go zrozumieć… oraz coś z nim zrobić. I na pewno nie jest metodą na ów problem podejście, że „powinniśmy używać PHP, a nie… Czytaj więcej »

Zobacz również artykuły o podobnej tematyce

Kolejna marka VRG uruchamia rozwiązanie e-commerce od i-systems

Nowa marka pojawiła się w portfolio giełdowej grupy: PICKY PICA, bo o niej mowa, stawiając pierwsze kroki w e-commerce, zdecydowała...

Konteksty i ich wpływ na rozwój oprogramowania

W branży IT niezmiernie ważnym obszarem jest development. Angielskie słowo “develop”, w dosłownym tłumaczeniu oznacza rozwijać i to właśnie ten...

7 trafnych decyzji, czyli sukces w omnichannel

Omnichannel, to niejako dalszy krok w rozwoju firmy. To naturalna transformacja koncepcji multichannel, idea gwarantująca spójność doświadczeń we wszystkich kanałach,...

Zobacz więcej wpisów