Mariusz Tarnaski "MariuszT"

Tuż po tym jak zabrałem się za naukę Zend Framework chciałem także sięgnąć po Symfony. Odłożyłem to jednak na później bo o ile o Zend Framework 2 jeszcze niewiele było słychać (i to się na razie nie zmienia) o tyle Symfony 2 rozwijało się już od wielu miesięcy. Wolałem więc poczekać z nauką na stabilną wersję 2.0. I doczekałem się

28 lipca Fabien Potencier, ojciec projektu, wykonał commit do repozytorium Git i tym samym nastał oficjalny początek pierwszej stabilnej wersji Symfony 2. Na nowej stronie projektu możecie przeczytać jak sam opisuje cechy najnowszej wersji swojego frameworka.

Nie programowałem w Symfony 1 więc nie wiem co jest zupełną nowością a co zostało tylko poprawione i w jakim stopniu. Jest jednak kilka rzeczy przez które mam wielkie nadzieje co do tego oprogramowania. Oto one:

• Symfony 2 składa się z (powiązanych ze sobą ale jednak oddzielnych) pakietów. Nawet jeżeli nie programujesz w Symfony to możesz wykorzystać konkretne moduły w swoich aplikacjach. Przypomina mi to ideę Zend Framework i bardzo mi się to podoba.
• Aby móc korzystać z nowego frameworka potrzebne jest PHP w wersji co najmniej 5.3.2. Mam nadzieję, że to wymusi na dostawcach hostingu szybsze wprowadzenie na swoje serwery PHP 5.3. Wydano je 30 czerwca 2009 roku a do tej pory znaczna część hostingodawców (większość?) jej nie udostępnia! Dzięki nowemu Symfony wreszcie mam pretekst aby dobrze poznać przestrzenie nazw.
• Kod naszej aplikacji w Symfony 2 może dzielić się na pakiety (bundles). To bardzo ekscytująca nowość. W skład takiego pakietu może wchodzić kod PHP, HTML, JavaScipt, pliki graficzne itd. czyli wszystko czego potrzebujemy do uruchomienia samodzielnego elementu naszej strony np. forum, blog czy system newsów. Przypomina mi to trochę moduły/pluginy z CMS’ów ale pisane wreszcie na podstawie dojrzałego oprogramowania i według jasnych, przejrzystych zasad. Ułatwi to również pracę w zespole nad dużymi projektami. Zobaczymy jak to się sprawdza w praktyce

To trzy główne nowości, które dla mnie są najważniejsze. Na tym oczywiście nie koniec ale tu odnoszę już do strony projektu i krótkiego wprowadzenia do nowego Symfony. Osoby zaznajomione z poprzednią wersją frameworka powinny również zainteresować się artykułem o różnicach między wersjami.

Kończę bo czeka na mnie jeszcze gorąca, nowa instalacja Symfony 2 Swój najnowszy projekt chcę oprzeć właśnie o ten framework.

PS
Jeżeli chcesz zacząć zabawę z Symfony 2 to zalecam pobrać paczkę .zip a nie .tgz. Z jakiegoś niewyjaśnionego powodu paczka .tgz ma błędy.. Wszystko się normalnie rozpakowuje ale parser PHP sypie błędami, pliki z kodem mają czasami rozszerzenie .ph zamiast .php i cholera wie co jeszcze tam jest nie tak Co jeszcze dziwniejsze, ten problem pojawia się nie pierwszy raz. Tak samo bywało z poprzednimi wersjami RC, beta itd. Takie rzeczy nie powinny mieć miejsca…

Jak już nie raz pisałem, PHP jest krytykowane za to, że daje zbyt dużą swobodę programiście podczas tworzenia kodu. Jest w tym trochę prawdy aczkolwiek to długi i skomplikowany temat. Nie mam ambicji aby proponować tu rozwiązania w samym języku. Chcę poruszyć bardziej trywialny ale mimo to ważny problem jakim jest brak oficjalnych zaleceń co do formatowania kodu, nazewnictwa funkcji, klas etc. Społeczność PHP przez tyle lat nie dorobiła się spójnych standardów, które byłyby przestrzegane i promowane chociażby przez wszystkich liczących się graczy.

Całkiem nieźle pamiętam czasy gdy większość programistów praktycznie wcale nie formatowała swojego kodu. Szczególnie olewano wcięcia. Nie było też żadnych zaleceń co do struktury katalogów i plików, nazewnictwa klas, funkcji, metod. Samowolka.

