Refaktoryzacja CSS: Wprowadzenie (część 1)

CSS to prosty język arkuszy stylów do definiowania strony internetowej lub prezentacji dokumentu. Jednak ta prostota pozostawia otwarte drzwi dla wielu potencjalnych problemów i długu technicznego — rozdęty kod, piekło specyfiki, zduplikowane bloki kodu z niewielką lub żadną różnicą, resztki nieużywanych selektorów, niepotrzebne hacki i obejścia, żeby wymienić tylko kilka.

Tego rodzaju dług techniczny, jeśli nie zostanie spłacony na czas, może się kumulować i prowadzić do poważnych problemów. Najczęściej może to prowadzić do nieoczekiwanych efektów ubocznych podczas dodawania nowych składników interfejsu użytkownika i utrudniania utrzymania bazy kodu. Prawdopodobnie pracowałeś już wcześniej nad projektem ze słabą bazą kodu CSS i zastanawiałeś się, jak inaczej napisałeś kod, mając możliwość refaktoryzacji lub przepisania wszystkiego od zera.

Refaktoryzacja dużych części kodu CSS nie jest pod żadnym względem łatwym zadaniem. Czasami może się wydawać, że jest to tylko kwestia „usuwania słabej jakości kodu, pisania lepszego CSS i wdrażania błyszczącego, ulepszonego kodu”. Należy jednak wziąć pod uwagę wiele innych czynników, takich jak trudność refaktoryzacji aktualnej bazy kodu, oczekiwany czas trwania i wykorzystanie zespołu, ustalanie celów refaktoryzacji, śledzenie efektywności i postępu refaktoryzacji itp. Jest też kwestia przekonania kierownictwa lub interesariuszy projektu do zainwestuj czas i zasoby w proces refaktoryzacji.

W tej trzyczęściowej serii przejdziemy przez proces refaktoryzacji CSS od początku do końca, zaczynając od wiedzy o tym, jak do tego podejść i kilku ogólnych zalet i wad refaktoryzacji, następnie przechodząc do samych strategii refaktoryzacji i kończąc z kilkoma ogólnymi najlepszymi praktykami dotyczącymi rozmiaru i wydajności pliku CSS.

Skutki uboczne złej jakości CSS

Mimo całej swojej elastyczności i prostoty, sam CSS ma kilka podstawowych problemów, które pozwalają programistom na pisanie kodu o niskiej jakości. Zagadnienia te wynikają z jego specyfiki i mechanizmów dziedziczenia, działających w zasięgu globalnym, zależności kolejności źródeł itp.

Na poziomie zespołu większość problemów z bazą kodu CSS zwykle wynika z różnych poziomów umiejętności i wiedzy na temat CSS, różnych preferencji i stylów kodu, braku zrozumienia struktury projektu oraz istniejącego kodu i komponentów, braku na poziomie projektu lub zespołu na poziomie standardów i wytycznych i tak dalej.

W rezultacie niskiej jakości CSS może powodować problemy, które wykraczają poza proste błędy wizualne i mogą powodować różne poważne skutki uboczne, które mogą wpłynąć na projekt jako całość. Niektóre takie przykłady obejmują:

• Spadek jakości kodu w miarę dodawania kolejnych funkcji ze względu na różne poziomy umiejętności CSS w zespole programistycznym oraz brak wewnętrznych zasad, konwencji i najlepszych praktyk.
• Dodanie nowych funkcji lub rozszerzenie istniejących selektorów powoduje błędy i nieoczekiwane skutki uboczne w innych częściach kodu (znane również jako regresja ).
• Wiele różnych selektorów CSS ze zduplikowanymi blokami kodu lub fragmentami kodu CSS można podzielić na nowy selektor i rozszerzyć według odmiany.
• Resztki niewykorzystanych fragmentów kodu z usuniętych funkcji . Zespół programistów stracił orientację, który kod CSS jest używany, a który można bezpiecznie usunąć.
• Niespójność w strukturze plików, nazewnictwo klas CSS, ogólna jakość CSS itp.
• „Piekło specyfiki”, gdzie nowe funkcje są dodawane przez nadpisanie zamiast istniejącej bazy kodu CSS.
• Cofanie CSS , gdy selektory o wyższej specyficzności „resetują” styl selektora o niższej specyficzności. Deweloperzy piszą więcej kodu, aby mieć mniej stylów. Powoduje to nadmiarowość i dużo marnotrawstwa w kodzie.

