Wytwarzanie  softu do Magento w postaci osobnych modułów niesie za sobą kilka zalet. Przede wszystkim stwarza to możliwość wykorzystania go w innym projekcie. Czy jednak będziemy mogli to zrobić z sukcesem? Czy jak damy go koledze, to po pięciu minutach nie wróci do nas mówiąc: “Słuchaj, coś mi nie działa” –  To zależy tylko i wyłącznie od nas. Chciałbym przedstawić kilka porad, które być może znacie, być może nie, a którymi to warto się kierować tworząc własny re-użyteczny moduł do Magento.

1. Nie przypisujmy na sztywno wartości w kodzie, które mogą w przyszłości ulec zmianie (tzw. hardkodowanie).

Takie wartości mają to do siebie, że po jakimś czasie programiści mają problemy z przypomnieniem sobie co ona oznaczała. Jeśli już zakładamy, że pewne parametry będą niezmienne, twórzmy stałe w obrębie klasy modelu. Dzięki takiemu posunięciu przy zmianie parametru wystarczy, że zmienimy tą wartość w definicji stałej, a wszystkie odwołania do niej dalej będą działały. Najlepszym rozwiązaniem jednak będzie umożliwianie definiowania wartości danego parametru w konfiguracji systemowej w panelu administratora. Dzięki temu możemy później, bez zmian w kodzie, przystosować moduł do działania na innym systemie. By jednak uniknąć błędów spowodowanych brakiem zdefiniowanej wartości (np. zaraz po deployu na serwerze producyjnym) definiujmy zawsze domyślne wartości dla tych pól. Magento daje nam taką możliwość za pośrednictwem sekcji default w plikach konfiguracyjnych modułów. Oto przykładowy xml definiujący domyślną wartość dla pola  definiującego czas przez jaki produkt jest traktowany jako nowo dodany. Pole to znajduje się w konfiguracji w sekcji katalog, w “bloku” “sklep od strony klienta”.
re-użyteczny moduł Magento

2. Nie korzystajmy z innych customowych modułów w swoim kodzie.

Może zdarzyć się sytuacja, w której w jednym projekcie mamy zainstalowany ekstra moduł kupiony za spore pieniądze. Pisząc kod, wykorzystujemy go często, bo po pierwsze jest to łatwe, a po drugie na pewno będzie  to działać. Pamiętajmy jednak, że w drugim projekcie on wcale nie musi występować. Takie zacieśnianie zależności może przekreślić już na starcie karierę naszego pluginu. Oczywiście możemy wykorzystywać moduły corowe, ponieważ na pewno  znajdą się w każdym projekcie bazującym na tej samej wersji Magento. Każdy moduł można wyłączyć dlatego pamiętamy o tzw “dependencies” w plikach konfiguracyjnych modułów.

3. Nazewnictwo – każda metoda powinna być czasownikiem i określać czynność jaką wykonuje.

Nie przesadzajmy jednak z długością nazw . Unikajmy też nazywania zmiennych jakimiś krótkimi nazwami takimi jak ‘$ret’,’$ob’ czy ‘$a’, nad których znaczeniem ktoś inny, nie znający naszych zwyczajów, będzie się zastanawiał. W silnie typowanych językach programowania jest o tyle łatwiej, że przynajmniej wiemy jakiego typu jest dana zmienna, ale w już php  bez debugowania lub “wyrzucania” zmiennych na ekran przeglądarki się nie obejdzie. Warto jednak zauważyć, że deklarowanie typów zmiennych jest w php jak najbardziej możliwe, jednak mało kto to robi, gdyż on sam od nas tego nie wymaga. Pamiętajmy też, że  w dobie globalizacjii wiodącym językiem na świecie jest angielski,  także starajmy się używać tego języka.

4. Nie stosujmy skomplikowanej składni.

Na pewnym etapie kodowania lub jak inni zwykli mówić “kodzenia” zawsze nadejdzie ten moment, kiedy musimy zadecydować czy wykonać operacje A czy B. Nie da się w nieskończoność przenosić ciężaru podejmowania decyzji na inną metodę. W takich sytuacjach zawsze powinniśmy mieć na uwadze to, by nie konstruować olbrzymich, zagnieżdżonych kilkakrotnie w sobie instrukcji warunkowych. Jeśli nasz mechanizm decyzyjny zaczyna w podejrzany sposób się rozrastać,to prawdopodobnie można taki kod refaktoryzować. Nie warto pozostawiać u siebie takiego ‚spaghetti’ kodu, bo bardzo prawdopodobne, że gdy za kilka miesięcy, kiedy będziemy coś w nim zmieniali, zadamy sobie pytanie: “Czy ja na prawdę to napisałem? O Co mogło mi wtedy chodzić” . Przyjmijmy też konwencje kodowania i twardo się jej trzymajmy. Zarówno Zend jak i Magento udostępniają poradniki dotyczące przyjętych standardów zapisu.

