A kiindulópont: egy élő, törékeny kódbázis átvétele

Egy másik csapattól éles kódbázist átvenni mindig kockázatos. A Netrisk-nél a kockázat konkrét volt: több üzletkritikus PHP portál — biztosítási összehasonlító, banki, telekommunikációs — amelyek jelentős napi bevételt generáltak, manuális, reprodukálhatatlan és valóban ijesztő deployment folyamatokkal. Az előző csapat fejlesztette a funkciókat; nem fektette be a fejlesztői alapokba, amelyek lehetővé teszik a magabiztos szállítást.

A megbízatásunk egyértelmű volt: stabilizálni a szállítást, bizalmat építeni a kiadások iránt, és lehetővé tenni a növekvő termék-roadmap gyorsabb haladását a további technikai adósság felhalmozása nélkül.

Mit csináltunk — és mit igényelt

• Reprodukálható fejlesztői környezetek. Az első lépés a "nálam működik" mint hibakategória megszüntetése volt. A Vagrant-alapú lokális környezetek, amelyek tükrözték az éles topológiát, egy egész integrációs meglepetés-osztályt szüntettek meg.
• CI/CD quality gate-ekkel. GitLab pipeline-okat építettünk, amelyek minden commit után automatizált teszteket, statikus elemzést és kódminőség-ellenőrzéseket futtattak. A deployment-ek egykattintásossá, auditálhatóvá és visszafordíthatóvá váltak.
• Tesztlefedettség, visszamenőlegesen megírva. Tesztek megírása teszteletlen legacy kódhoz lassú, dicsőségtelen munka. Szisztematikusan végeztük: a legkockázatosabb utakat először, lefedve a napi bevételhez valóban fontos üzleti logikát.
• Monitoring és megfigyelhetőség. Amit nem látunk, azt nem tudjuk javítani. Beállítottuk a hibakövetést és teljesítmény-monitorozást, hogy az éles viselkedés láthatóvá váljon és a csapat korai figyelmeztetést kapjon regressziókról.
• Csapat skálázás. Ahogy a szállítási alap megbízhatóvá vált, 10+ fejlesztőre bővítettük a csapatot, mindegyik képes volt önállóan szállítani anélkül, hogy a másikak munkáját kockáztatta volna.

Mit tanultunk

A Netrisk-ből szerzett legnagyobb felismerés megtévesztően egyszerű volt: a legacy modernizáció szűk keresztmetszete szinte soha nem a technológia. A bizalom az — vagy annak hiánya. A fejlesztők nem refaktorálnak olyan kódot, amelyben nem bíznak. A termékcsapatok nem gyorsítják a roadmap-et olyan platformokon, amelyeket nem tudnak megbízhatóan deployolni. Minden fejlesztésünk végső soron ennek a bizalomnak a kiépítését szolgálta.

A második lecke: a teszt-vezérelt stabilizáció megveri a funkció-befagyasztást. A kísértés törékeny rendszer öröklésekor az, hogy leállítsuk az új funkciók szállítását, amíg az alap szilárd nem lesz. A gyakorlatban ez kereskedelmileg szinte soha nem elfogadható. A fenntartható megközelítés az, hogy a tesztelefedettséget fokozatosan adjuk hozzá, az új funkciók körül és előtt, nem különálló kezdeményezésként.

Mit csinálnánk másképp ma

1. AI-asszisztált tesztgenerálás legacy kódhoz

Visszamenőleges tesztek megírása teszteletlen legacy kódhoz a stabilizációs munka legtöbb munkaerőt igénylő része. Ma az AI eszközök másodpercek alatt értelmező első tervvázlatot generálhatnak tesztesetekből egy adott funkcióhoz vagy endpointhoz — nem helyettesíti a kód megértését, de jelentős gyorsítást jelent. Egy Netrisk léptékű projekten ez százas számú fejlesztési órákat jelent visszanyerve.

2. AI-asszisztált kódbázis onboarding

Egy nagy kódbázis öröklésekor az egyik legköltségesebb tevékenység az új fejlesztők onboardingja — megmagyarázni, mit csinál a dokumentálatlan kód, feltérképezni az adatfolyamokat, megérteni a legacy logikába ágyazott üzleti szabályokat. Ma AI-t használnánk interaktív dokumentációs rétegként: a fejlesztők megkérdezhetik "mit csinál ez a függvény?" és megbízható választ kapnak, drámaian rövidítve a felvételtől a produktív hozzájárulásig eltelt időt.

3. Gyorsabb környezet-standardizálás

Reprodukálható fejlesztői környezetek beállítása 2018-ban jelentős erőfeszítést igényelt. Ma, a Dockerrel mint univerzális alappal és az AI-jal, amely Dockerfile-okat, compose konfigurációkat generál és környezeti problémákat debuggol, ugyanez a munka töredék idő alatt elvégezhető.

4. Korábbi befektetés a megfigyelhetőségbe

Agresszívebben instrumentálnánk az első naptól — nem csak hibakövetést, hanem strukturált naplózást, elosztott nyomkövetést és dashboardokat, amelyek az éles viselkedést olvashatóvá teszik mind a fejlesztők, mind a termék számára.

Mit hagynánk ugyanúgy

• A "bizalom először" filozófiát. Minden döntést azon a lencsén keresztül kell értékelni: megbízhatóbbá és visszafordíthatóbbá teszi-e a kiadásainkat?
• Fokozatos tesztlefedettség a funkciók mellett. Nem újraírás, nem funkció-befagyasztás — steady, mérhető javulás a tesztkészletben, hétről hétre.
• Szoros kommunikáció a termékcsapattal. A stabilizációs munka láthatatlan az üzleti érdekelteknek, ha nem tesszük láthatóvá.

Relevancia ma

A legtöbb vállalat, amely méretarányosan üzemeltet szoftvert, legalább egy Netrisk-szerű helyzetet tart a portfóliójában: egy rendszert, amely működik, bevételt generál, és csendesben technikai adósságot halmoz fel, amely végül mindent lelassít.

A ma elérhető AI eszközökkel ez a munka idővonala jelentősen összesűrűsödik. Ha van egy legacy rendszere, amelyik ilyen figyelmet igényel, vegyük fel a kapcsolatot.