W najgorszym przypadku wszystkie powyższe problemy połączone mogą skutkować dużym rozmiarem pliku CSS , nawet przy zastosowanej minifikacji CSS. Ten CSS zwykle blokuje renderowanie, więc przeglądarka nie renderuje nawet zawartości witryny, dopóki nie zakończy pobierania i analizowania pliku CSS, co skutkuje słabym UX i wydajnością w wolniejszych lub zawodnych sieciach.

Te kwestie wpływają nie tylko na użytkownika końcowego, ale także na zespół programistów i interesariuszy projektu, czyniąc utrzymanie i rozwój funkcji trudnym, czasochłonnym i kosztownym. Jest to jeden z bardziej przydatnych argumentów, które należy przytoczyć, argumentując za refaktoryzacją lub przepisywaniem CSS.

Zespół Netlify zauważył, że powodem ich wielkoskalowego projektu refaktoryzacji CSS była spadająca jakość kodu i łatwość konserwacji, ponieważ projekt rósł w złożoności wraz z dodawaniem coraz większej liczby komponentów interfejsu użytkownika. Zauważyli również, że brak wewnętrznych standardów i dokumentacji CSS doprowadził do spadku jakości kodu, ponieważ coraz więcej osób pracowało nad bazą kodu CSS.

„(…) to, co zaczęło się od zorganizowanego PostCSS, stopniowo przekształciło się w złożoną i powikłaną globalną architekturę CSS z wieloma szczegółami i nadpisaniami. Jak można się spodziewać, w pewnym momencie wprowadzony dług technologiczny utrudnia utrzymanie szybkiej wysyłki bez dodawania jakichkolwiek regresji. Poza tym, wraz ze wzrostem liczby programistów frontend, którzy przyczyniają się do tworzenia bazy kodu, praca z tego rodzaju architekturą CSS staje się jeszcze trudniejsza”.

Refaktoryzacja czy przepisanie?

Refaktoryzacja pozwala programistom na stopniowe i strategiczne ulepszanie istniejącego kodu, bez zmiany jego prezentacji lub podstawowej funkcjonalności. Te ulepszenia mają zwykle niewielki zakres i są ograniczone i nie wprowadzają przełomowych, szeroko zakrojonych zmian architektonicznych ani nie dodają nowych zachowań, funkcji ani funkcjonalności do istniejącej bazy kodu.

Na przykład obecna baza kodu zawiera dwie odmiany komponentu karty — pierwsza została zaimplementowana na wczesnym etapie rozwoju projektu przez doświadczonego programistę, a druga została dodana jakiś czas po uruchomieniu projektu przez mniej doświadczonego programistę w krótkim terminie, więc zawiera zduplikowany kod i szerokie selektory o wysokiej specyficzności.

Należy dodać trzecią odmianę karty, która podziela niektóre style z pozostałych dwóch odmian kart. Aby więc uniknąć błędów, powielanego kodu i złożonych klas CSS oraz znaczników HTML, zespół decyduje się na refaktoryzację CSS komponentu karty przed wdrożeniem nowej odmiany.

Przepisywanie umożliwia programistom wprowadzanie istotnych zmian w bazie kodu i zakłada, że ​​większość, jeśli nie cały kod z bieżącej bazy kodu zostanie zmieniony lub zastąpiony. Rewrite umożliwia programistom tworzenie nowej bazy kodu od podstaw, rozwiązywanie podstawowych problemów z obecnej bazy kodu, których naprawienie było niemożliwe lub kosztowne, ulepszanie stosu technologicznego i architektury oraz ustanawianie nowych wewnętrznych zasad i najlepszych praktyk dla nowej bazy kodu.

Na przykład klient jest w trakcie rebrandingu, a strona internetowa musi zostać zaktualizowana o nowy wygląd i odświeżoną treść. Ponieważ jest to zmiana w całej witrynie po wyjęciu z pudełka, programiści decydują się zacząć od zera, przepisać projekt i skorzystać z okazji, aby rozwiązać podstawowe problemy, które ma obecna baza kodu CSS, ale których nie można rozwiązać za pomocą refaktoryzacji kodu, zaktualizować stos technologiczny CSS , korzystać z najnowszych narzędzi i funkcji, ustalać nowe zasady wewnętrzne i najlepsze praktyki dotyczące stylizacji itp.

Podsumujmy plusy i minusy każdego podejścia.

Kiedy refaktoryzować CSS?

