Jak rozpoznać czy Twój projekt na Drupal 8 jest dobrze zrobiony?

Data dodania:

GIT

programista-drupala-podczas-pracy
Zanim przyjmiesz projekt od swojego wykonawcy koniecznie sprawdź czy dobrze wykonał swoją robotę. Niestety, wiele firm/freelancerów nie zna Drupala, ale przyjmują zlecenia na wykonanie stron w oparciu o ten CMS. Najczęściej testowanie strony przez klienta polega tylko na sprawdzeniu frontu oraz funkcjonalności – jeśli wszystko działa i w miarę dobrze wygląda, to projekt musi być zrobiony dobrze...

W ten sposób nie sprawdzimy jednak jak wykonany jest backend oraz jakiej jakości jest kod przygotowany przez programistów. W tym tekście zamieszczę sposoby na sprawdzenie kodu, które pozwolą wyeliminować problemy z nim związane w przyszłości.

GIT

Git to system kontroli wersji. Z jego pomocą mamy pełną kontrolę nad całym kodem projektu. Wszelkie zmiany jakie są dokonywane w kodzie będą rejestrowane i możliwe do wglądu. Cały proces dostarczania kodu powinien być oparty właśnie o gita. Wysyłka plików ze środowiska lokalnego na serwer produkcyjny powinna odbywać się poprzez komendy gita w wierszu poleceń.


Aby sprawdzić czy projekt jest wrzucony do gita w głównym katalogu projektu powinien być folder .git a w nim plik config. W configu powinien być adres url do 'remote origin', gdzie jest dostępny aktualny kod projektu.

Composer

Composer to system zarządzania pakietami dla języka PHP. Z jego pomocą możemy zainstalować Drupala, wszystkie moduły oraz zależności. Dzięki temu aktualizacja całego naszego kodu jest banalnie prosta i sprowadza się do polecenia composer update w wierszu poleceń.


Jeśli projekt został wykonany przy użyciu composera struktura katalogów w głównym folderze projektu powinna dzielić się na vendor i web/docroot. W vendor trzymane są wszystkie zależności a w web/docroot instalacja Drupala. Kolejnym krokiem jest sprawdzenie pliku composer.json. W sekcji 'require' powinny być wszystkie moduły z katalogu web/modules/contrib. Jeśli w katalogu web/libraries są zamieszczone jakieś biblioteki, to powinny być one zamieszczone w sekcji 'repositories'.

Moduły

Moduły są kluczową funkcjonalnością Drupala. Wszystkie nowe funkcjonalności jak i rozszerzanie obecnych powinny być w katalogu web/modules. Katalog powinien być podzielony na contrib oraz custom. W contrib powinny być wszystkie moduły napisane przez społeczność dostępne na drupal.org, a w custom powinny być moduły dedykowane napisane przez programistów odpowiedzialnych za projekt.


Najpierw zajmijmy się katalogiem contrib. Jeśli ilość modułów w nim zawartych liczona jest w dziesiątkach, a projekt wcale nie był jakiś rozległy, to może znaczyć, że deweloperzy poszli na łatwiznę i chcieli zrobić wszystko najmniejszym kosztem instalując co popadnie.


Należy również sprawdzić jakość instalowanych modułów, gdyż wiele z tych dostępnych na drupal.org jest w wersjach dev czy beta i nie nadają się do wrzucania w tej formie na produkcję. Najlepiej jeśli moduł na stronie drupal.org jest na zielono – wtedy mamy pewność, że wszystko z nim w porządku.


Jeśli chodzi o moduły w folderze custom, to musimy być szczególnie uważni. To tutaj (a przynajmniej powinien) znajduje się cały kod napisany przez programistów.


Moduły powinny być podzielone na funkcjonalności, tzn. że jeden moduł powinien odpowiadać za jedną konkretna funkcjonalność, np. do newslettera powinien być osobny moduł, a do integracji z jakimś systemem powinien być osobny moduł. Złą praktyką jest tworzenie jednego modułu o nic nie wnoszącej nazwie np. 'common' i wrzucanie tam wszystkiego.


