Legacy-kód refaktorálása a Delphi-ben: kockázatok csökkentése, karbantarthatóság növelése, üzem biztosítása

Aki egy üzletileg kritikus Delphi-alkalmazást üzemeltet, ismeri a feszültséget: stabilan fut, lefedi a kulcsfolyamatokat és mélyen integrált az adatbázisokba, interfészekbe és munkafolyamatokba. Ugyanakkor a változtatási ráfordítás és a kockázat minden Release-szel nő, mert évek alatt kompromisszumok, kivételes esetek és függőségek halmozódtak fel. Itt kezdődik a Legacy-Code in Delphi refactoren: nem „Rewrite” projektként, hanem kontrollált átalakításként a működő rendszerben – mérhető hatásokkal a karbantarthatóságra, a Release-biztonságra és az üzemeltetésre.

Gyakorlatban a refaktorálás ritkán Delphi-en bukik meg, sokkal inkább az átláthatóság hiányán: mi szakmailag kritikus? Hol vannak technikai adósságok (azaz strukturális hiányosságok, amelyek későbbi módosításokat drágítanak)? Mely részek érhetők el karbantartási ablakokban, és melyek nem? És hogyan lehet megakadályozni, hogy a „rendetrakás” új hibákat vagy teljesítményproblémákat okozzon a produkcióban? Ez a bejegyzés egy gyakorlati megközelítést ismertet, amely magával viszi az IT-vezetést és az adminisztrációt: az állapotfelméréstől az architektúra- és adatkérdéseken át a tesztekig, release-folyamatig és biztonsági kérdésekig.

Mit jelent valójában a „Legacy” az Delphi-projektekben?

A „Legacy”-t gyakran az „öreg” szinonimájaként használják. Vállalati kontextusban a legacy-kód elsősorban olyan kód, amelynek a módosítási kockázata magas, és viselkedése csak részben magyarázható. Ez lehet egy VCL-alkalmazás (Visual Component Library, klasszikus Windows-asztali UI), de lehet szolgáltatás, ütemező vagy kliens-szerver rendszer is.

Tipikus legacy-jellegzetességek Delphi-környezetekben:

• Erős csatolás: UI, adatelérés és üzleti logika keverednek; a változtatások mellékhatásokat vonnak maguk után.
• Implicit szabályok: az üzleti logika eseményekben, globális változókban vagy adatbázis-triggerben van, nem tiszta modulokban.
• Elavult adathozzáférések: pl. BDE (Borland Database Engine) vagy proprietáris komponensek; hiányzó pooling-/timeout-stratégiák.
• Inkonzisztens hibakezelés: kivételeket elnyomnak, üzenetek nem kerülnek a központi naplózásba.
• Build- és release-törékenység: függőségek, útvonalproblémák, eltérő fordítóbeállítások, manuális utómunkálatok.
• Hiányzó tesztek: a tudás a fejekben vagy a tapasztalt felhasználók „kattintás-szekvenciáiban” él.

Fontos: a legacy-kód nem feltétlenül „rossz”. Gyakran az időnyomás, a technológiai ciklusok és a pragmatikus döntések eredménye. A refaktorálás ilyenkor befektetés a irányíthatóságba – az üzemeltetés, a biztonság, a megfelelés és a változtatási sebesség szempontjából.

Refactoring vs. Rewrite: Mi változik az üzemeltetés és a kockázat szempontjából

Egy Rewrite (újrafejlesztés) tiszta indulást ígér, de gyakran hosszú párhuzamos üzemet, új hibakategóriákat és magas migrációs kockázatot hoz magával. A refaktorálás ezzel szemben az inkrementális javítást célozza folyamatos szállíthatóság mellett. Az IT-üzemeltetés és a szakmai területek számára ez gyakran a döntő különbség: a rendszer produktív marad, és a javítások átlátható csomagokban érkeznek.

Gyakorlati elhatárolás:

• Refaktorálás: a szerkezet javul, a külső viselkedés változatlannak marad. Fókusz: karbantarthatóság, tesztelhetőség, stabilitás, teljesítménytartalékok.
• Átszervezés/modernizálás: kiegészítő célzott viselkedésváltoztatások, pl. új Schnittstellen, új adatbázis, új platformcélok.
• Rewrite: új kódbázis, általában új UI/architektúra; megköveteli az adatok, folyamatok, Schnittstellen migrálását – gyakran „Big Bang” vagy hosszú átmeneti időszak.