Refaktoryzacja jest zalecanym podejściem do stopniowego ulepszania kodu CSS przy jednoczesnym zachowaniu obecnego wyglądu i stylu (projektu). Członkowie zespołu mogą pracować nad rozwiązywaniem tych problemów z bazą kodu, gdy nie ma żadnych zadań o wyższym priorytecie. Stopniowe ulepszanie bieżącej bazy kodu nie będzie miało bezpośredniego wpływu w większości przypadków, jednak czystszy i łatwiejszy w utrzymaniu kod zapewni łatwiejszą implementację funkcji i mniej nieoczekiwanych błędów i skutków ubocznych.

Interesariusze projektu prawdopodobnie zgodzą się zainwestować ograniczony czas i zasoby w refaktoryzację, ale będą oczekiwać, że te zadania zostaną wykonane szybko i będą oczekiwać, że zespół będzie dostępny dla podstawowych zadań.

Refaktoryzacja CSS powinna być wykonywana w regularnych odstępach czasu, gdy w najbliższej przyszłości nie są planowane żadne szeroko zakrojone zmiany w projekcie lub treści. Zespoły powinny proaktywnie szukać wspomnianych wcześniej słabych punktów w aktualnej bazie kodu CSS i pracować nad ich rozwiązywaniem, gdy nie ma dostępnych zadań o wyższym priorytecie.

Główny programista frontend lub programista z największym doświadczeniem w CSS powinien zgłaszać problemy i tworzyć zadania refaktoryzacji, aby wymusić standardy jakości kodu CSS w bazie kodu.

Kiedy przepisać CSS?

Przepisanie całej bazy kodu CSS powinno być wykonane, gdy baza kodu CSS ma podstawowe problemy , których nie można rozwiązać za pomocą refaktoryzacji lub gdy refaktoryzacja jest droższą opcją. Mówiąc z własnego doświadczenia, kiedy zacząłem pracować dla klientów, którzy przenieśli się z innej firmy i wyżej wymienionych problemów CSS i było oczywiste, że refaktoryzacja będzie trudna, zacznę od polecenia pełnego przepisania i zobaczenia, co myśli klient. W większości przypadków ci klienci byli niezadowoleni ze stanu bazy kodu i byli zadowoleni z dalszego przepisywania.

Innym powodem pełnego przepisania CSS jest planowana istotna zmiana w witrynie — rebranding, przeprojektowanie lub jakakolwiek inna znacząca zmiana, która wpływa na większość witryny. Można bezpiecznie założyć, że interesariusze projektu są świadomi, że jest to znacząca inwestycja i ukończenie przepisywania zajmie trochę czasu.

Audyt kondycji kodu CSS Codebase

Gdy zespół programistów zgodzi się, że kod CSS należy zrefaktoryzować, aby usprawnić przepływ pracy przy opracowywaniu funkcji lub wyeliminować nieoczekiwane efekty uboczne i błędy CSS, zespół musi przedstawić tę sugestię zainteresowanym stronom projektu lub kierownikowi projektu.

Dobrym pomysłem jest dostarczenie twardych danych wraz z subiektywnymi przemyśleniami na temat bazy kodu i ogólnym przeglądem kodu. To również da zespołowi wymierny cel, którego może być świadomy podczas pracy nad refaktorem — docelowy rozmiar pliku, specyfika selektora, złożoność kodu CSS, liczba zapytań o media…

Wykonując audyt CSS lub przygotowując się do refaktoryzacji CSS, polegam na kilku z wielu przydatnych narzędzi, aby uzyskać ogólny przegląd i przydatne statystyki dotyczące bazy kodu CSS.

Moim osobistym narzędziem jest CSS Stats, bezpłatne narzędzie, które zapewnia przydatny przegląd jakości kodu CSS z wieloma przydatnymi wskaźnikami, które mogą pomóc programistom w wyłapaniu niektórych trudnych do wykrycia problemów.

W 2016 r. trivago przeprowadziło zakrojoną na szeroką skalę refaktoryzację swojej bazy kodu CSS i wykorzystało dane z CSS Stats do wyznaczenia konkretnych, mierzalnych celów, takich jak zmniejszenie szczegółowości i zmniejszenie liczby wariantów kolorystycznych. W ciągu zaledwie trzech tygodni udało im się poprawić ogólny stan bazy kodu CSS, zmniejszyć rozmiar pliku CSS, poprawić wydajność renderowania na urządzeniach mobilnych itp.

„Narzędzie takie jak CSS Stats może łatwo pomóc w ustaleniu problemów ze spójnością w bazie kodu. Wskazując, co może się stać, gdy wszyscy mają różne opinie na temat tego, jak powinien wyglądać szary odcień, otrzymasz 50 odcieni szarości. Co więcej, wykres swoistości daje dobre ogólne wskazanie stanu Twojej bazy CSS”.

