Audyt techniczny WordPress - kod, architektura i możliwość dalszego rozwoju

Strona działa, ale każda aktualizacja budzi obawy? Rozwój trwa coraz dłużej? Poprzedni wykonawca przestał obsługiwać projekt? A może planujesz przejęcie strony przez nowy zespół i nie wiesz, w jakim stanie jest jej kod?

Audyt techniczny WordPress pozwala ocenić rzeczywisty stan istniejącego wdrożenia przed rozpoczęciem dalszych prac.

Analizujemy między innymi:

• architekturę projektu,
• motyw i kod dedykowany,
• wtyczki i zależności,
• wersje WordPressa, PHP i komponentów,
• bazę danych,
• integracje,
• logi i błędy,
• sposób wykonywania aktualizacji,
• środowiska developerskie i testowe,
• proces wdrożeń,
• elementy wpływające na wydajność,
• dług techniczny,
• możliwość dalszej rozbudowy.

Efektem nie jest lista kilkuset automatycznie wygenerowanych uwag.

Celem audytu jest odpowiedź na znacznie ważniejsze pytania:

Co trzeba poprawić? Co można pozostawić? Jakie są ryzyka? Czy projekt warto dalej rozwijać?

Audyt nie jest potrzebny przed każdą drobną zmianą.

Największą wartość daje wtedy, gdy firma stoi przed decyzją dotyczącą dalszego rozwoju istniejącego projektu.

Przejęcie strony po innym wykonawcy

Nowy zespół developerski nie powinien zaczynać większych zmian bez poznania istniejącego rozwiązania.

Przed przejęciem sprawdzamy między innymi:

• w jaki sposób przygotowano motyw,
• gdzie znajduje się kod dedykowany,
• jakie wtyczki są krytyczne,
• jak działają integracje,
• czy istnieje repozytorium,
• jak wykonywane są wdrożenia,
• jakie wersje technologii są wykorzystywane,
• gdzie znajdują się potencjalne ryzyka.

Dzięki temu można oddzielić faktyczne problemy od elementów, które działają prawidłowo i nie wymagają przepisywania.

Jeżeli projekt wymaga później stałego zespołu developerskiego, możemy przejąć jego wsparcie techniczne WordPress i dalszy rozwój.

Przed większą rozbudową strony

Jeżeli planujesz:

• nowe funkcjonalności,
• integrację z CRM lub ERP,
• strefę klienta,
• rozbudowę formularzy,
• nowe wersje językowe,
• zmianę sposobu zarządzania treścią,
• integrację API,

warto wcześniej ustalić, czy obecna architektura pozwala bezpiecznie dobudować kolejne elementy.

Nowa funkcja może być stosunkowo prosta sama w sobie, ale kosztowna we wdrożeniu, jeżeli istniejący projekt zawiera silne zależności, przestarzały kod lub rozwiązania trudne do rozszerzenia.

Gdy aktualizacje są ryzykowne

Audyt ma sens również wtedy, gdy:

• WordPress od dawna nie był aktualizowany,
• używana jest stara wersja PHP,
• aktualizacja wtyczki powoduje błędy,
• motyw zawiera modyfikacje wykonane bez kontroli wersji,
• firma nie wie, które rozszerzenia można bezpiecznie zaktualizować,
• zmiana jednego elementu wpływa na inne części strony.

W takim przypadku najpierw ustalamy zależności, a dopiero później przygotowujemy plan aktualizacji.

Gdy rozwój staje się coraz wolniejszy

Jeżeli prosta zmiana, która kiedyś zajmowała kilka godzin, obecnie wymaga kilku dni analizy i poprawek, problemem może być narastający dług techniczny.

Objawami mogą być:

• wiele obejść w kodzie,
• powielone funkcje,
• duża liczba zależności,
• brak spójnej architektury,
• brak dokumentacji,
• silne powiązanie funkcji z pojedynczymi wtyczkami,
• trudne do przewidzenia skutki zmian.

Audyt pozwala ustalić, czy problem można rozwiązać stopniową refaktoryzacją, czy potrzebna jest większa przebudowa.