A döntéshozók számára ez a pont központi: a Refactoring nem öncél, hanem egy eszköz a Change-Risiken csökkentésére. Ez közvetlenül üzemeltetési szempontból releváns, ha az alkalmazás 24/7-folyamatokat, a gyártáshoz közeli eljárásokat vagy ügyfélközeli portálokat befolyásol.

Legacy-kód refaktorálása Delphi-ban: kezdés egy megbízható állapotfelméréssel

Az első lépés nem egy eszköz, hanem a kockázatokra és célokra vonatkozó közös szemlélet. Enélkül a Refactoring könnyen abba fullad, hogy „ma itt rendet teszünk” — és ezt üzemeltetésben nehéz igazolni.

1) Kritikusság és üzemeltetési valóság feltárása

Térképezze fel, mely részek valóban üzleti-kritikusak: napi zárás, Schnittstellen az ERP/DMS/CRM felé, termelési adatgyűjtés, számlázás, jogosultságkezelés. Egészítse ki üzemeltetési paraméterekkel: karbantartási ablakok, rollback-lehetőségek, monitoring, adatmennyiség, késleltetési követelmények.

Hasznos kérdések:

• Mely funkcióknak kell részleges kiesések esetén is működniük (degradációs képesség)?
• Hol vannak „Single Points of Failure” (pl. egy központi ütemező)?
• Mely adatok érzékenyek szabályozási vagy adatvédelmi szempontból?
• Mely integrációk a leginkább hibára hajlamosak (fájlimportok, TCP/IP, SOAP/REST, Messaging)?

2) A technikai adósság láthatóvá tétele – nem csak a kódstílus

Delphi-projektekben a technikai adósság gyakran architekturális: globális állapotok, ciklikus unit-függőségek, nehezen tesztelhető adat-hozzáférések, vagy UI-események mint orchesztráció. A metrikák (pl. komplexitás, unit-méret, függőségi gráf) segítenek, de csak akkor értékesek, ha intézkedésekre fordítják őket.

Egy gyakorlatias keret a 2×2 vizsgálat:

• Gyakran változó & kockázatos: legmagasabb prioritás a refaktorálás számára.
• Gyakran változó & kevésbé kockázatos: folyamatok/tesztek javítása, kisebb struktúrális intézkedések.
• Ritkán változó & kockázatos: stabilizálás/biztosítás (tesztek, naplózás), nem feltétlenül a „szépítgetés”.
• Ritkán változó & kevésbé kockázatos: szándékosan érintetlenül hagyni.

3) Függőségek feltérképezése: adatok, Schnittstellen, futtatási környezet

Az adminisztráció és a projektfelelősök számára döntő fontosságú, mi függ a kódon kívül: adatbázis-backendek, ODBC/OLE DB, fájlmegosztások, nyomtatási és PDF-folyamatok, COM/ActiveX, Office-automatizálás, Windows-szolgáltatások, ütemezett feladatok, tanúsítványok, proxy-konfigurációk.

Gyakran itt keletkeznek a refaktorálás költségei közvetetten: egy „kicsi” változtatás új telepítőlogikát, új jogosultságokat vagy új tűzfalszabályokat kényszeríthet ki. Ezeket a mellékhatásokat korán egy technikai térképen kell dokumentálni.

Tipikus problématerületek Delphi-legacy rendszerekben és célzott kezelési módjuk

A Refactoring uralhatóvá válik, ha ismétlődő mintákra irányul. A következő területek a gyakorlatban gyakran a legnagyobb kockázati és költségtényezők.

Monolitikus Forms: amikor a UI tartja össze a rendszert

Sok VCL-alkalmazás történetileg „űrlapvezérelt” módon nőtt: az űrlap tölti be az adatokat, ellenőrzi a szabályokat, visszaír, elindít jelentéseket és frissít más képernyőket. Ez működik – amíg több csapat vagy több év módosítási története rá nem hat.

Egy operatív, bevált megközelítés, hogy lépésről lépésre tehermentesítjük a UI-t:

• Use-case-közeli szolgáltatások bevezetése: szakmai műveletek világosan elnevezett metódusokként az eseményláncok helyett.
• Adatelérés kapszulázása: lekérdezések/tranzakciók ne a UI-eseményekben legyenek, hanem az adat-hozzáférési rétegekben.
• DTO-k/modellek (egyszerű adatobjektumok) használata a űrlapállapot és az adatbázisállapot szétválasztására.

