Po co nam standardy?

Przez pryzmat ostatnich rozmów rekrutacyjnych, oraz architektury kilku projektów jakie analizowałem, dochodzę do wniosku, że spora część „programistów” nie tylko nie widzi sensu, co nie nie ma pojęcia o istnieniu pewnych standardów w świecie PHP.
Dzisiaj chciałbym przybliżyć kilka pojęć, kilka z naciskiem na OOP.

PHP Framework Interop Group (PHP-FIG)

Moim zdaniem w tym momencie znajomość PSR-0 do PSR-4 to podstawa. Projekt PHP-FIG zawiązał się w 2012 roku (3 lata temu). Przy „jednym stole” zasiadł m.in. Matthew Weier O’Phinney reprezentujący ZF2, Fabien Potencier z Symfony2, jak również Jordi Boggiano odpowiedzialny za Composer i Packagist. Pomysł był prosty – każdy zespół podchodził inaczej do tematu autoloadera (PSR-0), jak również pojawiały się różne wariacje coding style (PSR-1 i PSR-2).
Później powstał standard związany z interfejsem dla Loggera (PSR-3, dla niektórych dyskusyjne, dla mnie ok) oraz udoskonalona koncepcja autoloadera (PSR-4). A reszta już poszła lawinowo, zespół poniosła fantazja.

Reguła KISS

KISS to skrót od Keep It Simple, Stupid. Nie komplikuj kodu, pisz przejrzysty kod bez zbędnych dodatków. Dojdzie nowy programista do projektu, lub ktoś przejmie projekt? Taka osoba powinna móc szybko się wdrożyć, zrozumieć kod bez czytania obszernej dokumentacji i wprowadzić potencjalne poprawki.
Pamiętaj – twórz i utrzymuj taki kod, żeby każdy mógł go zrozumieć i nie musiał posiadać doktoratu w tej dziedzinie.

Zasada DRY

DRY to skrót od Don’t Repeat Yourself. Krótko: nie powtarzaj się. Widzisz podobne elementy kodu? Wydziel je, ustandaryzuj. Podczas deploy’u robisz zawsze te same czynności ręcznie? Zautomatyzuj to. Zaczynasz kolejny projekt? Z poprzedniego wydziel wspólną bibliotekę/bundle/etc.

Zasada YAGNI

YAGNI to skrót od You Aren’t Gonna Need It. Nie potrzebujesz czegoś tu i teraz, ani w następnej iteracji? Nie rób tego, nie twórz kodu na wyrost bo kiedyś wykorzystasz jakiś interfejs, albo cały mechanizm do tworzenia uniwersalnych walidatorów.
Większa ilość kodu zwiększa prawdopodobieństwo wystąpienia błędów oraz skomplikowanie kodu. Ta zasada po części wiąże się z KISS – wybieraj najprostszą drogę do celu, która daje zwiększoną niezawodność zaimplementowanych algorytmów.

Wzorce projektowe

Jest to chyba jedyny element programowania obiektowego, który został opanowany, a raczej wykuty przez programistów. Większość osób jest w stanie wymienić 3 wzorce i je opisać. Gorzej z wytłumaczeniem własnymi słowami do czego tak naprawdę dany wzorzec służy.
Moim zdaniem lepiej nie znać na blachę kilku pojęć z PHP, niż mieć problem ze zrozumieniem podstaw. Przy okazji przypomnijmy sobie czym jest OOP – podstawowe założenia paradygmatu obiektowego:

  • Abstrakcja
  • Hermetyzacja
  • Polimorfizm
  • Dziedziczenie

SOLID

Same wzorce projektowe, czy tworzenie klas i ich ciał nie świadczą o tym, że programuje się już obiektowo. Możemy mieć masę klas, zależności itp. A kod nadal jest proceduralny, bo ciągle zapominamy o OOP.
W tym przypadku pomoże nam zastosowanie 5 założeń nazwanych w skrócie SOLID.

GRASP