Przed modernizacją lub redesignem

Nowy wygląd strony nie rozwiązuje automatycznie problemów starej technologii.

Jeżeli obecny WordPress ma kilka lat, przed redesignem warto ustalić, które elementy:

• można zachować,
• wymagają aktualizacji,
• należy przebudować,
• lepiej przygotować ponownie.

Dopiero na tej podstawie można zdecydować, czy wystarczy modernizacja istniejącej strony, czy bardziej racjonalne będzie nowe wdrożenie. Obecna usługa modernizacji Webtom obejmuje już późniejszy etap przebudowy strony, więc audyt techniczny powinien pozostać etapem diagnozy poprzedzającym decyzję.

Zakres ustalamy indywidualnie. Nie każda strona wymaga analizy wszystkich poniższych elementów.

WordPress i środowisko technologiczne

Weryfikujemy między innymi:

• wersję WordPressa,
• wersję PHP,
• konfigurację środowiska,
• kompatybilność komponentów,
• zależności pomiędzy systemem, motywem i wtyczkami,
• elementy wymagające aktualizacji.

Interesuje nas nie tylko to, czy dana wersja jest aktualna, ale również jak duże ryzyko wiąże się z przejściem na nowsze środowisko.

Motyw może być:

• dedykowany,
• oparty o gotowy szablon,
• oparty o builder,
• rozwijany przez kilku kolejnych wykonawców,
• silnie zmodyfikowany względem pierwotnej wersji.

Sprawdzamy między innymi:

• sposób organizacji kodu,
• strukturę komponentów,
• miejsca zawierające logikę biznesową,
• sposób wykorzystania hooków i filtrów,
• powielony kod,
• rozwiązania trudne w utrzymaniu,
• zależności od konkretnych rozszerzeń,
• elementy utrudniające dalszy rozwój.

Nie chodzi o ocenianie kodu według osobistych preferencji programisty.

Oceniamy przede wszystkim, czy obecna konstrukcja jest czytelna, przewidywalna, możliwa do aktualizacji i rozszerzania.

Jeżeli projekt wymaga później przebudowy bardziej zaawansowanych elementów, możemy przejąć również dedykowane programowanie WordPress.

Sama liczba wtyczek niewiele mówi o jakości projektu.

Znacznie ważniejsze jest:

• do czego są wykorzystywane,
• czy są rozwijane,
• czy się wzajemnie dublują,
• które z nich są krytyczne,
• czy projekt zależy od rozszerzeń niewspieranych,
• czy funkcjonalność można bezpiecznie zaktualizować,
• czy występują konflikty.

Podczas audytu tworzymy obraz zależności pomiędzy WordPressem, motywem, wtyczkami i kodem dedykowanym.

Dzięki temu wiadomo, które elementy można bezpiecznie zmienić, a które wymagają wcześniejszych testów lub przebudowy.

W rozbudowanych projektach WordPress analiza nie powinna kończyć się na frontendzie i liście wtyczek.

W zależności od projektu sprawdzamy również:

• sposób przechowywania treści,
• custom post types,
• pola dodatkowe,
• relacje pomiędzy danymi,
• tabele tworzone przez wtyczki,
• dane historyczne,
• nieużywane elementy,
• problemy wynikające z wieloletniej rozbudowy systemu.

To szczególnie ważne przed:

• migracją,
• zmianą motywu,
• przebudową CMS,
• integracją z innym systemem,
• refaktoryzacją istniejących funkcji.

Strona WordPress może komunikować się między innymi z:

• CRM,
• ERP,
• API partnerów,
• systemami mailingowymi,
• narzędziami marketing automation,
• systemami rekrutacyjnymi,
• zewnętrznymi formularzami,
• systemami płatności,
• innymi bazami danych.

W audycie analizujemy:

• gdzie znajduje się kod integracji,
• w jaki sposób wymieniane są dane,
• jak obsługiwane są błędy,
• czy istnieją logi,
• jakie komponenty zewnętrzne są krytyczne,
• jakie ryzyka niesie zmiana integracji.