A cél nem a „Pattern-Reinheit”, hanem jobb tesztelhetőség és kevesebb mellékhatás: egy változtatás az érvényesítésben vagy számításban ne sodorja veszélybe az egész UI-kattintási útvonalat.

Adatelérés modernizálása: BDE ablösen, FireDAC konsistent einsetzen

Ha még BDE vagy egységesítetlen adatelemek vannak használatban, a refaktorálás gyakran egyben a működési kockázat modernizálása is. BDE nemcsak régi, hanem gyakran nehezen üzemeltethető: driverek, konfiguráció, 32 bites függőségek és hiányzó modern biztonsági mechanizmusok.

BDE-kiváltása natív csatlakozással (Delphi-nak a modern adatelérési könyvtára) sok scenárióban ésszerű alapértelmezés lehet, ha következetesen dolgoznak: egységes kapcsolatparaméterek, egyértelmű tranzakcióhatárok, timeouthatárértékek, pooling és rendezett kivételkezelés. Tipikus refaktorálási intézkedések ebben a területen:

• Kapcsolatkezelés egységesítése: központi Factory/Provider a „minden űrlapnak saját Connection-ja van” helyett.
• Tranzakciók explicit kezelése: Begin/Commit/Rollback mint a use-case része, ne rejtve a UI-ban.
• Paraméterezett lekérdezések következetes használata az SQL-injekciós kockázatok és a különleges karakterek okozta problémák csökkentésére.
• Timeoutok és újrapróbálkozások meghatározása, hogy a hálózati akadozások ne vezessenek „lefagyott” képernyőkhöz.

Az IT-üzemeltetés számára fontos, hogy az új kapcsolatstratégiákat összehangolják az adatbázis-üzemeltetéssel (pl. maximális kapcsolatok, poolméretek, deadlock-kezelés, karbantartási ablakok sémaváltoztatásokhoz).

Unit-függőségek és „globális állapotok” mint a mellékhatások fő oka

Delphi-unitok nagy interface-szekciókkal, sok Uses-bejegyzéssel és globális singletonokkal tipikusan gyorsítják a mellékhatások megjelenését. Egy apró változtatás egy unitban újrafordítási kaszkádokat indíthat el, vagy megszakíthat rejtett inicializációs sorrendeket.

Pragmatikus lépések, amelyek örömet szereznek legacy-projektekben:

• Függőségi irányok meghatározása: pl. UI → Alkalmazásszolgáltatások → Domain/logika → Adat-hozzáférés → Infrastruktúra.
• Inicializáció centralizálása: egyértelmű indítási sorrend a unit-inicializáció mint rejtett vezérlés helyett.
• Globális változók csökkentése: az állapotot objektumokban tartani, élettartamot és tulajdonjogot tisztázni.

Ez a stabilitást támogatja: ha az indítás determinisztikus, az update-ek vagy konfigurációváltozások utáni kiesések jobban kezelhetők.

Szálkezelés és szinkronizáció: stabilitás a „Performance-Optimierung” előtt

Sok legacy-alkalmazás az idő múlásával párhuzamosítódik: háttérimportok, polling, eszközökkel való kommunikáció, párhuzamos feldolgozás. Világos szabályok hiányában holtpontok, UI-fagyások vagy versenyhelyzetek (egyidejű végrehajtás miatti hozzáférési konfliktusok) alakulnak ki.

A működtetés és a support számára ez problémát jelent, mert gyakran „nem reprodukálható” hibákat eredményez. A refaktorálásnak itt szabványokra kell törekednie:

• Egyértelmű felelősség (Ownership) a szálak/feladatok számára és definiált leállítás (hogy a frissítések/leállítás ne akadjanak meg).
• Workerenkénti naplózás korrelációs azonosítóval a folyamatok követhetőségéhez.
• Szinkronizáció minimalizálása és a UI-hozzáférések szigorú kapszulázása (UI-thread-szabály).

Ha ebben mélyebben el kíván merülni, érdemes egy belső linket elhelyezni egy olyan bejegyzésre, amely a TThread és Synchronize használatával kapcsolatos robusztus mintákról szól, mert ez a téma a legacy-refaktorálásnál gyakran a stabilitás szűk keresztmetszete.

