Zmiana przycisku na stronie głównej dostaje wycenę na dwa tygodnie. Aktualizacja wtyczek czeka do poniedziałku, bo w piątek nikt nie chce ryzykować. Nowy programista po tygodniu nadal nie ma działającej kopii strony u siebie. Właściciel firmy widzi rosnące faktury i wyciąga najprostszy wniosek: ludzie pracują za wolno.
Ally Piechowski, która audytuje zespoły programistów, opisała w artykule Why Your Engineering Team Is Slow (It’s the Codebase, Not the People) pięć sygnałów, że tempo hamuje kod, a nie zespół. Pisała o aplikacjach, ale każdy z tych sygnałów ma swój odpowiednik na stronie WordPress i w sklepie WooCommerce. Poniżej każdy z nich razem ze sposobem, jak go zmierzyć na własnej instalacji.
Dlaczego wycena prostej zmiany w WordPressie jest tak wysoka
Pierwszy sygnał autorka nazywa wyceną z przeprosinami. Przy funkcji, która powinna zająć trzy dni, programista mówi “znając ten kod, to pewnie dwa tygodnie” (cytat za Ally Piechowski, tłumaczenie własne), bo wie, że zmiana w jednym miejscu psuje coś w trzech innych. Jej zdaniem wyceny, które stale wychodzą 2-3 razy wyższe niż powinny, nie są problemem szacowania. Zespół wie, ile kosztuje ten kod, tylko przestał to tłumaczyć.
W WordPressie takie ukryte powiązania mają typowe źródła: motyw, który sam generuje część treści zamiast korzystać z bloków, nadpisane szablony WooCommerce skopiowane kilka wersji temu, kilka wtyczek robiących to samo i własny kod wpięty w te same haki.
Jak to zmierzyć: weź z historii zgłoszeń ostatnie dziesięć zmian i zestaw wycenę z wykonaniem. Jeśli rozjazd jest stały i zawsze w tę samą stronę, wycena mówi prawdę o kodzie.
Dlaczego nikt nie chce aktualizować strony w piątek
Drugi sygnał to strach przed wdrożeniem. W artykule pada przykład zespołu z niepisaną zasadą “żadnych wdrożeń po środzie”. Powstała po trzech czwartkowych wdrożeniach z rzędu, które skończyły się awarią w weekend, przy braku planu powrotu, testach, którym nikt nie ufał, i 45-minutowym procesie wdrożenia.
Na stronie WordPress strach przed wdrożeniem wygląda tak: aktualizacje wtyczek klikane na produkcji, brak stagingu albo staging z bazą sprzed pół roku, kopia zapasowa, której nikt nigdy nie przywracał. Skutek jest ten sam co w artykule: zmiany zbierają się w paczki, a każda paczka jest większa i bardziej ryzykowna od poprzedniej.
Jak to zmierzyć: odpowiedz na trzy pytania. Czy istnieje staging z aktualną bazą? Czy ktoś przywrócił kopię zapasową w ostatnim kwartale? Czy są dni, w których zespół nie wdraża? Każde “nie” przy dwóch pierwszych i “tak” przy trzecim podnosi wynik.
Który plik w motywie WordPress jest strefą zakazaną
Trzeci sygnał to plik, którego nikt nie rusza. Autorka szuka go w historii repozytorium: plik, który ciągle pojawia się w git log, ale od lat nikt nie zmienił jego struktury. Wokół takiego pliku zespół buduje obejścia, więc kod rośnie dookoła strefy, której wszyscy unikają.
W WordPressie to najczęściej functions.php motywu, który przez lata urósł do kilku tysięcy linii, albo własna wtyczka firmy, do której każdy dopisał “tylko jedną funkcję”.
Jak to zmierzyć: w repozytorium motywu lub własnej wtyczki uruchom
git log --since="1 year ago" --format= --name-only | sort | uniq -c | sort -rn | head -10Lista pokaże pliki zmieniane najczęściej. Plik na szczycie, w którym zmiany to wyłącznie dopiski na końcu, jest kandydatem na strefę zakazaną. Jeśli motyw nie ma repozytorium, wynik tego sygnału i tak jest wysoki: nie da się ustalić, kto i dlaczego zmienił kod.
Przy okazji policz aktywne wtyczki:
wp plugin list --status=active --format=countSama liczba niczego nie przesądza, ale kilka wtyczek od formularzy, cache albo SEO naraz to częste źródło konfliktów, które wydłużają każdą zmianę.
Czy wysokie pokrycie testami chroni checkout WooCommerce
Czwarty sygnał autorka nazywa kłamstwem pokrycia. Panel pokazuje zdrowy procent pokrycia testami, a trzy modele, które obsługują pieniądze, nie mają ani jednego testu. Do tego testy na serwerze CI trwały 40 minut, więc programiści przestali uruchamiać je u siebie. Jej test jest prosty: kiedy ostatnio test złapał błąd, zanim trafił na produkcję?
Sklep WooCommerce bez żadnego testu ma ten sam problem w ostrzejszej postaci. Ścieżka pieniędzy to koszyk, checkout, bramka płatności i e-mail z potwierdzeniem zamówienia. Jeśli po każdej aktualizacji ktoś ręcznie składa zamówienie testowe, sklep ma test, tylko ręczny i zależny od pamięci jednej osoby.
Jak to zmierzyć: sprawdź, czy istnieje jakikolwiek automatyczny test składający zamówienie, i zapytaj, kiedy ostatnio coś wyłapał.
Ile trwa przygotowanie nowego programisty do pracy przy stronie
Piąty sygnał to czas do pierwszej zmiany: ile trwa, zanim nowa osoba wdroży prawdziwą poprawkę. Według autorki w zdrowym projekcie to dzień albo dwa, w niezdrowym widziała dwa tygodnie i więcej. Przyczyną bywa zbutwiała konfiguracja: nieaktualne skrypty instalacyjne, zepsute dane startowe, nieopisane zmienne środowiskowe.
Przy WordPressie lista jest podobna: brak repozytorium, zrzut bazy, który trzeba wyprosić od hostingu, klucze API zapisane tylko na produkcji, wtyczki premium bez licencji deweloperskiej.
Jak to zmierzyć: postaw od zera działającą kopię lokalną, na przykład w wp-env, i zanotuj czas oraz każdą rzecz, o którą trzeba było kogoś prosić.
Jak policzyć wynik pięciu sygnałów
Autorka ocenia każdy sygnał w skali od 0 do 2. Wynik 4 lub więcej oznacza, że kod wymaga bezpośredniej inwestycji, zanim pomogą inne zmiany. Od 7 punktów, jak pisze, zaczyna się większość jej zleceń.
| Sygnał | 0 punktów | 2 punkty |
|---|---|---|
| Wycena z przeprosinami | wyceny zgadzają się z wykonaniem | stały rozjazd w górę |
| Strach przed wdrożeniem | staging, plan powrotu, wdrożenia w dowolny dzień | zmiany na produkcji, brak sprawdzonej kopii |
| Plik, którego nikt nie rusza | żaden plik nie dominuje historii | jeden plik obrasta dopiskami |
| Pokrycie testami | test złapał ostatnio błąd przed produkcją | checkout bez żadnego testu |
| Czas do pierwszej zmiany | kopia lokalna w godzinę | kilka dni i prośby o dostęp |
Same punkty są umowne, liczy się kolejność sygnałów. Autorka radzi zacząć od sygnału z najwyższym wynikiem, poświęcić mu skupiony dwutygodniowy sprint i zmierzyć coś konkretnego, na przykład częstotliwość wdrożeń albo trafność wycen.
Dlaczego najlepszy programista przy stronie pracuje najwolniej
Autorka zwraca uwagę na paradoks: przy takim kodzie najbardziej zwalniają najlepsi. Widzą ryzyko, wiedzą, że zmiana w tym pliku może zepsuć tamten proces, więc działają ostrożnie, piszą kod obronny i zawyżają wyceny. Mniej doświadczona osoba bywa szybsza, bo nie widzi zagrożenia, a potem powoduje awarię, po której wszyscy stają się jeszcze ostrożniejsi.
Przykład z jej artykułu: dwóch programistów przez tydzień dodawało eksport CSV do panelu administracyjnego, choć samej pracy było może na dzień. Reszta czasu poszła na zrozumienie istniejącego kodu na tyle, żeby bezpiecznie go zmienić. Ten narzut nie pojawia się w żadnym raporcie, więc kierownictwo widzi tylko powolnych ludzi.
Czy przebudowa strony od zera rozwiąże problem wolnych zmian
Nie zawsze. Autorka opisuje klienta, u którego w ciągu dziesięciu lat przewinęło się sześć zespołów programistów. Za każdym razem wzorzec był ten sam: nacisk na nowe funkcje, odkładane porządki, aż kod zaczynał wyglądać na nie do uratowania. Wtedy ktoś proponował przepisanie albo wydzielenie mikroserwisów, co pogarszało sprawę, bo zamiast jednego systemu były dwa, a stary nadal działał.
Na WordPressie ten scenariusz wygląda znajomo: nowy motyw stawiany obok starego, frontend headless, który przejmuje część stron, podczas gdy reszta nadal idzie przez stary szablon, albo nowy sklep, do którego połowa integracji nigdy nie zostaje przeniesiona. Przebudowa ma sens, gdy wiadomo, który sygnał hamuje i czy nowa architektura go usuwa. Bez tego przenosi się stare przeszkody do nowego kodu.
Co naprawić najpierw przy każdym sygnale
Autorka podaje dla każdego sygnału inny pierwszy krok. Poniżej jej zalecenia i ich odpowiednik na stronie WordPress.
- Wycena z przeprosinami: rozdzielić moduły o najszerszym zasięgu skutków. W WordPressie to zwykle rozbicie
functions.phpna osobne pliki albo wtyczkę z jasno nazwanymi funkcjami i wycofanie nadpisanych szablonów WooCommerce, których nikt nie aktualizował. - Strach przed wdrożeniem: szybszy proces wdrożenia, automatyczny powrót do poprzedniej wersji i mniejsze paczki zmian. W WordPressie: staging z aktualną bazą, wdrażanie kodu z repozytorium zamiast przez FTP i przetestowane przywracanie kopii zapasowej.
- Plik, którego nikt nie rusza: najpierw testy wokół niego, potem zmiany struktury. Dla motywu wystarczy na start kilka testów sprawdzających, czy kluczowe strony się renderują.
- Pokrycie testami: test ścieżki pieniędzy. W WooCommerce to jeden automatyczny test, który na stagingu składa zamówienie i sprawdza, czy przyszedł e-mail z potwierdzeniem.
- Czas do pierwszej zmiany: według autorki jeden dzień poświęcony na skrypt instalacyjny i opis środowiska zwraca się szybko. W WordPressie: plik konfiguracyjny wp-env w repozytorium, skrypt pobierający zanonimizowany zrzut bazy i lista zmiennych środowiskowych.
Gdy rozmawiasz o tym z zarządem albo z klientem, konkret działa lepiej niż ogólnik. Autorka zestawia dwa zdania: “każda funkcja trwa mniej więcej dwa razy dłużej przez powiązania w tych trzech modułach” to zupełnie inna rozmowa niż narzekanie na dług techniczny (cytat za Ally Piechowski, tłumaczenie własne).
Czy AI przyspieszy zmiany na starej stronie WordPress
Kuszące jest założenie, że agent AI przepisze problem. Autorka przytacza badanie METR z 2025 roku: 16 doświadczonych programistów open source pracowało z narzędziami AI o 19% wolniej w repozytoriach, które dobrze znali. Autorka dodaje, że pisanie kodu nigdy nie było wąskim gardłem.
Agent trafia na te same ukryte zależności co człowiek, tylko szybciej generuje kolejne obejście wokół pliku, którego nikt nie rusza. Pięć sygnałów warto więc obniżyć, zanim wpuścisz AI do repozytorium.
Od czego zacząć naprawę wolnej strony WordPress
Przy wyniku od czterech punktów w górę zacznij od usunięcia przeszkody z najwyższą oceną. Nowy programista albo nowy motyw trafią na te same przeszkody. Zwykle jest to staging z aktualną bazą i repozytorium dla motywu, bo bez nich nie da się bezpiecznie ruszyć żadnego innego sygnału.
Tak działa nasz sprint naprawczy WooCommerce: płatna diagnoza, poprawki według priorytetu, wdrożenie najpierw na stagingu i pisemny raport z tym, co zmieniono i dlaczego. Jeśli zastanawiasz się, czy stronę w ogóle opłaca się jeszcze naprawiać, zacznij od audytu gotowości do przebudowy albo przewodnika kiedy przebudować stronę internetową.