Jeśli chodzi o narzędzia CLI, Wallace to poręczne narzędzie, które zapewnia nieco podstawowe, ale przydatne statystyki i przegląd CSS, które można wykorzystać do zidentyfikowania problemów związanych z rozmiarem pliku, liczbą reguł i selektorów, typami i złożonością selektorów itp.

Wallace oferuje również bezpłatne narzędzie analizujące na stronie Project Wallace, które wykorzystuje pozornie bardziej zaawansowaną wersję Wallace w backendzie, aby zapewnić przydatne wizualizacje danych i kilka innych wskaźników, które nie są dostępne w interfejsie Wallace CLI.

Project Wallace oferuje również kompletne, płatne rozwiązanie do analizy bazy kodu CSS . Zawiera jeszcze więcej przydatnych funkcji i wskaźników, które mogą pomóc programistom wyłapać niektóre trudne do wykrycia problemy i śledzić zmiany statystyk CSS na podstawie każdego zobowiązania. Chociaż płatny plan zawiera więcej funkcji, bezpłatny plan i podstawowe narzędzie do analizowania CSS są więcej niż wystarczające do audytu jakości bazy kodu CSS i uzyskania ogólnego przeglądu, aby zaplanować refaktoryzację.

Pisanie wysokiej jakości CSS

Widzieliśmy, jak prostota i elastyczność bazy kodu CSS może powodować wiele problemów z jakością kodu, wydajnością i błędami wizualnymi. Nie ma automatycznego narzędzia typu „srebrna kula”, które zapewni, że napiszemy CSS w najlepszy możliwy sposób i unikniemy po drodze wszelkich możliwych pułapek architektonicznych.

Najlepsze narzędzia, które zapewnią, że napiszemy wysokiej jakości kod CSS, to dyscyplina, dbałość o szczegóły oraz ogólna wiedza i umiejętności związane z CSS . Deweloper musi być stale świadomy szerszego obrazu i rozumieć, jaką rolę odgrywa jego CSS w tym szerszym obrazie.

Na przykład, przedefiniowując selektory, pojedynczy programista może poważnie ograniczyć użyteczność, prowadząc do tego, że inni programiści będą musieli powielać kod, aby użyć go w innych, podobnych komponentach z różnymi znacznikami. Te problemy często występują, gdy programiści nie rozumieją i nie wykorzystują podstawowych mechanizmów CSS (kaskada, dziedziczenie, wydajność przeglądarki i specyfika selektorów). Te wczesne decyzje mogą prowadzić do poważnych reperkusji w przyszłości , więc kondycja i łatwość utrzymania bazy kodu CSS zależą od wiedzy, umiejętności i zrozumienia podstaw CSS przez programistę.

Zautomatyzowane narzędzia nie są świadome szerszego obrazu ani sposobu użycia selektora, więc nie mogą podejmować tych kluczowych decyzji architektonicznych, poza egzekwowaniem pewnych podstawowych, przewidywalnych i sztywnych zasad.

Mówiąc z własnego doświadczenia, stwierdziłem, że następujące elementy pomogły mi znacznie poprawić sposób, w jaki pracowałem z CSS:

• Poznanie wzorców architektonicznych.
  Wytyczne CSS zapewniają doskonałą bazę wiedzy i najlepsze praktyki dotyczące pisania wysokiej jakości CSS w oparciu o ogólne wzorce programowania i zasady architektoniczne.
• Ćwicz i ulepszaj.
  Pracuj nad osobistymi projektami lub podejmij wyzwanie od Frontend Mentor, aby poprawić swoje umiejętności. Zacznij od prostych projektów (pojedynczego komponentu lub sekcji) i skup się na pisaniu najlepszego CSS, wypróbuj różne podejścia, stosuj różne wzorce architektoniczne, stopniowo ulepszaj kod i naucz się efektywnie pisać wysokiej jakości CSS.
• Uczenie się na błędach.
  Zaufaj mi, na początku napiszesz naprawdę kiepskiej jakości CSS. Potrzebujesz kilku prób, aby to naprawić. Poświęć chwilę i zastanów się, co poszło nie tak, przeanalizuj słabe punkty, zastanów się, co i jak mogłeś zrobić inaczej i staraj się unikać tych samych błędów w przyszłości.

Ważne jest również ustalenie zasad i wewnętrznych standardów CSS w zespole lub nawet dla całej firmy. Jasno zdefiniowane standardy, styl kodu i zasady obowiązujące w całej firmie mogą przynieść wiele korzyści, takich jak:

