Jak zrobić serwis firmowy raz a porządnie?

Tworząc naszą Drupalową dystrybucję Droopler, wzięliśmy pod uwagę kilka lat doświadczenia przy budowaniu serwisów korporacyjnych. Zauważyliśmy, że jednym z najważniejszych wymogów dotyczących kreacji dużych witryn jest stosowanie zasady “raz a porządnie”.

Raz stworzone oprogramowanie powinno być proste w obsłudze i aktualizacji, i nie wymagać poważnej przebudowy w celu wprowadzenia nowych funkcji. Oto kilka porad na temat tworzenia stron, którymi możemy się z Tobą podzielić. Będą one przydatne zwłaszcza w kontekście pracy z Drooplerem.

Nie chodź na skróty

Programowanie ma to do siebie, że jeden cel można często osiągnąć na wiele sposobów. Pamiętajcie, że sposób najszybszy i najłatwiejszy niekoniecznie jest tym zalecanym. Dobrym przykładem są tu zmiany w wyglądzie stron internetowych. 

Z pewnością spotkaliście się z kiepsko napisanymi arkuszami CSS zawierającymi kod napisany “na szybko”, bez zagłębiania się w dokumentację i dotychczasową strukturę styli. Charakterystyczne dla takich modyfikacji jest nadużywanie dyrektywy !important i chowanie niepotrzebnych elementów za pomocą właściwości display: none. Perspektywa szybkiego przeprowadzenia zmian potrafi przyćmić właściwy osąd do tego stopnia, że kod ląduje w niewłaściwym miejscu. Niedoświadczeni programiści niejednokrotnie edytują pliki skompilowane, nie zauważając zupełnie plików źródłowych SCSS i JavaScript. Skutki takich działań podnoszą koszt ewentualnego przejęcia projektu przez inny zespół.

Innym przykładem pójścia na skróty jest nadpisywanie całych szablonów stron w celu zmiany pojedynczych elementów. Jest to często widoczne w przypadku Drupala i używanych przez niego plików Twig. Wybraną stronę można nadpisać bez żadnych widocznych problemów, zła decyzja projektowa może jednak przynieść dalekosiężne konsekwencje.

Podsumowując: jakie są wady szybkich rozwiązań? Na krótką metę są one tanie i efektywne, ale w dłuższej perspektywie utrudniają utrzymanie strony i jej aktualizację. Ciężko jest też przekazać innym programistom kod pełen nieprzemyślanych modyfikacji.

Przykładaj się do drobiazgów 

Na początek przybliżę Wam teorię rozbitej szyby. Jest to zagadnienie z dziedziny socjologii opisujące przypadek, gdzie zniszczenia w naszym otoczeniu mogą doprowadzić do konkluzji, że prawo nie istnieje. Prof. Philip Zimbardo przeprowadził eksperyment, w którym umieścił dwa porzucone auta, po jednym: w biednej i bogatej dzielnicy. Auto z biednej dzielnicy zostało szybko zniszczone, auto z bogatej dzielnicy pozostało w idealnym stanie. Jednakże po umyślnym wybiciu szyby, również i ono uległo z czasem zupełnej dewastacji. Wygląda na to, że widok zaniedbania wyzwala w człowieku zanik moralnych hamulców.

Teorię tę można odnieść bezpośrednio do pracy programisty. Jeśli zauważy on, że zmiany w danym projekcie są wprowadzane byle jak, nie będzie miał motywacji do pisania solidnego kodu. Metaforyczne “Wybite szyby” sprawią, że kolejne modyfikacje nie będą lepsze od poprzednich.

To właśnie dlatego niezwykle ważne jest przykładanie się do najmniejszych drobiazgów. Tworząc oprogramowanie w Droptica, bardzo wnikliwie sprawdzamy kod i nie dopuszczamy nawet do najmniejszych uchybień, w ten sposób zachęcamy innych, aby nie opuszczali gardy i utrzymywali jakość swojej pracy na wysokim poziomie. Polecamy Wam to podejście. Zwracając uwagę nawet na drobne literówki w komentarzach do kodu, podniesiecie poprzeczkę dla całego zespołu.

Dbałość o szczegóły wiążę się bezpośrednio z poprzednim punktem, czyli nie chodzeniem na skróty. Działajcie solidnie. Od początku istnienia projektu używajcie wersjonowania i wnikliwie sprawdzajcie kod. Jako użytkownicy Drupala i Drooplera bezwzględnie korzystajcie z Composera i nie ulegajcie pokusie ściągania modułów za pośrednictwem plików ZIP. Planujcie swoje działania i stosujcie podejście modularne, w którym poszczególne funkcjonalności są oddzielone od siebie.

Używaj narzędzi zgodnie z ich przeznaczeniem

