Wstęp

Deweloperzy pracujący nad rozwojem framework’a postawili duży nacisk na to by produkt, który tworzą, był bardziej spójny, dobrze udokumentowany, zwiększający produktywność i szybkość uruchamiania aplikacji. Artykuł opisuje dlaczego i w jaki sposób developerzy chcą zrealizować postawione przez siebie cele. Do pełnego zrozumienia będzie potrzebna podstawowa znajomość pierwszej wersji Zend Framework, wzorców projektowych i PHP 5.3.

Prosty i szybki proces nauki

Pierwszy krok jest najtrudniejszy, to stwierdzenie, dokładnie oddaje najczęściej napotykany problem, przez rozpoczynających przygodę z pierwszą wersją framework’a, programistów. Pomimo dobrej dokumentacji i dopracowania rozdziału „Quick Start”, programista napotyka na dodatkowe problemy związane z rozwojem aplikacji:

• Spójność. Dokumentacja opisuje jak korzystać z poszczególnych komponentów takich jak Zend_Cache, Zend_Translate, Zend_Form, itd. ale brakuje kompletnego przykładu, pokazującego jak połączyć istniejące komponenty, w bardziej złożonej i dynamicznie rozszerzanej o nowe funkcjonalności aplikacji.

• Niekonsekwencja API. Pierwsza wersja framework’a zawiera hepler’y, plugin’y i filtry, niektóre z nich posiadają spójny interfejs a pozostałe już nie. Cześć z nich posiada niejawne metody tworzone poprzez __call(), które trudniej jest znaleźć w kodzie. Część z komponentów pozwala na konfigurację poprzez przekazanie array lub obiektu Zend_Config natomiast pozostałe wyłącznie array. Niektóre komponenty pozwalają na konfigurację camelCaseOption natomiast inne na underscore_separated.

Rozwiązanie, które deweloperzy zaproponowali jako remedium na powyższe problemy można przedstawić w kilku zwięzłych punktach:

• Stworzenie podręcznika demonstrującego kompletny cykl tworzenia aplikacji internetowej w ZF2.

• Udokumentowanie i przedstawienie wszystkich przypadku użycia dla każdego z komponentów

• Ujednolicenie interfejsów w całym obszarze framework’a, które nie tylko ułatwi proces nauki ale także zwiększy produktywność programisty poprzez eliminację dezorientacji wynikającej z niekonsekwencji w API.

• Standaryzacja mechanizmu konfiguracji – stworzenie nowego komponentu, który będzie odpowiedzialny przekazywanie i walidację danych.

• Przygotowanie sandbox ZF2, który umożliwia błyskawiczny start z framework’iem.

Prostota w rozszerzaniu

Główną zaletą Zend Framework jest jego możliwość rozszerzania, przez dewelopera, o nowe komponenty czy funkcjonalności. Jednak mimo tego że w pierwszej wersji framework’a jest to relatywnie proste to istnieje kilka kluczowych przypadków, dla których taka możliwość jest bardzo utrudniona:

1. Wykorzystanie Singleton’ów w wielu miejscach w aplikacji, bardzo komplikuje lub wręcz uniemożliwia rozszerzenie lub podmianę funkcjonalności. Przykładami takich komponentów to Zend_Controller_Front, Zend_Auth, Zend_Session.

2. Częste użycie klas abstrakcyjnych zamiast interfejsów, powoduje rozszerzanie lub podmianę komponentów znacznie trudniejszym. Część z klas abstrakcyjnych jest już bardzo bogata w elementy, które w nowej funkcjonalności nie potrzebujemy, w konsekwencji podmieniony kod posiada dużą ilością zbędnych metod.

3. Twarde zależności uniemożliwiają w wielu miejscach rozdzielenie funkcjonalności  lub jej podmianę na nową. Najlepszym przykładem jest Zend_View, który jest nierozłącznym składnikiem wielu komponentów np.: Zend_Controllerze_Action, Zend_Form przez co próba skorzystania z Smarty lub OPT zamiast standardowego systemu szablonów jest bardzo utrudniona.

4. Brak możliwości rozszerzenia elementów, z których użytkownik mógłby wynieść wiele korzyści. Idealnym przykładem jest Zend_Db, który gdyby oferował możliwość rozszerzania o plugin’y mógłby zaoszczędzić pracy przy tworzeniu struktur drzewiastych, cachowania itp. a dodatkowo kod byłby wielokrotnego użytku.

Podstawowy plan działań jaki został obrany przez deweloperów by rozwiązać powyższe problemy, można streścić w kilku punktach:

• Identyfikacja kluczowych interfejsów dla komponentów i typowanie/żutowanie do nich zamiast do klas abstrakcyjnych.

• Usunięcie singletonów gdzie tylko jest to możliwe, natomiast jeżeli nie jest to możliwe przenieść zachowanie do obiektów współpracujących (collaborating objects)

