Jak wygląda kod-spaghetti, wiemy wszyscy. Jest on tworzony bardzo często przez programistów, którzy swoją naukę zakończyli wraz z nauką języka programowania. Próbują oni odkrywać koło na nowo, osiągając coraz to nowsze pokłady nieporządku i niezrozumienia. Dla wszystkich tych, którzy właśnie przeczytali coś o sobie, jest właśnie ten wpis.
Czy i kiedy potrzebujemy standardów?
Standardem nazywamy zbiór reguł respektowanych oraz stosowanych wśród ludzi zgromadzonych wokół konkretnego zagadnienia. W środowisku budowlanym mamy np. standardy metryczne, konstrukcyjne jak i wykończeniowe. Gdyby nie one, to mieszkalibyśmy w sypiących się ruderach z krzywymi ścianami.
Ze standardami jest tak, iż na ogół są one potrzebne. Dobrze jest mieć w projekcie jednakowo sformatowany kod w każdym pliku. Fajnie jest, kiedy mamy jasne reguły autoloadingu – łatwiej nam wtedy lokalizować klasy w drzewku projektowym. Sztos, kiedy nazwy klas i metod odzwierciedlają swoje odpowiedzialności. Dlatego właśnie dobrze jest korzystać ze standardów.
Ze standardami jest również tak, iż jak jest zbyt wiele dotyczących tej samej materii, to wtedy tracimy to coś, co one ze sobą wnoszą. Im więcej standardów w danej dziedzinie, tym mniej ludzi, którzy z niego korzystają. Dlatego zamiast na siłę tworzyć nowy, wspaniały standard – lepiej jest skorzystać z tych już istniejących (rysunek poglądowy poniżej )
Do gry wchodzi PSR
Pewnego dnia, w 2009 roku, na jednej z konferencji z tematyki PHP, organizowanej przez tek conference, spotkało się kilku przedstawicieli topowych frameworków. Założyli oni organizację PHP-FIG (eng. Framework Interoperability Group). Grupa ta miała na celu interoperacyjność pomiędzy twórcami popularnych frameworków.
Niestety, nie jest mi pisane poznać, na czym ta interoperacyjność miała (oraz w tej chwili ma) polegać. Jako osoba „z zewnątrz” mogłem jedynie zaobserwować, iż co jakiś czas pojawiały się nowe propozycje standaryzacyjne nazywane PSR (eng. PHP Standard Recommendation). o ile połączyć to z formą głosowania nad propozycjami, to wychodzi nam, iż wszyscy członkowie organizacji prawdopodobnie zgodzili się na dostosowanie swoich produktów do przegłosowanych rekomendacji (poruszone w dalszej części wpisu).
Must-have programistyczny, czyli PSR-1 i PSR-4
Z perspektywy programisty mogę powiedzieć, iż PHP-FIG zrobiło dobrą robotę, wprowadzając standardy PSR-1 (formatowanie kodu) oraz PSR-4 (autoloading).
Co do formatowania kodu, chyba każdy przez to przechodzi. Klamry w nowych linijkach, czy na końcu? Spacja między nawiasem a klamrą? No i chyba klasyka: camelCase czy snake_case? Od momentu wydania (oraz co ważniejsze – rozpropagowania) PSR-1 nie powinniśmy dłużej się nad tym zastanawiać. Nie twierdzę, iż to, co zaproponował PHP-FIG, jest formatowaniem idealnym. Każdy ma swoje gusta. Najważniejsze w tym wszystkim jest to, iż reprezentanci społeczności PHP zdecydowali, a następnie dając przykład – wdrożyli. Dodatkowym plusem dla PSR-1 jest to, iż mogły powstać narzędzia pilnujące formatowania za nas. Przykładem jest mój ulubiony ECS, który wspiera PSR-12 (który jest odpowiednikiem PSR-1 na wypasie).
Drugim (bardzo krótkim, ale istotnym) standardem jest PSR-4, który mówi o tym, w jaki sposób układać nazwy klas oraz namespace w stosunku do katalogowania. To dzięki temu dokumentowi mógł powstać Composer w formie, którą znamy dzisiaj. Dzięki temu dokumentowi mamy również korelację pomiędzy katalogami, nazwami plików, namespacami oraz nazwami klas. Czyli patrząc na drzewko plików w IDE wiemy, w jaki sposób dostać się do klasy, której poszukujemy.
Proste standardy, które są fundamentem dobrej architektury
PHP-FIG wydało również kilka dokumentów funkcjonalnościowych, których znajomość poleciłbym wszystkim czytającym ten wpis. Mowa o:
- PSR-3 – Logger Interface
- PSR-6 – Caching Interface
- PSR-11 – Container Interface
- PSR-14 – Event Dispatcher
- PSR-18 – HTTP Client
To, co mi się bardzo w nich podoba, to bardzo precyzyjne podejście do definicji domen funkcjonalności, o których piszą. Bo nie każdy, kto robi cache w aplikacji, musi zadać sobie pytanie – co z wygasaniem? Nie każdy, kto używa swojego customowego logera, musi wpaść na pomysł definiowania różnych kanałów pochodzenia logów. Ale (mam nadzieję) każdy, kto zapozna się z tymi dokumentami pozna wszystkie podstawowe elementy zagadnienia związane z logowaniem, cache, kontenerem zależności itd. I dlatego właśnie, moim zdaniem, powinniśmy propagować te dokumenty.
Nadchodzi rok 2017 i wielki rozłam w PHP-FIG
Jakiś czas temu firma Jetbrains wydała bardzo fajną stronkę z podsumowaniem 25 lat istnienia języka PHP. Przeglądając sobie tą stronę zauważyłem jeden interesujący punkt:
May 15: Laravel, Propel, Doctrine, The PHP League, and Guzzle resign from PHP-FIG
Zaintrygowało mnie bardzo, dlaczego największe frameworki wyszły z organizacji, i to tak… jednogłośnie? Znalazłem w sieci artykuł, który odnosił się do wpisów na twitterze trzech core-team developerów Symfony (w tym twórcy, Fabiena Potencier-a). Każdy z nich odnosił się do tego, iż nowo wprowadzone standardy nie mogą zostać zaimplementowane w wyżej wymienionych, co równa się z ich wyjściem z organizacji PHP-FIG.
Czy w tej chwili warto jest stosować standardy PSR?
Odejście dużych graczy nie oznacza, iż wprowadzane standardy są złe. Bardziej może to znaczyć, iż produkty, jakimi są Symfony, Laravel czy Doctrine nie są w stanie z powodów biznesowych, bądź choćby architektonicznych, kontynuować pełnego wsparcia dla standardów PSR. Standardy same w sobie spełniają dalej swoją rolę.
Moim zdaniem, standardy z rodziny PSR są bardzo udanym projektem, który zrewolucjonizował w dużym stopniu community PHP. Uważam, iż stanowczo warto wdrażać je wszędzie tam, gdzie możemy (nie oznacza to pchania na siłę). Zmniejszymy dzięki temu próg wejścia w projekt oraz zwiększymy szansę na poprawną i sprawną integrację naszego kodu z zewnętrznymi paczkami.
