Újraírás helyett modernizáció - egy sportklub oldal átvétele

Egy működő rendszer teljes lecserélése ritkán a legjobb lépés. Joel Spolsky már 2000-ben, a Netscape példáján mutatta meg a világnak, mibe kerülhet a teljes újraírás: a két főverzió között közel 3 év telt el, és ezidő alatt a cég piaci részesedése elolvadt.¹ Az ok azóta is ugyanaz: az új rendszernek praktikusan mindent tudnia kell, amit a régi tudott, a soha le nem írt kivételeket és üzleti szabályokat is, ugyanis a rendszer határa nem a kódbázis, hanem a viselkedése.

Amikor egy rendszer gazdát cserél

Gyakori, hogy egy másik csapat által készített szoftvert öröklünk meg. Ilyenkor ritkán a kód minősége a fő kihívás. Sokkal inkább a hiányzó kontextus: miért születtek bizonyos döntések, mi kritikus, és hol vannak rejtett függőségek. Minden rendszer a saját kora terméke, a korábbi csapat az akkori követelmények, határidők és technológiai lehetőségek között dolgozott.

Amikor egy sportegyesület digitális platformjának karbantartására szerződtünk, egy nagyjából 100 000 soros, Symfony 3 alapú PHP-rendszert vettünk át. Egyszerre szolgálta ki a klub híreit, a mérkőzés- és tabellaadatokat, az élő közvetítéseket és a mobilalkalmazás API-jait. Egy ilyen rendszert nem lehet lekapcsolni hónapokra, és ráérősen újraépíteni: az átvétel alatt is működnie kell.

Ahonnan indultunk

Az átvételkor több probléma egyszerre volt jelen. Az adatbázisszerver terhelése kritikus szinten volt, mérkőzésnapokon pedig a szokásosnál nagyságrendekkel nagyobb forgalmat kellett kiszolgálni. A keretrendszer verziója már nem kapott biztonsági frissítéseket, és a függőségek között is akadt elhagyott vagy ismert sérülékenységű csomag. Emellett több funkció és külső integráció hibásan működött, köztük a mobilalkalmazás API-kapcsolatai és a közösségimédia-csatlakozások.

Először megérteni, utána változtatni

Mielőtt bármihez hozzákezdtünk volna, a következő kérdésekre keressük a választ:

1. Mit csinál valójában a rendszer?
2. Hol van a valódi kockázat?
3. Mi működik jól, amit érdemes megtartani?
4. Mit kell változtatni, és milyen ütemben?

A sportegyesületi projektben erre egy nagyjából három hónapos, intenzív stabilizációs és modernizációs szakasz épült. Az alkalmazás mellett az infrastruktúrát és a hálózati oldalt is átvizsgáltuk és optimalizáltuk.

A keretrendszer frissítése önmagában nem cél, de egy biztonsági javításokat már nem kapó alapra hosszú távon nem lehet építeni. A mechanikus átírás nagy részét eszköz végezte, a valódi munka ott kezdődött, ahol az eszköz már nem tudott dönteni: azokon a pontokon, ahol a régi és az új verzió eltérően viselkedik. Ugyanebben a szakaszban váltottuk ki a nem karbantartott csomagokat, és állítottuk helyre azokat a kapcsolatokat, amelyeken keresztül a platform a mobilalkalmazással és a közösségi médiával kommunikál.

Minden komponensnél a megfelelő stratégiát kellett választani: néhány komponens nehezen volt módosítható, de a rendszer sok pontja támaszkodott rá. Ezeket nem írtuk újra azonnal, hanem izoláltuk és stabilizáltuk őket. Ahol viszont a meglévő megoldás már nem tudta követni az igényeket és jól körülhatárolható volt, ott az újratervezés volt az észszerű döntés.

Minden változtatási egység ellenőrizhető volt, mert egy legacy rendszerben egy apró módosítás is több komponensre hathat. Ugyanez a logika működik nagyobb léptékben is: Martin Fowler „strangler fig” mintájában az új részek fokozatosan épülnek a régi köré, a régi elemek pedig egyenként vonulnak vissza.² A modernizáció így nem egyetlen nagy átállási nap, hanem folyamat.

Két másodpercről indultunk

A dinamikus oldalakon válaszidő az átlagos 2 másodpercről a negyedére csökkent, a szerverterhelés jelentősen mérséklődött, és a felesleges komplexitások eltávolításával a kód is átláthatóbbá vált. És folyamat alatt a platform végig működött.

A projekt jól mutatta, hogy a legtöbb problémát nem érdemes nyers erővel megoldani. Rövid távon a gyorsabb, olcsóbb kerülőút csábító, de ha a megfelelő megoldás költségét és hasznát sikerül világosan bemutatni a megrendelőnek, az hosszabb távon mindkét félnek jobban megéri.

Mit változtat ezen az AI?

Ebben a projektben a rendszer működését rögzítő utólagos specifikáció és a tesztek még jelentős részben kézzel készültek. Egy legacy rendszer átvételének régen épp a megértés volt a legdrágább része, és az AI itt hozott érdemi változást. A Thoughtworks Technology Radar 2025 novemberében „Adopt” besorolást adott a GenAI használatának legacy kódbázisok megértésére, vagyis bevett gyakorlatnak tekinti.³ A Morgan Stanley saját eszköze nagyjából 9 millió sor örökölt kódot alakított olvasható specifikációvá, becslésük szerint mintegy 280 000 fejlesztői órát megtakarítva.⁴

Ma egy hasonló átvételnél már AI alapú megoldásokat használjuk a kódbázis feltérképezésére, a dokumentáció elkészítésére, és arra, hogy még a módosítások előtt teszteket írjunk, amelyek rögzítik a rendszer jelenlegi működését. A feltárt összefüggéseket fejlesztő ellenőrzi, és arról, hogy mit tartunk meg és mit cserélünk, továbbra is ember dönt. Mivel az AI az újraírást is olcsóbbá teszi, a jó döntés nem veszít a jelentőségéből. Épp ellenkezőleg: fontosabb, mint valaha.

Nem kell az elejéről újrakezdeni

Egy régi kódbázis, egy gazdátlan rendszer nem feltétlenül menthetetlen. Ami jól működik, azt megtartjuk, amit modernizálni kell, azt pedig fokozatosan korszerűsítjük, és ha egy rész valóban kiváltásra szorul, annak megtervezzük a biztonságos módját. Ha nálatok is van egy rendszer, ami a működés fontos része, de már kevesen értik, hogyan, kezdjük azzal, hogy megértjük, mit csinál valójában. Utána döntsük el közösen, mi marad, mi változik, és milyen ütemben.