Architektúra-célkép: Layering mint eszköz, nem dogma

Egy gyakorlatias célkép sok Delphi-meglévő megoldás számára egy tiszta rétegstruktúra (gyakran „3 rétegként” értelmezve): prezentáció (UI), alkalmazáslogika (Use Cases/Services) és adat-hozzáférés (Repositories/DAO). Fontos a működtetési perspektíva: a rétegzés megkönnyíti a teszteket, a frissítéseket és a későbbi interfészek különválasztását.

Konkrét előnyök a vállalatok számára:

• Interfészek utólagos kiépítése (pl. REST-API), anélkül hogy a UI-logikát duplikálni kellene.
• Részleges modernizáció: adatbázisváltás vagy BDE-Ablosung mit nativer Anbindung-átállítás egy rétegbe koncentrálható.
• Karbantartás: a hibák gyorsabban lokalizálhatók, mert a felelősségek a kódban világosabbak.

Egy reális célkép figyelembe veszi, hogy a legacy rendszerek ritkán válnak „tisztté”. Döntő, hogy az irány helyes legyen, és az új változtatások ne oldják fel újból a struktúrát.

Tesztstratégia a Delphi-refaktoráláshoz: hogyan rögzítse a viselkedést, mielőtt átépít

Teszt nélküli refaktorálás üzletileg kritikus rendszerekben kockázatot jelent. Ugyanakkor a teljes tesztautomatizálás gyakran nem reálisan megvalósítható rövid távon. A központi gondolat tehát: céltudatosan tesztelni ott, ahol a kockázat és a változási nyomás magas.

Golden Master und Regression: Praktisch für Legacy

A „Golden Master” a jelenlegi viselkedés referenciája: a bemeneteket és a várt kimeneteket rögzítik, hogy változtatások után eltéréseket lehessen észlelni. Ez alkalmas riportokhoz, számításokhoz, exportokhoz, import-pipeline-okhoz vagy interfészválaszokhoz.

Fontos a működtetés szempontjából: a Golden-Master tesztek csökkentik annak kockázatát, hogy mellékhatások csak a rollout után jelentkezzenek — és támogatják a gyors hotfix-döntéseket, mert az eltérés konkrétan mérhetővé válik.

Integrációs tesztek az adatbázis és az interfészek körül

Sok hiba nem a tiszta üzleti logikában keletkezik, hanem a rendszerhatároknál: tranzakciók, kódolás (pl. Unicode), időbélyegek, tizedeselválasztó, jogosultságok, hálózati zavarok. Az integrációs teszteknek ezért legalább az alábbi pontokat kell lefedniük:

• Tranzakcióviselkedés hibák esetén (Rollback, részleges frissítések, zárolások).
• Kódolás import/export esetén (CSV, XML, JSON), különös tekintettel a különleges karakterekre.
• Teljesítményprofilok tipikus adatmennyiségekre, hogy a lassan bekövetkező romlásokat észre lehessen venni.

Manuális tesztesetek megmaradnak – aber strukturiert

Ahol az automatizálás (még) hiányzik, ott a strukturált manuális teszttervek, amelyek a release-ekhez kötődnek, segítenek. Az adminisztrációs nézőpontból releváns, hogy a tesztesetek üzemeltetési szempontokat is tartalmazzanak: telepítési-/frissítési útvonal, jogosultságok, konfiguráció, naplózás/monitorozás, nyomtató/PDF, hálózati útvonalak.

Adatok és migráció: a refaktorálás gyakran a sémán dől el

Delphi-rendszerekben az adatbázisszerkezetek évek alatt nőttek. A refaktorálás gyakran ütközik „történeti” táblákkal, duplikált mezőkkel vagy szakmailag túlterhelt oszlopokkal. A kritikus pont: a séma-módosítások hatással vannak az üzemeltetésre, a backup/restore-ra, a replikációra, a riportolásra és a felületekre.

Sémamódosítások tervezhetővé tétele

Bevált megközelítés a világosan verziózott adatbázismigráció: minden sémaváltozás reprodukálható lépésként dokumentálva, benne visszagörgetési stratégiával. Még ha a migrációk kezdetben manuálisan történnek is, a fegyelem döntő: semmi „gyorsan megváltoztatjuk élesben“.