Integracja, która działa dzisiaj, może jednocześnie być bardzo trudna w późniejszym utrzymaniu.

Dlatego sprawdzamy nie tylko czy działa, ale również jak została zbudowana.

Nie wszystkie problemy techniczne są widoczne dla użytkownika.

Strona może działać pozornie prawidłowo, a jednocześnie regularnie generować:

• błędy PHP,
• problemy JavaScript,
• błędy integracji,
• nieudane zadania cron,
• problemy z wysyłką wiadomości,
• błędy zapytań do bazy,
• ostrzeżenia dotyczące niekompatybilnych komponentów.

Jeżeli projekt na to pozwala, analizujemy dostępne logi i próbujemy ustalić, które problemy są incydentalne, a które wskazują na większy problem architektoniczny.

Audyt techniczny może wskazać źródła problemów z wydajnością, np.:

• ciężki motyw,
• nadmierną liczbę zapytań,
• niewłaściwie działające wtyczki,
• problemy z bazą danych,
• nieefektywne fragmenty kodu,
• nieprawidłowy cache,
• problemy po stronie serwera.

Nie zastępuje jednak pełnego audytu UX i Performance, jeżeli głównym celem jest analiza Core Web Vitals, ścieżki użytkownika lub konwersji.

Jednym z najważniejszych rezultatów audytu może być odpowiedź na pytanie: Czy tę stronę da się bezpiecznie zaktualizować?

Analizujemy między innymi zależności pomiędzy:

• WordPressem,
• PHP,
• motywem,
• wtyczkami,
• kodem dedykowanym,
• bibliotekami,
• integracjami.

Nie aktualizujemy produkcji metodą prób i błędów.

Jeżeli zmiany są ryzykowne, rekomendujemy wykonanie ich najpierw na środowisku testowym WordPress. Staging pozwala weryfikować m.in. aktualizacje, integracje i większe zmiany przed publikacją.

Stan techniczny projektu to nie tylko kod.

Sprawdzamy również, w jaki sposób strona jest rozwijana.

W zależności od projektu analizie mogą podlegać:

• repozytorium Git,
• środowisko development,
• staging,
• produkcja,
• sposób wykonywania deploymentu,
• backup przed zmianami,
• możliwość cofnięcia wdrożenia,
• dokumentacja,
• historia zmian.

Jeżeli jedynym procesem wdrożenia jest: „edytujemy plik bezpośrednio na serwerze produkcyjnym” to nawet relatywnie prosty projekt może generować niepotrzebne ryzyko.

Dług techniczny nie oznacza automatycznie, że projekt jest źle wykonany.

Część długu może powstać naturalnie:

• technologia się zmienia,
• wymagania biznesowe rosną,
• pojawiają się kolejne integracje,
• rozwiązania używane kilka lat temu przestają być wspierane,
• szybkie rozwiązanie tymczasowe pozostaje w projekcie znacznie dłużej niż planowano.

Problem zaczyna się wtedy, gdy dług techniczny utrudnia każdą kolejną zmianę.

Podczas audytu staramy się rozdzielić:

• elementy wymagające pilnej poprawy,
• problemy możliwe do usunięcia etapami,
• zadania rozwojowe,
• elementy, których przebudowa nie przyniosłaby uzasadnionej korzyści.

Celem nie jest refaktoryzowanie wszystkiego.

Celem jest świadome zarządzanie ryzykiem i kosztem dalszego rozwoju.

To jeden z najważniejszych scenariuszy wykorzystania tej usługi.

Jeżeli zmienia się wykonawca, nowy zespół powinien najpierw zrozumieć:

• strukturę projektu,
• historię najważniejszych decyzji,
• stan technologii,
• integracje,
• sposób deploymentu,
• ograniczenia,
• znane problemy.

Dopiero później można odpowiedzialnie zadeklarować: „przejmujemy rozwój”.

Webtom.pl może przeprowadzić audyt jako osobny etap przed rozpoczęciem dalszej współpracy.

Po analizie klient może zdecydować, czy:

• zlecić nam poprawki,
• rozpocząć stałe utrzymanie,
• kontynuować rozwój z dotychczasowym zespołem,
• przekazać raport innemu wykonawcy.

Audyt nie wymaga automatycznie zlecenia kolejnego etapu Webtom.pl.

Jeżeli projekt przejmujesz jako agencja i potrzebujesz zewnętrznego zespołu, który będzie realizował development dla Twojego klienta, możemy również pracować w modelu White Label WordPress dla agencji.

To często najważniejsze pytanie całego audytu.

Naprawa punktowa

Ma sens, gdy architektura jest poprawna, a problemy dotyczą ograniczonego zakresu.

Przykładowo:

• kilku błędnych wtyczek,
• konfiguracji,
• pojedynczej integracji,
• aktualizacji środowiska.

Refaktoryzacja

Może być właściwa, gdy projekt nadal ma dobrą podstawę, ale wybrane fragmenty kodu utrudniają rozwój.

Nie trzeba wtedy przepisywać całej strony.

Można etapami przebudowywać najbardziej problematyczne obszary.

Nowe wdrożenie

Może być bardziej racjonalne, gdy:

• technologia jest mocno przestarzała,
• motyw nie nadaje się do dalszego rozwoju,
• aktualizacje są bardzo ryzykowne,
• system opiera się na niewspieranych komponentach,
• większość funkcji wymaga przebudowy,
• koszt kolejnych obejść zaczyna przewyższać wartość zachowania istniejącej architektury.

Audyt powinien pomóc podjąć tę decyzję przed rozpoczęciem kosztownych prac, a nie w ich połowie.

Nie próbujemy jednym audytem zastąpić wszystkich pozostałych specjalizacji.

Gdy problemem jest UX i konwersja

Jeżeli użytkownicy nie rozumieją oferty, nie przechodzą do kontaktu albo mają problemy z nawigacją, właściwym rozwiązaniem będzie audyt UX strony WordPress.

Ta usługa analizuje m.in. nawigację, ścieżki konwersji, CTA, mobile i architekturę treści.

Gdy głównym problemem jest bezpieczeństwo

Audyt techniczny może wykazać ryzykowne wersje komponentów lub nieprawidłowości widoczne podczas analizy projektu.

Nie zastępuje jednak szczegółowej analizy podatności, malware, konfiguracji dostępu czy procedur bezpieczeństwa.

Do tego służy osobny audyt bezpieczeństwa WordPress / WooCommerce.

Gdy analizujemy sprzedaż i wydajność WooCommerce

W przypadku sklepu, którego podstawowym problemem są:

• porzucone koszyki,
• ścieżka zakupowa,
• karta produktu,
• checkout,
• szybkość odczuwana przez klientów,

lepszym punktem wyjścia będzie Audyt UX i Performance sklepu WooCommerce.

1. Ustalamy cel audytu

Najpierw określamy, dlaczego analiza jest potrzebna.

Inny zakres będzie potrzebny przed:

• zmianą wykonawcy,
• dużą rozbudową,
• aktualizacją starego projektu,
• refaktoryzacją,
• modernizacją.

2. Zbieramy informacje o projekcie

W zależności od zakresu możemy potrzebować dostępu do:

• WordPressa,
• hostingu,
• repozytorium,
• bazy danych,
• logów,
• stagingu,
• dokumentacji,
• systemów zewnętrznych.

Nie zawsze wymagane są wszystkie dostępy.

3. Analizujemy środowisko

Sprawdzamy technologię, konfigurację, strukturę projektu i zależności.

4. Analizujemy kod i komponenty

Weryfikujemy motyw, wtyczki, kod dedykowany i elementy wpływające na dalszy rozwój.

5. Analizujemy krytyczne funkcje

Jeżeli projekt zawiera integracje lub funkcje dedykowane, sprawdzamy ich konstrukcję i zależności.

6. Oceniamy ryzyka

Problemy rozdzielamy według wpływu i pilności.

Nie każdy błąd wymaga natychmiastowej reakcji.

7. Przygotowujemy rekomendacje

Wyniki nie kończą się na komunikacie: „kod należy poprawić”.