5. Jeśli jednak, z jakiegoś powodu jesteśmy zmuszeni tworzyć pokrętną logikę lub innego rodzaju hacki, twórzmy komentarze do kodu.

Komentarz przeznaczony jest zarówno dla Ciebie, jak i dla kogoś, kto będzie później pracował z tym kodem, więc używanie jakichkolwiek skrótów myślowych może prowadzić do zguby. Tak samo jak w przypadku nazewnictwa zmiennych i metod jeśli tylko potrafimy zachować sens wypowiedzi, korzystajmy z języka angielskiego.

6. Stosujmy się do wzorca MVC.

Nie będę przytaczał jego definicji, ponieważ każdy, kto pracuje w Magento go zna i wie również, że magentowe MVC trochę różni się od standardowego. Mianowicie oprócz widoków, modelów, kontrolerów i helperów mamy również  bloki, które wraz z layoutem i szablonami składają się na warstwę widoku aplikacji. Tak więc V w Magento posiada własne, małe MVC. Często możemy zadać pytanie: Jaka logika powinna znaleźć się w bloku? Generalnie rzecz biorąc blok przejmuje część obowiązków modelu, czyli to on powinien pobierać dane, odpowiednio przygotować, jeśli jest taka potrzeba i wystawiać je do szablonu. Również  w blokach tak samo jak w helperach  możemy umieszczać metody aliasy, które nie zajmują się niczym innym niż wywołaniem innej metody, ale dzięki temu, że opakowują skomplikowaną składnie w elegancki sposób, sprawiają, że używanie ich w szablonach wpływa pozytywnie na czytelność kodu.

7. Nie korzystajmy z short tagów w szablonach PHTML.

Jeśli nawet twórcy PHP sugerują by tego nie robić to już wiedz, że coś się dzieje… ;). Short tagi mają zostać usunięte w kolejnych wersjach PHP tak więc wnioski nasuwają się same.

8. Poddawajmy walidacji dane jakie możemy przyjąć od użytkownika.

Musimy zawsze zdawać sobie sprawę z tego, że nie każdy użytkownik ma dobre zamiary i czasami zamiast grzecznie wypełnić formularz, poda nam kawałek kodu, który może nieźle namieszać nam w bazie danych jeśli się odpowiednio nie zabezpieczymy. Gdzie więc powinna znajdować się walidacja danych? – W modelu. Magento posiada biblioteki z Zenda wykorzystywane przy walidowaniu danych, które świetnie się nadają do tego typu zadań.

9. Nie korzystajmy z mechanizmu rewrite Magento.

Pewne klasy często wymagają dodania przez nas dodatkowej logiki. W takim wypadku prawdopodobnie skorzystamy z mechanizmu rewrite i nadpiszemy bazową klasę własną. Co jednak w przypadku w projekcie znajdzie się inny moduł, który również nadpisuje tą samą klasę? Jeśli nie nakażemy jej dziedziczyć po naszej lub nasza klasa nie odziedziczy po tamtej to gwarantowane jest, że któraś wypadnie z obiegu. O wiele bezpieczniejszą metodą  (choć niekoniecznie prostszą) jest korzystanie z mechanizmu eventów Magento do wprowadzania zmian w działaniu obiektów. Załóżmy, że chcemy dodać nową kolumnę do gridu z produktami w panelu administratora. Wykorzytując mechanizm eventów powinniśmy przygotować Observer, dysponujący jedną metodą, która zostanie wywoływana w odpowiedzi na powiadomienie o przygotowaniu kolekcji (w celu dołączeniu nowych danych) oraz drugą, która zostanie wywołana po akcji wyświetlenia formularza (w celu wstawienia dodatkowej kolumny na dodane uprzednio do kolekcji dane).

10. Twórzmy dokumentację funkcjonalną do modułów.

Nawet jeśli posiadamy pamięć absolutną warto spisać wszelkie informacje dotyczące modułu: jak go skonfigurować, jakie są zależności od innych modułów, jakie są odejścia od konwencji oraz najzwyczajniej w świecie – do czego służy. Dzięki temu oszczędzimy czas i swój i innym, gdyż nie będziemy musieli za każdym razem objaśniać komuś działania, a chętni nie będą musieli nas szukać po coraz to większym biurze :) Oczywiście  nasz moduł w tym optymistycznym scenariuszu znajduje się już w repozytorium i każdy zainteresowany ma do niego dostęp.

Z pewnością znalazłoby się jeszcze wiele zasad i porad, a każdy z nas ma pewnie swoje własne programistyczne credo, którym się kieruje. Dlatego pytajmy się, wymieniajmy doświadczenia, i poddawajmy dyskusji problemy oraz rozwiązania jakie powstają podczas pracy. Gwarantuje wam, że na tym zyskacie a już na pewno nie stracicie . Tak więc już dzisiaj zapytaj osobę siedzącą obok Ciebie co według niego jest najważniejsze przy tworzeniu własnego re-użyteczengo modułu. Kto wie, może  dowiesz się czegoś nowego?

Jesteś zainteresowany implementacją Magento? Napisz do nas.