A kiadásbiztonság érdekében határozza meg:

• Szükséges leállási idő: lehetséges-e online migráció, vagy szükséges karbantartási ablak?
• Visszaállítási stratégia: adatkompatibilitás visszagörgetés esetén, migráció előtti biztonsági mentések, újraindítási terv.
• Kompatibilitási fázis: az alkalmazás átmenetileg képes együttműködni a régi és az új sémával (pl. kiegészítő oszlopok, nézetek).

Az adatok minőségét és a tisztítást ne becsülje alá

A refaktorálás gyakran feltár olyan adathibákat, amelyek korábban „úsztak” a rendszerben: érvénytelen értékek, inkonzisztenciák, hiányzó idegen kulcsok. Fontos szakmailag meghatározni, mi a helyes állapot. Technikailag az alkalmazásnak ezután szigorúbban kell érvényesítenie és a hibákat követhetően naplóznia, ahelyett, hogy csendben javítana.

Interfészek utólagos kialakítása anélkül, hogy destabilizálnánk a legacy rendszert

Sok vállalat refaktorálja Delphi-állományait, mert az új követelmények integrációkat kényszerítenek: portálok, BI, mobil folyamatok, partnerkapcsolatok. A leggyakoribb hiba, hogy az interfészeket közvetlenül az UI-logikából vagy „valahonnan a kódból” táplálják. Jobb, ha az interfészeket egy konszolidált szolgáltatási rétegre helyezzük, amely már a refaktorálás során kialakul.

Ha egy REST-API (Representational State Transfer, a szokásos web-API HTTP/JSON felett) utólag léptetnek be, üzemeltetési és biztonsági szempontból különösen fontosak:

• AuthN/AuthZ: a hitelesítés és a jogosultságkezelés szétválasztása; pl. tokenek, SAML 2.0 vállalati SSO környezetben, világos szerepmodellek.
• Rate Limits und Timeouts: hogy a külső hívók ne blokkolják a backendet.
• Verziózás: API-verziók definiálása, hogy a kliensek ne sérüljenek minden változtatásnál.
• Observability: strukturált naplók, korrelációs azonosítók, metrikák (hibaarányok, késleltetések).

Egy belső hivatkozás egy mélyebb cikkre a meglévő szoftverhez utólag beépített REST-API-ról jó folytatás lehet, mert az interfészek a modernizációs projektekben ritkán egy „Add-on” jellegű kiegészítők, inkább önálló üzemeltetési termékek.

Biztonság és megfelelőség: a refaktorálás alkalom a biztonsági rések bezárására

Legacy rendszer gyakran azt jelenti, hogy a biztonsági feltevések elavultabbak a mai fenyegetési körnél. A refaktorálás során legalább ellenőrizze, hogy a rendszert az alábbi területeken frissíteni kell-e:

• Hitelesítő adatok és titkok: ne legyenek jelszavak INI-fájlokban vagy a kódban; biztonságos tárolás és rotáció.
• Transzporttitkosítás: TLS az interfészeknél, korrekt tanúsítvány-kezelés.
• Legkisebb jogosultság elve: az adatbázisfelhasználók és fájljogosultságok minimalizálása; külön szerepkörök olvasásra/írásra/adminisztrációra.

Az IT-vezetés számára ez központi üzleti előny: a refaktorálás nemcsak a karbantartási költségeket csökkenti, hanem strukturált megvalósítás esetén mérsékelheti a biztonsági és auditkockázatokat.

Kiadási és üzemeltetési folyamat: tiszta pipeline nélkül a refaktorálás költséges

Sok Delphi-legacy projektben a probléma kevésbé a kódban, inkább a folyamatban van: a buildek munkaállomásonként eltérnek, a kiadások kézzel történnek, a hibák nem követhetők vissza tisztán. Ezért a refaktorálásnak mindig a szállítási folyamat stabilizálását is szolgálnia kell.

Build-reprodukálhatóság és konfigurációkezelés

Az üzemeltetés és az auditok szempontjából fontos, hogy egy kiadás reprodukálható legyen: azonos források, azonos Compiler-/Library-verziók, azonos függőségek. Ide tartoznak a fejlesztésre, tesztre és éles környezetre egyértelműen elkülönített konfigurációk (pl. adatbázis-végpontok, naplózási szintek, feature-flagek).

Naplózás, monitoring és támogatási alkalmasság