Rekomendacja powinna określać:

• co wymaga działania,
• dlaczego,
• jakie jest ryzyko,
• jaki powinien być priorytet,
• czy element warto poprawić, przebudować czy pozostawić.

8. Omawiamy wyniki

Raport omawiamy z klientem, aby rekomendacje były zrozumiałe również dla osób, które nie pracują bezpośrednio z kodem.

9. Ustalamy możliwe kolejne kroki

Audyt może zakończyć się:

• listą punktowych poprawek,
• planem aktualizacji,
• refaktoryzacją,
• modernizacją,
• przygotowaniem nowego wdrożenia,
• przejęciem projektu do stałego utrzymania.

Zakres raportu zależy od wielkości projektu, ale wyniki powinny umożliwiać podejmowanie decyzji.

Może obejmować:

• opis obecnego środowiska,
• zidentyfikowane problemy,
• ocenę ryzyka,
• listę przestarzałych komponentów,
• problemy architektoniczne,
• uwagi dotyczące integracji,
• zidentyfikowany dług techniczny,
• rekomendacje dotyczące aktualizacji,
• priorytety zmian,
• rekomendowany kierunek dalszego rozwoju.

Kluczowa jest priorytetyzacja.

Lista 150 uwag bez informacji, które trzy z nich mają największy wpływ na projekt, ma ograniczoną wartość biznesową.

Audyt nie powinien zmieniać się w nieograniczoną analizę całej obecności firmy w internecie.

Jeżeli nie zostało to osobno uzgodnione, audyt techniczny nie jest:

• pełnym audytem UX,
• audytem konwersji,
• pełnym audytem SEO,
• testem penetracyjnym,
• pełnym audytem bezpieczeństwa,
• redesignem strony,
• wdrożeniem wszystkich znalezionych poprawek.

Jeżeli podczas analizy zauważymy problem należący do innego obszaru, wskazujemy go i rekomendujemy odpowiedni kolejny krok.

Analizujemy WordPress od strony developerskiej

Audyt wykonuje zespół, który na co dzień rozwija, utrzymuje i przejmuje istniejące projekty WordPress.

Dzięki temu analizujemy nie tylko zgodność z checklistą, ale także praktyczny wpływ problemu na kolejne wdrożenia.

Potrafimy ocenić również projekt po innym wykonawcy

Nie zakładamy, że wszystko trzeba przepisać.

Szukamy rozwiązań, które można zachować, oraz tych elementów, które rzeczywiście stanowią ryzyko.

Software house i WordPress w jednym zespole

W bardziej złożonych projektach możemy przeanalizować nie tylko CMS, ale również:

• kod dedykowany,
• integracje,
• API,
• proces deploymentu,
• środowisko developerskie,
• zależności pomiędzy systemami.

Audyt może być niezależnym etapem

Możesz zamówić analizę przed podjęciem decyzji o dalszej współpracy.

Raport może służyć Webtom.pl, Twojemu zespołowi wewnętrznemu albo innemu wykonawcy.

Możemy wdrożyć rekomendacje

Jeżeli zdecydujesz się kontynuować współpracę, ten sam zespół może przejąć:

• stabilizację projektu,
• refaktoryzację,
• aktualizacje,
• rozwój funkcji,
• integracje,
• dalsze utrzymanie.

Nie istnieje jedna cena odpowiednia dla każdego projektu.

Na zakres analizy wpływają między innymi:

• wielkość strony,
• rodzaj motywu,
• liczba i znaczenie wtyczek,
• ilość kodu dedykowanego,
• liczba integracji,
• stan dokumentacji,
• dostępność repozytorium,
• liczba środowisk,
• wiek projektu,
• wersje technologii,
• zakres bazy danych,
• liczba problemów wymagających głębszej diagnozy.

Prosta strona posiadająca 40 podstron może wymagać mniejszej analizy niż serwis z 10 podstronami, ale rozbudowanymi integracjami i kilkuletnim kodem rozwijanym przez wielu wykonawców.

Dlatego przed wyceną prosimy o podstawowe informacje dotyczące projektu i celu audytu.