En ny knapp på forsiden får et estimat på to uker. Oppdateringen av utvidelser venter til mandag, fordi ingen vil ta sjansen på en fredag. Etter en uke har den nye utvikleren fortsatt ikke en fungerende kopi av nettsiden på sin egen maskin. Daglig leder ser fakturaene vokse og trekker den enkleste konklusjonen: folkene jobber for sakte.
Ally Piechowski, som gjennomgår utviklingsteam, beskrev i artikkelen Why Your Engineering Team Is Slow (It’s the Codebase, Not the People) fem tegn på at det er koden og ikke teamet som bremser tempoet. Hun skrev om applikasjoner, men hvert av tegnene har en motpart på en WordPress-side og i en WooCommerce-butikk. Her går vi gjennom dem ett for ett, med en måte å måle hvert av dem på din egen installasjon.
Hvorfor er estimatet for en enkel WordPress-endring så høyt
Det første tegnet kaller forfatteren estimatet med unnskyldning. For en funksjon som burde ta tre dager, sier utvikleren: “Slik jeg kjenner denne koden, tar det nok rundt to uker” (Ally Piechowski, egen oversettelse). Utvikleren vet at en endring ett sted ødelegger noe tre andre steder. Ifølge forfatteren er estimater som stadig blir 2-3 ganger høyere enn de burde, ikke et estimeringsproblem. Teamet vet hva denne koden koster, det har bare sluttet å forklare det.
I WordPress har slike skjulte koblinger typiske kilder: et tema som lager deler av innholdet selv i stedet for å bruke blokker, overstyrte WooCommerce-maler kopiert for flere versjoner siden, flere utvidelser som gjør det samme, og egen kode koblet på de samme krokene.
Slik måler du det: hent de ti siste endringene fra sakshistorikken og sett estimatet opp mot faktisk tidsbruk. Er avviket stabilt og alltid i samme retning, forteller estimatet sannheten om koden.
Hvorfor vil ingen oppdatere nettsiden på en fredag
Det andre tegnet er frykten for å publisere. Artikkelen nevner et team med den uskrevne regelen “ingen publiseringer etter onsdag”. Den kom etter at tre publiseringer på rad på torsdager endte med driftsavbrudd i helgen, uten noen plan for å gå tilbake, med tester ingen stolte på og en publiseringsprosess på 45 minutter.
På en WordPress-side ser denne frykten slik ut: oppdateringer av utvidelser klikkes rett i produksjon, det finnes ikke noe testmiljø, eller testmiljøet har en database fra et halvt år siden, og sikkerhetskopien har aldri blitt gjenopprettet av noen. Resultatet er det samme som i artikkelen: endringene hoper seg opp i pakker, og hver pakke er større og mer risikabel enn den forrige.
Slik måler du det: svar på tre spørsmål. Finnes det et testmiljø med oppdatert database? Har noen gjenopprettet en sikkerhetskopi siste kvartal? Finnes det dager da teamet ikke publiserer? Hvert “nei” på de to første og et “ja” på det tredje øker poengsummen.
Hvilken fil i et WordPress-tema er forbudt sone
Det tredje tegnet er filen ingen rører. Forfatteren leter etter den i historikken til repoet: en fil som stadig dukker opp i git log, men der ingen har endret strukturen på mange år. Rundt en slik fil bygger teamet omveier, så koden vokser rundt en sone alle unngår.
I WordPress er dette oftest temaets functions.php, som over årene har vokst til flere tusen linjer, eller firmaets egen utvidelse, der alle har lagt til “bare én funksjon til”.
Slik måler du det: kjør dette i repoet til temaet eller den egne utvidelsen:
git log --since="1 year ago" --format= --name-only | sort | uniq -c | sort -rn | head -10Listen viser filene som endres oftest. Filen øverst, der endringene bare er tillegg nederst, er en kandidat til forbudt sone. Har temaet ikke noe repo, er poengsummen for dette tegnet høy uansett: det er umulig å finne ut hvem som endret koden, og hvorfor.
Tell samtidig de aktive utvidelsene:
wp plugin list --status=active --format=countTallet alene avgjør ingenting, men flere skjema-, hurtigbuffer- eller SEO-utvidelser samtidig er en vanlig kilde til konflikter som gjør hver endring tregere.
Beskytter høy testdekning WooCommerce-kassen
Det fjerde tegnet kaller forfatteren testdekningsløgnen. Panelet viser en sunn prosent for testdekning, mens tre modeller som håndterer penger, ikke har en eneste test. I tillegg tok testene på CI-serveren 40 minutter, så utviklerne sluttet å kjøre dem lokalt. Testen hennes er enkel: når fanget en test sist en feil før den nådde produksjon?
En WooCommerce-butikk helt uten tester har det samme problemet i en skarpere form. Betalingsflyten er handlekurven, kassen, betalingsløsningen og e-posten med ordrebekreftelse. Hvis noen legger inn en testordre for hånd etter hver oppdatering, har butikken en test, bare en manuell en som avhenger av hukommelsen til én person.
Slik måler du det: sjekk om det finnes noen automatisk test som legger inn en ordre, og spør når den sist fanget noe.
Hvor lang tid tar det å få en ny utvikler i gang med en WordPress-side
Det femte tegnet er tiden til første endring: hvor lang tid det tar før en ny person publiserer en ekte rettelse. Ifølge forfatteren er det en dag eller to i et sunt prosjekt, mens hun har sett to uker og mer i usunne. Årsaken er ofte et oppsett som har forfalt: utdaterte installasjonsskript, ødelagte startdata, udokumenterte miljøvariabler.
Med WordPress ser listen lik ut: ikke noe repo, en databasedump man må tigge om hos vertsleverandøren, API-nøkler som bare ligger i produksjon, premium-utvidelser uten utviklerlisens.
Slik måler du det: sett opp en fungerende lokal kopi fra bunnen, for eksempel i wp-env, og noter tiden og alt du måtte be noen om.
Hvordan regner man ut poengsummen for de fem tegnene
Forfatteren gir hvert tegn mellom 0 og 2 poeng. En sum på 4 eller mer betyr at koden trenger en direkte investering før andre tiltak hjelper. Fra 7 poeng, skriver hun, starter de fleste av oppdragene hennes.
| Tegn | 0 poeng | 2 poeng |
|---|---|---|
| Estimat med unnskyldning | estimatene stemmer med tidsbruken | stabilt avvik oppover |
| Frykt for å publisere | testmiljø, plan for å gå tilbake, publisering alle dager | endringer rett i produksjon, ingen testet sikkerhetskopi |
| Filen ingen rører | ingen fil dominerer historikken | én fil vokser med tillegg |
| Testdekning | en test fanget nylig en feil før produksjon | kassen uten noen test |
| Tid til første endring | lokal kopi på en time | flere dager og forespørsler om tilgang |
Selve poengene er vilkårlige, det er rekkefølgen på tegnene som teller. Forfatteren anbefaler å starte med tegnet med høyest poengsum, gi det en fokusert sprint på to uker og måle noe konkret, for eksempel hvor ofte teamet publiserer eller hvor treffsikre estimatene er.
Hvorfor jobber den beste utvikleren på nettsiden tregest
Forfatteren peker på et paradoks: med slik kode er det de beste som bremser mest. De ser risikoen, de vet at en endring i denne filen kan ødelegge den prosessen, så de jobber forsiktig, skriver defensiv kode og estimerer høyere. En mindre erfaren person er av og til raskere fordi vedkommende ikke ser faren, og forårsaker så et avbrudd som gjør alle enda mer forsiktige.
Et eksempel fra artikkelen hennes: to utviklere brukte en uke på å legge til CSV-eksport i administrasjonspanelet, selv om selve arbeidet kanskje var en dag. Resten av tiden gikk med til å forstå den eksisterende koden godt nok til å endre den trygt. Denne merkostnaden dukker ikke opp i noen rapport, så ledelsen ser bare trege folk.
Løser det å bygge nettsiden på nytt problemet med trege endringer
Ikke alltid. Forfatteren beskriver en kunde som hadde seks utviklingsteam innom på ti år. Hver gang var mønsteret det samme: press for nye funksjoner, opprydding som ble utsatt, til koden begynte å se ut som den ikke kunne reddes. Da foreslo noen å skrive alt på nytt eller skille ut mikrotjenester, noe som gjorde vondt verre, for i stedet for ett system fikk man to, og det gamle var fortsatt i drift.
På WordPress kjenner man igjen dette: et nytt tema satt opp ved siden av det gamle, en headless frontend som tar over noen av sidene mens resten fortsatt går gjennom den gamle malen, eller en ny butikk der halvparten av integrasjonene aldri blir flyttet over. En ny oppbygging gir mening når du vet hvilket tegn som bremser, og om den nye arkitekturen fjerner det. Uten det flytter de gamle hindringene inn i den nye koden.
Hva bør man rette først for hvert tegn
Forfatteren gir et eget første steg for hvert tegn. Her er rådene hennes og hva de tilsvarer på en WordPress-side.
- Estimat med unnskyldning: løs opp modulene som får følger flest steder. I WordPress betyr det som regel å dele opp
functions.phpi egne filer eller en utvidelse med tydelig navngitte funksjoner, og å fjerne overstyrte WooCommerce-maler ingen har oppdatert. - Frykt for å publisere: en raskere publiseringsprosess, automatisk tilbakerulling og mindre pakker med endringer. I WordPress: et testmiljø med oppdatert database, kode som publiseres fra repoet i stedet for over FTP, og en testet gjenoppretting av sikkerhetskopien.
- Filen ingen rører: først tester rundt den, deretter endringer i strukturen. For et tema holder det til å begynne med noen tester som sjekker at de viktigste sidene vises.
- Testdekning: en test av betalingsflyten. I WooCommerce er det én automatisk test som legger inn en ordre i testmiljøet og sjekker at bekreftelsen kom på e-post.
- Tid til første endring: ifølge forfatteren betaler én dag brukt på å fikse oppsettet seg selv. I WordPress: en wp-env-konfigurasjonsfil i repoet, et skript som henter en anonymisert databasedump, og en liste over miljøvariabler.
Når du tar dette opp med ledelsen eller en kunde, fungerer det konkrete bedre enn det generelle. Forfatteren setter to utsagn opp mot hverandre: “hver funksjon tar omtrent dobbelt så lang tid på grunn av koblingene i disse tre modulene” er en helt annen samtale enn å klage over teknisk gjeld (Ally Piechowski, egen oversettelse).
Gjør AI endringer på en gammel WordPress-side raskere
Det er fristende å tro at en AI-agent skal skrive problemet bort. Forfatteren viser til en METR-studie fra 2025: 16 erfarne åpen kildekode-utviklere jobbet 19% saktere med AI-verktøy i repoer de kjente godt. Hun legger til at skrivingen av kode aldri var flaskehalsen.
Agenten møter de samme skjulte avhengighetene som et menneske, den lager bare neste omvei rundt filen ingen rører, raskere. Få derfor ned de fem tegnene før du slipper AI inn i repoet.
Hvor begynner man når en WordPress-side er treg å endre
Med fire poeng eller mer begynner du med å fjerne hindringen med høyest poengsum. En ny utvikler eller et nytt tema vil møte de samme hindringene. Som regel er det et testmiljø med oppdatert database og et repo for temaet, for uten dem kan ingen av de andre tegnene tas tak i på en trygg måte.
Slik fungerer vår redningssprint for WooCommerce: en betalt diagnose, rettelser etter prioritet, publisering i testmiljøet først og en skriftlig rapport om hva som ble endret og hvorfor. Lurer du på om nettsiden i det hele tatt er verdt å reparere, start med klarhetsrevisjonen før ombygging eller veiledningen om når du bør bygge nettsiden på nytt.