Az üzemeltetésben a „valami történt” kevés. A refaktorálás jó alkalom az egységes naplózás bevezetésére: strukturált naplóbejegyzések, egyértelmű hibakódok, kontextus (felhasználó, bérlő, megbízás, interfész) és világos elkülönítés a technikai hibák és az üzleti validációk között.

24/7 jellegű folyamatok esetén további elemek hasznosak:

• Állapotellenőrzések (pl. adatbázis-kapcsolat, sorfelgyülemlés, memóriafogyasztás),
• Riasztás súlyosság szerint,
• Runbookok az újraindításhoz és tipikus hibákhoz.

Gyakorlatias refaktorálási ütemterv 6 lépésben

Ahhoz, hogy a refaktorálás ne fulladjon bele a napi ügymenetbe, egy világos ütemterv segít, amely kompatibilis a kiadási ciklusokkal. Egy bevált eljárás:

1. Kockázat- és változás-térkép készítése (modulok, interfészek, adatok, üzemeltetés).
2. Védőháló kiépítése: naplózási szabvány, első regressziós/Golden-Master-tesztek a kritikus útvonalakra.
3. Architektúrális határvonalak meghúzása: szolgáltatásréteg és adat-hozzáférés-kapszulázás mint a módosítások „új normálja”.
4. Hotspotok refaktorálása: azok a modulok, amelyeket gyakran módosítanak és kieséseket okoznak (hibastatisztika és változás-előzmények használata).
5. Adatelérés konszolidálása: FireDAC/tranzakciók/időtúllépések egységesítése, teljesítmény mérése, holtpontok ellenőrzése.
6. Modernizációs utak megnyitása: interfészek (REST), platformtémák (Unicode/64-bit), fokozatos UI-modernizáció, ahol érdemes.

A lényeg a sorrend: először átláthatóság és biztosítás, aztán strukturális intézkedések, végül nagyobb átépítések. Így a megoldás szállítható és üzemstabil marad.

Amikor a refaktorálás nem elég: jelek nagyobb modernizáció szükségességére

Vannak helyzetek, amikor maga a refaktorálás nem oldja meg a szűk keresztmetszetet. Tipikus jelek:

• Technológiai zsákutcák: már nem támogatott adatbázis-illesztők, nem javítható komponensek, merev 32 bites függőségek.
• Az architektúra már nem megfelelő: pl. az alkalmazást szolgáltatás-alapú környezetben kellene működtetni, de minden eleme UI-központú.
• Méret- és rendelkezésre állás: a bérlőizolációra (multitenancy), magas rendelkezésre állásra vagy távoli hozzáférésre vonatkozó követelményeket csak strukturális változtatásokkal lehet kielégíteni.
• Biztonsági követelmények: hitelesítés/SSO, audit, titkosítás nem építhető utólag be nagyobb átépítés nélkül.

Még ilyenkor is a refaktorálás gyakran érdemi része a megoldásnak: rendet teremt, hogy célzottan ki lehessen kapcsolni részeket ahelyett, hogy az egész rendszert egyszerre cserélnénk le.

Összegzés: Refaktorálás mint technikai felelősség az üzemeltetés során

A Delphi-ban található legacy-kód refaktorálása elsősorban priorizálás, kockázatkezelés és üzemeltetés-közelség kérdése. Ha megbízható állapotfelméréssel indít, a kritikus pontokat biztosítja, az adathozzáférést és az architekturális elválasztási vonalakat konszolidálja, továbbá a teszteket és a naplózást célzottan a kritikus útvonalakra igazítja, az „Aufräumen” egy irányítható modernizációs projekté válik. Az eredmény nem csupán jobban olvasható kód, hanem egy olyan rendszer, amely megbízhatóbban üzemeltethető, biztonságosabban módosítható és könnyebben integrálható.

Ha az Delphi-meglévő megoldását strukturáltan stabilizálni vagy modernizálni kívánja, szívesen tisztázzuk együtt a kiindulási helyzetet, a kockázatokat és egy reális refaktorálási útvonalat:

A szakmai környezetben fontos szerepet játszanak Delphi modernizáció és Delphi refaktorálás is, amikor az integrációknak, az adatfolyamoknak és a további fejlesztésnek tisztán kell együttműködniük.

Projekt vagy modernizációs terv megbeszélése Net-Base-vel.