Potrzeba elastyczności przy projektowaniu stron nigdy nie maleje. Z doświadczenia wiemy, że żadne rozwiązanie edycyjne nie jest w stanie pokryć wszystkich możliwych zastosowań. Prowadzi to zazwyczaj do korzystania z oprogramowania w sposób nie do końca zgodny z intencjami jego twórców.

Patrząc z perspektywy twórców Drooplera, dostarczamy wraz z naszą dystrybucją kilkanaście gotowych typów paragrafów (elementów, z których można zbudować stronę). Czasami zachodzi potrzeba uzyskania funkcjonalności, która nie była przez nas przewidziana. Użytkownicy wklejają przykładowo w treści pól tekstowych skrypty z innych stron internetowych lub zmieniają kolorystykę paragrafów w sposób rozbieżny z oficjalną instrukcją.

Dlaczego takie podejście jest nieefektywne? Wydając nową wersję Drooplera, staramy się przetestować dotychczasowe funkcjonalności i zapewnić wszystkim użytkownikom ciągłość działania ich stron internetowych. Nie jesteśmy jednak w stanie sprawdzić zastosowań niestandardowych i niewspieranych. 

Uwaga ta tyczy się właściwie każdego oprogramowania. Używając narzędzi niezgodnie z przeznaczeniem, musimy się liczyć z faktem, że w przyszłości przestaną one działać zgodnie z naszymi założeniami.

Ogranicz liczbę wykorzystywanych narzędzi

Drupal jest systemem rozbudowywanym przez społeczność w oparciu o zewnętrzne moduły. Ich mnogość powoduje, że jeden efekt można nie raz osiągnąć zupełnie innymi metodami. Dla przykładu: treść możemy dodawać zarówno przez zwykły edytor WYSIWYG, elementy Paragraphs, jak i znany z Wordpressa projekt Gutenberg. Bloki na stronie możemy układać w zaawansowany sposób poprzez moduły Layout Builder lub Context. Wyszukiwanie treści możemy realizować poprzez Views, wbudowany Search lub zewnętrzny Search API.

Wszystkie wymienione w powyższych przykładach moduły mogą działać równolegle i uzupełniać wzajemnie swoje funkcjonalności. Należy jednak pamiętać, że każde kolejne rozwiązanie zastosowane na stronie komplikuje jej konfigurację i wpływa negatywnie na wydajność. Rozpoczynając budowę strony, wybierz narzędzia, których chcesz używać i trzymaj się ich konsekwentnie. W przypadku Drooplera niektóre metody działania (jak dodawanie treści przez Paragraphs) narzucone są z góry przez architekturę dystrybucji.

Zachowaj wizualną spójność

Zachowanie wizualnego porządku jest bardzo istotne w przypadku każdej strony internetowej. Nie chodzi nam jednak wyłącznie o zapewnienie odpowiedniego wyglądu. Równie istotny jest sposób wprowadzania modyfikacji. Witryna wyświetlana zupełnie poprawnie dla zewnętrznego użytkownika może zawierać jednocześnie poważne wady projektowe.

W przypadku Drooplera przed dokonaniem zmian w SCSS polecamy przejrzenie dokumentacji zawartej w oficjalnym repozytorium. Zajmie to chwilę, a przyspieszy Waszą pracę kilkakrotnie. Przygotowaliśmy architekturę SCSS, w której zmienne ułożone są w swoistej piramidzie zależności. Użycie zmiennych u szczytu piramidy wpływa na wszystkie zmienne poniżej, ale istnieje też możliwość zablokowania takiego “dziedziczenia” wartości i nadpisania każdego elementu. To niezwykle elastyczne i efektywne podejście, które pozwala na zmianę całej kolorystyki strony w kilka minut.

Jeśli wprowadzisz modyfikacje poza opisanym systemem, nie skorzystasz z zalet naszej architektury - Twój kod zaś stanie się trudniejszy w aktualizacji i mniej zrozumiały.

Podsumowanie

Zasada “Raz a porządnie” ma cztery niezwykle ważne z punktu biznesowego zalety:

• Ułatwienie aktualizacji - upewniamy się, że jesteśmy gotowi do instalacji przyszłych wersji oprogramowania i dzięki temu jesteśmy w stanie szybko reagować na wydawane krytyczne poprawki.
• Możliwość przejęcia projektu - jeśli zajdzie potrzeba zmiany zespołu programistów lub wykonawcy - odbędzie się ona bez konieczności żmudnych analiz kodu.
• Zabezpieczenie aplikacji - wprowadzanie zmian w zalecany sposób i unikanie rozwiązywania problemów “byle jak” prowadzi w prostej linii do zapewnienia większego poziomu bezpieczeństwa.
• Oszczędność czasu na przyszłość - należy pamiętać, że naprędce pisany kod i pochopnie podjęte decyzje projektowe prędzej czy później zaczynają generować poważne koszty (chociażby refactoringu i aktualizacji).