• Usunięcie twardych zależności na rzecz DI

• Określenie komponentów, które powinny pozwalać na rozszerzalność i współpracę z innymi obiektami.

Poprawiona wydajność

Szybkość działania pierwszej wersji framework’a, zachwycała tylko na początku (do wydania 1.5) a z każdą jego kolejną odsłoną szybkość stopniowo spadała. Developerzy, podejmując pracę nad drugą wersją framework’a, określili sobie za cel poprawę wydajności rzędu 200-300%.

Jako że jest już dostępne do testowania developerskie wydanie ZF2 to można stwierdzić iż separacja zależności i wykorzystanie na szeroką skalę dependency injection oraz lazy load przynosi spodziewane korzyści, ale to nie wszystko. Całkowicie został przebudowana modułowość i MVC. Teraz moduł jest elementem niezależnym od MVC. Moduł może korzystać z MVC i definiować własny bootstrap, routing i konfigurację. W dużych i różnorodnych projektach takie podejście do problemu może mieć ogromny wpływ na poprawę wydajności gdyż moduł będzie ładował tylko to co jest konieczne dla jego prawidłowego działania.

Kolejnym etapem w poprawie wydajności jest pomoc programiście w zdobyciu informacji o dobrych praktykach optymalizacyjnych. Developerzy chcą to osiągnąć poprzez stworzenie odpowiedniego działu w dokumentacji.

Rozwój i utrzymanie

Rosnąca popularność ZF niesie za sobą ogromną ilość zmian i nowych komponentów. Na chwilę obecną projekt składa się z 2 milionów linii kodu w tym 14 tysięcy linii testów jednostkowych. Nad jego rozwojem i spójnością czuwają trzy osoby z zespołu Zend’a i ogromna ilość programistów z całego świata zaangażowana w jego rozwój i tworząca nowe komponenty.

Projekt o takiej skali wymaga odpowiedniego podejścia do rozwoju i utrzymania. Jednym z rozwiązań mającym pomóc w tym zadaniu jest przejście z centralizowanego systemu kontroli wersji na rozproszony system kontroli wersji – GIT – jest on znany developerom, zapewnia możliwość weryfikacji i identyfikowania programistów współpracujących nad kodem, umożliwi łatwe łatanie i łączenie zmian dzięki czemu jest bardziej skutecznym narzędziem w prowadzeniu i utrzymywaniu projektu.

Kolejnym aspektem rozwoju jest integracja z projektami firm trzecich. Do tej pory taka integracja była nie lada wyzwaniem (wprowadzenie Zend_Application uprościło ten proces). Teraz developerzy zamierzają jasno i klarowne określić w jaki sposób biblioteki powinny być integrowane z ZF2 co zapewni dostęp do bardziej wszechstronnych rozwiązań dla użytkownika bez nakładu dodatkowej pracy.

Wzór wykorzystania PHP 5.3

PHP 5.3 wnosi do języka wiele nowości: przestrzenie nazw, funkcje anonimowe, late static binding, goto itd. dlatego jak najbardziej zrozumiałym jest podejście developerów do wykorzystania tego potencjału.

Można wyróżnić następujące etapy, które zostaną uwzględnione podczas re-factoringu kodu źródłowego framework’a:

• Migracja na przestrzenie nazw w celu zniwelowania kolizji w nazewnictwie z bibliotekami firm trzecich jak i kodu prywatnego użytkownika.

• Usunięcie wszystkich wywołań create_funciton() i zastąpienie go funkcjami anonimowymi.

• Identyfikacja kodu, który może skorzystać z nowości w PHP 5.3

Podsumowanie

Pierwsze szkice planu rozwoju drugiej odsłony framework’a jasno wskazywały że będziemy mieli do czynienia z ewolucją ukierunkowaną na wykorzystanie nowych możliwości PHP 5.3, aktualizację dokumentacji, poprawienie wydajności. Jednak z czasem obraz ten nabiera coraz to większej ostrości.Obecnie, mimo że mamy do czynienia jeszcze z wydaniem alpha, to projekt w implementacji jest na tyle rewolucyjny w porównaniu do poprzedniej wersji framework’a że przez moment zastanawiałem się czy nie było by stosownym zmienić jego nazwę. Osobiście podoba mi się kierunek rozwoju i z niecierpliwością czekam na pierwszą betę, która ma zostać wydana pomiędzy 17-20 października podczas trwania ZendCon 2011. Zachęcam wszystkich zainteresowanych programistów PHP do śledzenia projektu na github oraz uczestnictwa grupie dyskusyjnej.

Słownik:

• ZF – Zend Frameork

• DI – Dependency Injection

• MVC – Model View Controller

Linki:

• http://zendcon.com/

• http://framework.zend.com/zf2/blog

• http://framework.zend.com/wiki/display/ZFDEV2/

• https://github.com/zendframework