Technikai adósság

Költségoldal

A technikai adósság a fejlesztési órákban látszik meg először. Ugyanaz a feladat az egyik oldalon 2 óra, a másikon 8. A különbség nem a fejlesztő képessége, hanem az, hogy mennyi mindent kell megkerülni.

Kockázati oldal

A nem frissíthető rendszer előbb-utóbb támadási felület lesz. A WordPress-ökoszisztéma sérülékenységeinek nagy része ismert és foltozott, csak épp az adott oldalon nincs telepítve a folt. Innen vezet az út a SEO-spam feltöréshez és az index-szennyezéshez.

Sebesség

Minden réteg hozzáad. A 12 plugin együtt 30 CSS- és JS-fájlt tölt be, ebből 20 az adott oldalon feleslegesen fut. Ez közvetlenül látszik az LCP és a TBT értékeiben, és a Core Web Vitals mérésében.

Üzleti oldal

A legdrágább következmény nem technikai. Az adósság miatt a marketing ötletei lassabban valósulnak meg. Ha egy landing oldal két hét helyett hat hét, akkor a kampány csúszik. Ez a lassulás a legtöbb helyen soha nem kerül be a költségvetésbe.

Kikre vonatkozik

• Élő üzleti oldalak, amelyek 3 évnél régebbi kódbázison futnak
• Webshopok, ahol a fizetési és szállítási modulok verziófüggők
• Sablonból indult KKV-oldalak, amelyeket azóta több fejlesztő is bütykölt
• Több kézen átment projektek, ahol nincs dokumentáció és átadás

Kikre kevésbé

• Friss, 1 évnél fiatalabb oldalak karbantartási szerződéssel: náluk a megelőzés a téma
• Statikus generátorral készült oldalak, ahol nincs futó CMS-réteg
• Staging- és tesztkörnyezetek: ott az adósság nem üzleti kockázat
• Kampányra épült, tervezetten eldobható microsite-ok

A méret nem véd. Nagy, jól menő webshopoknál is látni 2018-as PHP-t, csak ott a bevétel elfedi a problémát egy ideig.

Lépések

1. Nézd meg a futó verziókat. A CMS-felismerés és a szerverfejlécek elárulják a PHP- és CMS-verziót. WordPressnél az admin Állapot menüpontja (Eszközök > Állapot) ezt kiírja.
2. Számold meg az aktív pluginokat. 20 felett szinte biztosan van átfedés és holt funkció.
3. Nézd meg, mikor frissültek. Ha egy plugin 2 éve nem kapott frissítést, az elhagyott.
4. Nyisd meg a devtools Network fülét. Számold össze a CSS- és JS-kéréseket egy sima aloldalon.
5. Kérdezd meg, van-e staging. Ha nincs, minden módosítás élesben történik.
6. Keresd a sablonmódosítást. Ha a téma nem gyerektéma, a következő frissítés mindent felülír.
7. Futtass le egy teljes weboldal-auditot, hogy a tünetek egy helyen legyenek.

Jó jel

• Támogatott PHP-verzió, aktív CMS-főverzió
• Gyerektéma vagy saját téma, verziókövetésben
• 15 alatti aktív plugin-szám, mind karbantartott
• Létező staging-környezet és mentési rend
• Egy forrásból származó strukturált adat

Rossz jel

• Lejárt támogatású PHP a szerveren
• "Ne frissítsd, mert szétesik" mondat a dokumentációban vagy a fejlesztőtől
• Két SEO-plugin egyszerre aktív
• Közvetlenül szerkesztett core- vagy sablonfájlok
• Nincs mentés, vagy senki nem tudja, hol van

WordPress

1. Állíts be staging-környezetet, mielőtt bármihez hozzányúlsz.
2. Készíts teljes mentést fájlokkal és adatbázissal együtt.
3. Deaktiváld a pluginokat egyesével, és nézd meg, mi hiányzik valójában.
4. Emeld a PHP-t támogatott verzióra a tárhely paneljén, először stagingen.
5. Ha a téma módosított, hozz létre gyerektémát, és vidd át bele a testreszabást.
6. Vezesd be a rendszeres frissítési ciklust: havonta egyszer, staging után élesben.

Shopify

1. Nézd át a telepített appokat, és távolítsd el a nem használtakat.
2. Keresd meg az eltávolított appok maradék kódját a theme.liquid fájlban.
3. Használj téma-duplikátumot a módosításokhoz, ne az élőt szerkeszd.
4. Frissítsd a témát a hivatalos verzióra, ha régi Online Store 1.0-n vagy.