Każdy moduł powinien mieć nazwę adekwatną do tego czym się zajmuje, czyli moduł do wysyłki newslettera nazywa się 'newsletter', a moduł do integracji z elasticsearch nazywa się 'elastic', 'elastic_integration' itp.


Po wejściu w moduł powinniśmy zobaczyć najpierw plik .module. Jeśli ma on setki czy tysiące linii, to może być to błędem. Oczywiście nadal można tak pisać kod, ale jest on strukturalny i w przyszłości podczas kolejnych aktualizacji (szczególnie do drupala 9) może przestać działać. Większość funkcjonalności powinno się znajdować w katalogu src modułu.


W większych modułach, szczególnie w tych odpowiadających za kluczowe funkcjonalności strony powinien również znajdować się katalog tests. Złożony kod, aby dobrze działał musi być przetestowany.


Ważne jest również dokumentowanie kodu. Po wejściu w jakikolwiek plik z końcówką php nad funkcjami powinny widnieć adnotacje zamieszczone w /** */. W adnotacjach powinny być zamieszczone informacje do czego dana funkcja/metoda służy, jakie argumenty przyjmuje i co zwraca.

Skórka

W katalogu web/themes znajdziemy tak jak w przypadku modułów 2 katalogi, custom i contrib. W contrib są skórki gotowe pobrane z drupal.org, a w custom są stworzone przez developerów.


Gotowe skóki nie powinny przysparzać problemów jeśli są dobrze zaimplementowane, jednak customowe to już inny temat.


W customowej skórce w pliku .info.yml powinny znaleźć się informacje na temat tego czy skórka jest stworzona od podstaw przez dewelopera czy dziedziczy z jakiejś gotowej (np. bootstrap). W tym pliku znajdziemy również spis wszystkich regionów strony. Jeśli jest ich dużo, a ich nazwy są typu 'header1', 'header2', 'footer_bottom', 'footer_bottom_after' tzn., że programista nie miał najlepszego pomysłu na wdrożenie projektu graficznego. Nazwy regionów powinny być jasne i precyzyjne, a ich ilość powinna się mieścić w większości przypadkach w max 10.


Kolejnym plikiem, którym warto się zainteresować jest .theme. W tym pliku programiści często dodają mnóstwo kodu, który nadpisuje przeróżne rzeczy na stronie. Jeśli jest go dużo, a dodatkowo jest słabo udokumentowany, może oznaczać, że deweloper nadpisał sporą część Drupala/gotowych modułów zamiast zaprojektować coś samemu. Takie nadpisywane funkcjonalności ciężko się rozwija i aktualizuje.


Skórka powinna mieć katalogi css i js. Katalogi powinny byc złożone z wielu plików, które odpowiadają za różne elementy strony. Jeśli jest tylko jeden plik style.css i jeden plik script.js i oba mają po kilka tysięcy linii to nie świadczy to za dobrze o programiście.

Podsumowanie

Dzięki takim testom jesteśmy w stanie sprawdzić czy deweloperzy starali się dostarczyć projekt dobrej jakości czy chcieli go zrobić 'byle jakoś działało'. Warto również przedstawić wymagania przed startem projektu, aby Drupal był zainstalowany composerem, moduły wykorzystywane na stronie nie były w wersjach dev lub beta, a kod był dobrze udokumentowany i wrzucony do gita. Programiści często chcąc zaoszczędzić trochę czasu na naukę Drupala, robią to co znajdą w pierwszym lepszym tutorialu.


W razie problemów z takimi testami zawsze można zlecić audyt tego co zostało wykonane doświadczonym programistom, którzy dokładnie sprawdzą i ocenią kod. Dzięki temu aplikacja może działać dobrze przez wiele lat a jej rozwój będzie szybki i bezproblemowy.


Masz podejrzenia niepoprawnego wykonania projektu na Drupalu? Napisz do nas!

Autor: Adam

Full-stack developer. Programista z powołania. Samouk. Problemy podczas tworzenia projektów traktuje jako szansę do rozwoju. Po pracy lubi gotować, grać na konsoli i bawić się z kotem.