Jakby równolegle obok zasad projektowania obiektowego SOLID, są zasady GRASP (General Responsibility Assignment Software Patterns).

W dużym uproszczeniu w GRASP chodzi o opisanie podstawowych zasad, którymi będziemy kierować się podczas tworzenia całego projektu, gdzie wszystko kręci się wokół metodycznego podejścia do fundamentów OOP.
GRASP składa się z 9 zasad: Creator, Information Expert, Controller, Low Coupling, High Cohesion, Polymorphism, Indirection, Pure Fabrication, Protected Variations.
Małe wprowadzenie do GRASP znajdziecie w grwykładzie Wiktora Zychla.

Konferencje

Tak wiem, konferencje != stanardy, przynajmniej teoretycznie. Jeśli znasz powyższe reguły, przeczytałeś wiele mądrych książek oraz masz za sobą kilka projektów… Pamiętaj nie stój w miejscu, świat dookoła się zmienia, tak samo zmienia się IT.
Powstają nowe frameworki, biblioteki, narzędzia, inni programiści natrafiają na inne problemy. Warto pojechać chociażby na PHPCon (niedługo pojawią się informacje o tegorocznej edycji), czy również pójść na spotkanie lokalnej społeczności (PHPers).

Jeśli chodzi o PHP i potencjalne szukanie pracy. Pamiętajcie, że dzisiaj ten język programowania to coś więcej nić echo „Hello world”, a wokół samego języka powstało sporo narzędzi wspierajacych rozwój oprogramowania i również warto je znać.

  • Marek

    Znam te problemy, kiedyś też babrałem się w tym języku. No i co ciekawe spora część tych problemów jest związana tylko z tym językiem. Ten język u samych podstaw jest źle zaprojektowany i dlatego wychodzą potem takie gówniane projekty i takie masowe gówno.

    Zobacz jak się robi projekty w „go”. Patrząc po tym co napisałeś artykule chyba już dorosłeś do porzucenia php :p Cóż, to jest zmiana którą można porównać do przesiadki z maluszka do ferrari 😉

  • Hm. Każdy język ma swoje plusy i minusy.
    Większość pozycji z powyższej listy (poza PSR*) jest uniwersalna. Równie dobrze można napisać kiepski kod w Javie, nie tylko w PHP 😉

  • aPoCoMiLogin

    Albo w C jak ostatnio udowodniły wybory 😉 język to tylko narzędzie, a odpowiednia standaryzacja jest potrzebna, nawet jeżeli w dokumentacji języka jej nie ma. Osobiście nie potrafię zrozumieć czemu niektórzy tak bardzo stronią od PSR i nie jestem przekonany czy twój wpis to zmieni.. Niestety.

  • Marek

    Zasadniczy problem phpa to brak porządnych modułów. Bez tego język nie powstaną porządne biblioteki.
    Żaden standard się nie przyjmie, jeśli język nie wymusi tego standardu. Mylę się ? 🙂 W wymuszaniu bardzo pomocne jest statyczne typowanie którego php nie ma …

  • Nie do końca – jednak trochę ciężej jest napisać kiepski kod w Javie czy w Pythonie, bo te języki po pierwsze mają wyższą barierę wejścia, a po drugie mają mocno ukorzenione we wszelkich kursach czy w dokumentacji, czy nawet w strukturze języka dobre standardy. Pisząc w Pythonie szybko zauważa się, że o wiele łatwiej jest pisać kod, który jest przejrzysty i zgodny z praktykami, niż brzydki (który oczywiście też da się pisać).

  • aPoCoMiLogin

    Czyli mówisz że symfony, czy ogólnie pakiety composera, to nie są porządne liby ?

    Javascript nie wymusza żadnego statycznego typowania, a zobacz ile zajebistych libów w javascripcie powstało. To nie jest reguła, że jak język jest zajebisty, to zajebiste będą też liby. Wszystko zależy od przystępności języka i jego wymagań.

  • Witam kolegę 🙂