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:

• filter_input_array (http://php.net/manual/en/function.filter-input-array.php) do deklaratywnego filtrowania danych przychodzących z requestów
• wykorzystanie dostępu do bazy danych poprzez obiekt PDO ze sparametryzowanym SQL, aby zapobiec atakom SQL injection
• ustawienia php.ini, które sprawią, że nasza witryna będzie bardziej odporna na podmianę sesji oraz kradzież ciasteczek:
  – session.use_only_cookies: 0/1 zapobiega wyciekaniu sesji to URLa: http://ca.php.net/manual/en/session.configuration.php#ini.session.use-only-cookies
  – session.cookie_httponly: 0/1 zapobiega przed skryptami odczytującymi plik cookie z przeglądarki: http://ca.php.net/manual/en/session.configuration.php#ini.session.cookie-httponly
  – wykorzystanie atrybuty httponly w funkcji setcookie
  – dalsze ciekawe przykłady można znaleźć na stronie:
  https://en.wikipedia.org/wiki/Session_fixation
• ciekawy i prosty silnik temlatek: https://arshaw.com/phpti/ dysponujący najważniejszymi możliwościami największych bibliotek do renderowania widoków
• biblioteka pearl do zarządzania routingiem: https://pear.php.net/manual/en/package.networking.net-url-mapper.example.php

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.