Prowadziło to do odruchów wymiotnych gdy los skazywał nas na pracę z kodem takiego niechlujnego programisty. Z czasem pojawiały się pierwsze propozycje takie jak wstawianie tu i ówdzie spacji dla większej czytelności kodu czy zasada „jedna klasa = jeden plik”. Oczywiście to tylko przykłady, było tego więcej ale nawet dobrzy programiści stosowali te zasady wybiórczo. Frameworki przyniosły kolejną poprawę, przynajmniej w obrębie pojedynczych społeczności zrzeszonych wokół danego projektu.

Ten artykuł nie jest po to aby opisywać historię lub tworzyć/proponować nowe standardy. Jest po to aby zachęcić Cię do wybrania jednego, spójnego standardu i stosowania go. Jeżeli podchodzisz ambitnie do tego co robisz to nie masz innego wyjścia – musisz zostać programistycznym pedantem

Na pierwszy ogień idzie automatyczne ładowanie klas. Przez długie lata programista musiał sam dbać o to aby kod klasy był dostępny gdy chcemy utworzyć nowy obiekt. Ładował więc wszystkie klasy nawet gdy tylko część była używana lub przy każdym stworzeniu obiektu dołączał kod za pomocą include_once/require_once. Metody mało wydajne i kłopotliwe dla programisty. W PHP 5.1.2 nastąpił przełom, pojawiły się funkcje spl_autoload*. Jeżeli pierwszy raz o nich słyszysz to zapraszam do dokumentacji i google. W tym artykule istotniejsze od działania tego mechanizmu jest to, że społeczność PHP chyba po raz pierwszy postanowiła wspólnie wypracować jakiś standard. Owocem tych prac jest PSR-0. Standard ten odpowiada na wszystkie ważne pytania dotyczące automatycznego ładowania klas np. jak tłumaczyć nazwę klasy na ścieżkę do pliku czy gdzie w tym wszystkim jest miejsce na przestrzenie nazw wprowadzone w PHP 5.3. Standard ten zgodziły się promować takie marki jak Zend Framework czy Symfony (zresztą sami uczestniczyli w tworzeniu tego standardu) i powstało oczekiwanie w świecie PHP, że każdy poważny programista będzie się stosował do tych wskazówek. To daje wspaniałe możliwości, programiści rozumieją się bez słów a różne projekty można ze sobą w prosty sposób integrować.

Niestety w sprawie konkretnych rozwiązań programistycznych lista półoficjalnych (bo PSR-0 oficjalne chyba nie jest aczkolwiek ma błogosławieństwo od Zend) się kończy. Oczywiście istnieją powszechnie znane wskazówki ale dotyczą one raczej bardzo konkretnych fragmentów kodu i najczęściej są omawiane w pierwszych rozdziałach kursów PHP dla początkujących. Na końcu należy wspomnieć o pozytywnej modzie na używanie wzorców projektowych ale to bardzo obszerny temat i mogę w tej chwili napisać tylko tyle, że dobrze, że są I warto je stosować. Trzeba je stosować!

Osobna sprawa to formatowanie kodu. Przyznam, że temat bardzo mnie męczy bo co kod, co programista to trochę inne zasady (albo co gorsza, brak zasad). Ratunkiem są tu wcześniej wspomniane frameworki, które z dnia na dzień coraz bardziej lubię (o czym chciałbym wkrótce napisać). Zawierają one w swoich dokumentacjach standardy kodowania, które często są gotową ściągawką jak programować aby czytanie kodu było przyjemniejsze.

Jako świeżo upieczony programista Zend Framework stosuję się do stylu przez nich polecanego. Dokument jest tutaj a polska wersja tutaj. Wcześniej stosowałem się do standardów Drupala. Polecam również standardy Kohany i Symfony.

W dużej części są one ze sobą zbieżne, czasami różnią się szczegółami (Wcięcia na dwie czy cztery spacje? Ja wolę dwie ale ZF nakazuje cztery, jakoś przeboleję ). Nie jest tak bardzo istotne który standard wybierzesz (przeczytaj wszystkie), bylebyś wybrał jakikolwiek. Chodzi bardziej o ucywilizowanie programisty Gdy się przekona, że przestrzeganie tych zasad jest warte zachodu to zmiana drobnych szczegółów aby go „dopasować” do nowego projektu, nowego zespołu programistów będzie już łatwiejsza.

Stosujcie standardy!

EDIT
Polecam wpis Zyxa Propozycja zasad dobrego projektowania. Tomek opracował dokument, który w jednym miejscu zbiera zasady dobrego programowania w PHP. Lektura obowiązkowa! Nie każę Ci się bezwzględnie stosować do jego rad ale to na pewno skłoni Cię do przemyśleń. Myślenie jest dobre!