Unas

1. Ellenőrizd, melyik sablonverzión fut a bolt.
2. Gyűjtsd össze az egyedi HTML- és JS-betoldásokat a szerkesztőből.
3. Kérj sablonfrissítést, és előtte mentsd ki a testreszabásokat.
4. Az egyedi kódot vidd át a hivatalosan támogatott beszúrási pontokra.

Shoprenter

1. Nézd meg, régi vagy új generációs sablonon fut-e a bolt.
2. Listázd az aktív bővítményeket és a bekötött külső scripteket.
3. A sablonfrissítés előtt exportáld a saját template-módosításokat.
4. Az elavult, nem támogatott modulokat cseréld natív funkcióra.

Egyedi fejlesztés

1. Tedd verziókövetésbe a kódot, ha még nincs benne.
2. Frissítsd a futtatókörnyezetet és a függőségeket támogatott verzióra.
3. Írd le, mi hova van kötve: enélkül minden átadás újrakezdés.
4. Vezess be automatikus mentést és egy egyszerű deploy-folyamatot.

Mikor érdemes újraépíteni

Nincs univerzális határ, de a döntéshez ezeket mérd:

• Költség: ha a következő 12 hónap karbantartása eléri egy új oldal árának felét, számolj újra.
• Kockázat: ha nem frissíthető a rendszer, a kockázat idővel nő, nem csökken.
• Sebesség: ha egy egyszerű módosítás rendszeresen napokat vesz el, a lassulás önmagában költség.
• AI-olvashatóság: ha a HTML-struktúra és a strukturált adat nem hozható rendbe a sablon átírása nélkül, az érv az újraépítés mellett szól.

Mit néz ebből a riport

Az audit a futó verziókat, a felismert technológiákat és a kiszolgált HTML állapotát vizsgálja. Ezekből áll össze a pontszám és a fejlesztői ítélet: még érdemes-e a meglévő alapra fejleszteni, vagy gazdaságosabb új alapokra helyezni. A riport nem dönt helyetted, hanem számokat ad a döntéshez.

• Az adósságot hibának hiszik, ezért csak akkor foglalkoznak vele, ha valami már látványosan elromlott.
• A frissítést halogatják, így a végén nem egy, hanem öt főverziót kellene átugrani egyszerre.
• Plugin-nal oldanak meg mindent, és a tizedik bővítménynél már senki nem tudja, melyik mit csinál.
• Nincs staging, ezért minden kísérlet éles forgalmon fut, és a hiba azonnal ügyfelet érint.
• A sablont közvetlenül szerkesztik, így a következő témafrissítés visszaállítja az összes munkát.
• Csak a látványt újítják fel, a mögötte lévő elavult rendszert nem, és a kamat megmarad.
• Az újraépítést érzelmi alapon döntik el, nem költség- és kockázatszámok mentén.

A futó verziók és a betöltött erőforrások gyorsan kiderülnek parancssorból.

# Mit árul el a szerver a technológiáról
curl -sI https://pelda.hu | grep -Ei 'server|x-powered-by|x-generator'

# WordPress-verzió a generator metából
curl -s https://pelda.hu | grep -i 'name="generator"'

# Hány CSS- es JS-fajlt tolt be egy aloldal
curl -s https://pelda.hu/szolgaltatasok | grep -oE '(href|src)="[^"]+\.(css|js)' | wc -l

Tipikus kimenet egy elhanyagolt oldalon:

Server: Apache/2.4.29 (Ubuntu)
X-Powered-By: PHP/7.4.33
<meta name="generator" content="WordPress 5.8.2" />
41

A PHP 7.4 és a WordPress 5.8 is jóval a támogatott verziók mögött van. A 41 külön erőforrás-kérés a plugin-rétegek biztos jele. Ugyanez a devtools Network fülén is látszik, ha a szűrőt CSS-re és JS-re állítod.

{
  "cms": "WordPress",
  "php": "7.4.33",
  "aktiv_pluginok": 27,
  "gyerektema": false,
  "staging": false,
  "dontesi_jelzes": "ujraepites_merlegelendo"
}

Ez a fajta összegzés az, amiből a döntés megszületik. Egyetlen sor sem önmagában súlyos, a kombináció az.