Kod w wielu językach programowania przechodzi przed wdrożeniem do użytku przegląd kodu. Bez względu na to czy jest to szybka recenzja, wnikliwy przegląd dokonany przez partnera czy kompletne testy jednostkowe, wszytskie te techniki pomagają z przekonaniem wydać kod, który będzie funkcjonować prawidłowo.
Zastanawiałem się, jak może wyglądać przegląd kodu CSS. Kod ten można pisać na wiele sposobów, a najlepszy z nich zwykle dobierany jest pod kątem konkretnego projektu. W żadnym wypadku nie zamierzam pisać dogmatycznego artykułu. Zamiast tego chcę zaprezentować przykładowy punkt wyjścia do udoskonalenia kodu CSS przed jego publikacją.
Po co w ogóle wykonywać przegląd kodu CSS
To naturalne, że zastanawiasz się dlaczego w ogóle mielibyśmy recenzować CSS. Przegląd kodu stanowi jeszcze jeden etap prac, który wymaga dodatkowego czasu, pieniędzy oraz wysiłku i opóźnia dostarczenie produktu.
Dzięki recenzji możemy jednak spojrzeć na naszą pracę z dystansu i uczciwie ją ocenić – bądź poprosić drugą osobę, która będzie mieć świeże spojrzenie. Tym właśnie różnimy się od maszyn i dzięki temu możemy wystrzec się wymagających naprawy błędów lub problemów z wydajnością, które mogłyby umknąć naszej uwadze przed dostarczeniem kodu.
Przegląd kodu nie służy jedynie wcześniejszemu wyeliminowaniu błędów – może przynieść o wiele więcej korzyści. Zauważyłem, że podzielenie przeglądu na kilka ukierunkowanych na osiągnięcie konkretnych korzyści obszarów pomaga uporządkować proces recenzji i przyspiesza osiąganie dobrych rezultatów. Twoje indywidualne korzyści mogą różnić się od tych przedstawionych poniżej. Wymieniłem jednak te, które odnoszę regularnie.
Obszar 0. Kod spełnia swoje zadanie
Nie będziemy się nad tym zbytnio rozwodzić, lecz warto o tym etapie pamiętać. Podstawowym zadaniem kodu CSS jest sformatowanie strony zgodnie z zamierzeniem projektanta. CSS powinien nadać stronie wygląd pokrywający się ze szkicem projektowym czy dopasować go do wymagań stylistycznych. Wygląd ten tworzony jest dzięki zmiennej treści strony (tytuły i treść różnej długości, obrazy różnej wielkości itd.). Jeśli CSS nie spełnia tego zadania, należy to naprawić w pierwszej kolejności.
Jeśli strona jest responsywna, upewnij się, że sformatowane elementy działają płynnie na każdym punkcie kontrolnym.
Obszar 1. Styl i spójność
Na tym etapie naszym celem jest upewnienie się, że kod CSS został dobrze napisany, zorganizowany i udokumentowany. Ci z nas, którym zdarzyło się przejąć projekt po innych programistach wiedzą, jakie niesie to ze sobą korzyści. Kod, w którym stosowana jest spójna konwencja nazewnicza i który ma dokładną dokumentację jest łatwiejszy do zrozumienia, a ponadto zawiera instrukcje dotyczące jego obsługi i dalszego udoskonalania.
Pytania, jakie należy zadać:
- Czy dla danego projektu istnieją wytyczne dotyczące formatowania CSS? Jeśli tak, czy kod jest z nimi zgodny?
- Czy kod jest dokładnie udokumentowany? Czy zawiera jakieś niejasne elementy, własności bądź sztuczki, co do których nie można wywnioskować, dlaczego zostały napisane w dany sposób?
- Czy istnieją jakieś rażące nieścisłości w nazewnictwie elementów lub w organizacji ich własności?
Dostępne zasoby:
- CSS Lint — świetne narzędzie do wyszukiwania błędów i nieścisłości. Jest ono również dostępne w formie zadań w narzędziach Grunt i Gulp, które można skonfigurować tak, by weryfikowały kod zgodnie naszymi własnymi ustawieniami.
- CSS Style Guides — przegląd przykładowych przewodników po stylach, które mogą być źródłem inspiracji do opracowania własnego przewodnika.
- What makes for good docs?: artykuł Dave’a DeSandro przedstawiający związek dokumentacji z marketingiem.
Obszar 2. Zgodność z przeglądarkami
Kiedy już kod CSS jest odpowiednio zorganizowany i spójny, zwykle sprawdzam jak formatowanie prezentuje się w różnych przeglądarkach i na różnych urządzenia. Dobrze napisany kod to jedno, jednak nie zda się on na wiele, jeśli nie działa w odpowiednim miejscu i czasie.
Pytania, jakie należy zadać:
- Które przeglądarki i urządzenia mają być obsługiwane? Czy możemy je zdobyć na czas testowania?
- Czy dla określonej strony dostępne są dane analityczne? Jeśli tak, czy można na ich podstawie wywnioskować, do których przeglądarek należy przyłożyć największą uwagę podczas testów?
- Czy w kodzie zastosowano jakieś sztuczki, by kod funkcjonował w konkretnej przeglądarce lub na konkretnym urządzeniu? Jeśli tak, czy można je napisać inaczej? Czy są dobrze udokumentowane?
Dostępne zasoby:
- Can I Use — centralne repozytorium zawierające informacje o własnościach CSS i ich zgodności z różnymi przeglądarkami i wersjami.
- Ghostlab — aplikacja do przeprowadzania zsynchronizowanych testów w przeglądarkach na wielu urządzeniach.
- Establishing an Open Device Lab — wyczerpujący artykuł w portalu Smashing Magazine zawierający informacje na temat korzyści płynących z korzystania z laboratoriów testowych oraz porady jak założyć własne laboratorium.
- Support vs. Optimization — godny polecenia wpis Brada Frosta opisujący różnice pomiędzy tymi pojęciami i ich wpływ na sposób pisania kodu.
- Testowanie w wielu przeglądarkach — taka możliwość dostępna jest na stronach Cross Browser Testing i Browserstack.
Obszar 3. Precyzja
Teraz czas ocenić jak precyzyjne są elementy naszego kodu i sprawdzić, które fragmenty można poddać refaktoryzacji. Przegląd tego obszaru pozwoli nam stworzyć funkcjonalną kaskadę stylów, której elementy będą tak modułowe lub tak precyzjne jak chcemy.
Pytania, jakie należy zadać:
- Czy w kodzie używane są identyfikatory? Jeśli tak, czy nie można by w ich miejsce zastosować klas? Czy wytyczne stylistyczne mówią coś na ten temat?
- Czy w kodzie jest używana dyrektywa
!important
? Jeśli tak, dlaczego została zastosowana? Czy dałoby się zrefaktoryzować kod, tak by można jej było uniknąć? - Czy w kodzie wykorzystywane są przedrostki, a jeśli tak, to czy dla nieobsługiwanych przeglądarek zostały ustawione odpowiednie wartości domyślne?
- Jak modułowe są elementy kodu? Czy sprawdzą się w teście, w którym wszystkie zostaną użyte w jednym dokumencie HTML?
Dostępne zasoby:
- CSS Specificity Graph Generator — narzędzie umożliwiające wizualizację poziomu precyzji na przestrzeni całego arkusza stylów.
- Specificity Calculator — kalkulator pozwalający zobaczyć w formie graficznej jak precyzyjny jest dany element.
- Specifics on CSS Specificity — wpis wyjaśniający czym jest precyzja selektorów CSS i jaki jest jej wpływ na kaskadę stylów.
- Responsive Deliverables — ogólnie jestem wielkim zwolennikiem tworzenia „programów rozruchowych w wersji mini”, jednak dobrze byłoby sprawdzić także stopień precyzji kodu.
Obszar 4. Wykorzystanie preprocesora
Jeśli projekt nie korzysta z preprocesora, zignoruj ten etap. Jeśli zaś korzysta, na pewno znajdzie się kilka rzeczy, które warto przemyśleć.
Pytania, jakie należy zadać:
- Czy istniejące zmienne są wykorzystywane tam gdzie powinny? Czy wprowadzono jakieś nowe zmienne? Jeśli tak, czy są zrozumiałe i dobrze udokumentowane?
- Czy inne abstrakcje (np. rozszerzenia, domieszki, pętle, słowniki itp.) zostały użyte prawidłowo i zgodnie z funkcjonowaniem pozostałej części kodu?
- Czy nowe elementy CSS zostały umieszczone w prawidłowych widokach częściowych? Czy użyto nowych widoków częściowych? Czy ich zastosowanie ma sens pod kątem architektury projektu?
- Czy reguły są zgodne z przyjętymi wytycznymi stylistycznymi dla preprocesorów?
Dostępne zasoby:
- Sass Style Guide ze strony CSS-Tricks
- Sass Guidelines autorstwa Hugo Giraudela
- Podstawy Sass
Obszar 5. Wydajność
Nie umieściłem etapu poświęconego wydajności na końcu procesu recenzji po to, by umniejszyć jego znaczenie, lecz by był wisienką na naszym przeglądowym torcie. Zapewnienie wydajności kodu CSS jest często kwestią jego doszlifowania, a także zależy od sposobu w jaki kod jest dostarczany i udostępniany. Z tego powodu zwieńczenie przeglądu etapem poświęconym wydajności wydaje się uzasadnione – nawet jeśli zawsze podświadomie mamy ją na uwadze.
Pytania, jakie należy zadać:
- Jaki jest końcowy rozmiar pliku CSS? Czy planujemy poddać go minimalizacji i skompresować do formatu gzip (tak, proszę!)? Jaka będzie wówczas różnica w rozmiarze?
- Jak wiele różnych arkuszy stylów wczytujemy (poprzez element
link
lub dyrektywę@import
)? Czy możemy zmniejszyć tę liczbę? Czy można je obsłużyć warunkowo lub asynchronicznie? - Kod CSS jest zapisywany w pamięci podręcznej, prawda?
Dostępne zasoby:
- CSS Stats — podaj adres URL strony a otrzymasz garść statystyk, w tym raport przedstawiający wszystkie wykorzystywane czcionki i kolory.
- CSS Dig — bardzo podobne narzędzie do CSS Stats, tyle że w formie wygodnego rozszerzenia przeglądarki Chrome.
- unCSS — menadżer zadań usuwający nieużywany CSS w oparciu o kod HTML i JavaScript. Dostępny w narzędziach Grunt, Gulp i Broccoli.
- Critical CSS — jeszcze jeden menedżer zadań, tworzący pojedyncze pliki CSS na podstawie kodu HTML danej strony. Taka optymalizacja jest stale zalecana przez narzędzie PageSpeed Insights firmy Google.
- loadCSS — funkcja umożliwiająca asynchroniczne wczytywanie kodu CSS.
Podsumowanie
Na pewno nie wszystkie z wymienionych pytań i narzędzi są zawsze potrzebne i mają zastosowanie w każdym projekcie. W gruncie rzeczy istnieje prawdopodobnie jeszcze więcej pytań i narzędzi, którym warto poświęcić uwagę. Czy są jeszcze jakieś pytania, które sobie rutynowo zadajesz przed przekazaniem arkuszy stylów do użytku? Na którym etapie przeglądu zająłbyś się, na przykład, wpływem CSS na dostępność strony? Podziel się swoimi przemyśleniami!
Pamiętaj również, że przegląd nie służy stworzeniu kodu doskonałego. W przypadku CSS idziemy na kompromisy z wielu powodów (celowo bądź nie). Koniec końców, wystarczy, że staramy się po prostu dobrze wykonać naszą pracę, a przeprowadzenie przeglądu kodu nam w tym pomoże.