• Ujednolicony i spójny styl i jakość kodu
• Łatwiejsza do zrozumienia, solidna baza kodu
• Usprawnione wdrażanie projektów
• Standaryzowane przeglądy kodu, które może wykonać każdy członek zespołu, nie tylko główny programista frontend czy bardziej doświadczeni programiści

Kirby Yardley pracował nad refaktoryzacją systemu projektowania Sundance Institute oraz CSS i zwrócił uwagę na znaczenie ustanowienia wewnętrznych zasad i najlepszych praktyk.

„Bez odpowiednich zasad i strategii CSS jest językiem, który może być nadużywany. Często programiści będą pisać style specyficzne dla jednego komponentu, nie zastanawiając się krytycznie nad tym, jak ten kod mógłby zostać ponownie wykorzystany w innych elementach (…) Po wielu badaniach i rozważaniach na temat tego, jak chcielibyśmy podejść do tworzenia naszego CSS, zdecydowaliśmy się użyć metodologii zwanej ITCSS. “

Wracając do poprzedniego przykładu z zespołu trivago, ustalenie wewnętrznych zasad i wytycznych okazało się ważnym krokiem w procesie refaktoryzacji.

„Wprowadziliśmy bibliotekę wzorców, zaczęliśmy wykorzystywać projektowanie atomowe w naszym przepływie pracy, stworzyliśmy nowe wytyczne dotyczące kodowania i dostosowaliśmy kilka metodologii, takich jak BEM i ITCSS, aby wesprzeć nas w utrzymaniu i rozwijaniu naszego CSS/UI na dużą skalę”.

Nie wszystkie zasady i standardy muszą być ręcznie sprawdzane i egzekwowane. Narzędzia do lintingu CSS, takie jak Stylelint, zapewniają przydatne reguły, które pomogą Ci sprawdzić błędy i egzekwować wewnętrzne standardy i typowe najlepsze praktyki CSS, takie jak blokowanie pustych bloków kodu CSS i komentarzy, blokowanie duplikatów selektorów, ograniczanie jednostek, ustawianie maksymalnej szczegółowości selektorów i głębokości zagnieżdżania, ustalanie wzór nazwy selektora itp.

Wniosek

Przed podjęciem decyzji o zaproponowaniu granularnej refaktoryzacji bazy kodu lub pełnego przepisania CSS, musimy zrozumieć problemy z obecną bazą kodu , aby uniknąć ich w przyszłości i mieć wymierne dane dla procesu. Baza kodu CSS może zawierać wiele złożonych selektorów o wysokiej specyficzności, które powodują nieoczekiwane efekty uboczne i błędy podczas dodawania nowych funkcji. Być może baza kodu cierpi z powodu wielu powtarzających się fragmentów kodu, które można przenieść do oddzielnej klasy narzędziowej, lub może połączenie różne zapytania o media powodują nieoczekiwane konflikty.

Przydatne narzędzia, takie jak CSS Stats i Wallace, mogą zapewnić ogólny ogólny przegląd bazy kodu CSS i szczegółowy wgląd w stan i kondycję bazy kodu. Narzędzia te zapewniają również mierzalne statystyki , które można wykorzystać do ustalenia celów procesu refaktoryzacji i śledzenia postępów w refaktoryzacji.

Po określeniu celów i zakresu refaktoryzacji, ważne jest ustalenie wewnętrznych wytycznych i najlepszych praktyk dotyczących bazy kodu CSS — konwencji nazewnictwa, zasad architektury, struktury plików i folderów itp. Zapewnia to spójność kodu, ustanawia rdzeń projektu, który można udokumentować i które można wykorzystać do onboardingu i przeglądu kodu CSS. Korzystanie z narzędzi lintingowych, takich jak Stylelint, może pomóc w egzekwowaniu niektórych typowych najlepszych praktyk CSS, aby częściowo zautomatyzować proces przeglądu kodu.

W następnym artykule z tej trzyczęściowej serii zajmiemy się kuloodporną strategią refaktoryzacji CSS, która zapewnia płynne przejście między obecnym i zrefaktoryzowanym kodem.

Bibliografia

• „Zarządzanie projektami CSS za pomocą ITCSS”, Harry Roberts
• „Refaktoryzacja CSS na dużą skalę w Trivago”, Christoph Reinartz
• „System projektowania Sundance.org i refaktor CSS”, Kirby Yardley
• „Od semantycznego CSS do Tailwind: refaktoryzacja bazy kodu Netlify UI”, Charlie Gerard i Leslie Cohn-Wein
• „Narzędzia audytu CSS”, Iris Lješnjanin