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 üzleti szempontból kritikus Delphi-alkalmazást üzemeltet, ismeri a feszültségteret: az alkalmazás stabilan fut, lefedi a kulcsfolyamatokat és mélyen integrált az adatbázisokba, interfészekbe és munkafolyamatokba. Ugyanakkor a változtatási költség és a kockázat minden kiadással növekszik, mert évek alatt kompromisszumok, kivételek és függőségek halmozódtak fel. Itt lép be a képbe a Legacy-Code in Delphi refactoren: nem „Rewrite”-projektként, hanem kontrollált átépítésként a működő rendszerben – mérhető hatásokkal a karbantarthatóságra, a kiadások biztonságára és az üzemeltetésre.

A gyakorlatban a refaktorálás ritkán magán a Delphi-on bukik el, sokkal inkább az átláthatóság hiányán: mi számít szakmailag kritikusnak? Hol vannak a technikai adósságok (azaz strukturális hiányosságok, amelyek későbbi módosításokat drágítanak)? Mely részekhez lehet nyúlni karbantartási ablakokban, és melyeket nem? És hogyan lehet megakadályozni, hogy a „rendrakás” új hibákat vagy teljesítményproblémákat okozzon éles környezetben? Ez a cikk egy gyakorlati megközelítést ír le, amely bevonja az IT-vezetést és az üzemeltetést: a felméréstől az architektúra- és adatkérdéseken át a tesztekig, a release-folyamatig és a biztonsági szempontokig.

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

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

Tipikus Legacy-jellemzők Delphi-környezetekben:

• Szoros kapcsolódás: a UI, az adathozzáférés és az üzleti logika összekeverednek; a módosítások mellékhatásokat idéznek elő.
• Implicit szabályok: a domain-logika eseményekben, globális változókban vagy adatbázis-triggerekben található, nem világos modulokban.
• Elavult adathozzáférések: pl. BDE (Borland Database Engine) vagy proprietáris komponensek; hiányoznak a pooling-/timeout-stratégiák.
• Inkonzisztens hibakezelés: a kivételek elnyelődnek, ü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ómunka.
• Hiányzó tesztek: a tudás fejben vagy a tapasztalt felhasználók „kattintási útvonalában” van.

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 ebben az esetben befektetés a kezelhetőségbe – az üzemeltetés, a biztonság, a megfelelőség é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 (újraírás / új fejlesztés) tiszta indulást ígér, de gyakran hosszú párhuzamos üzemet, új hibatípusokat és nagy migrációs kockázatot hoz magával. A refaktorálás viszont az inkrementális javításra törekszik, miközben a folyamatos szállíthatóság megmarad. 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 kerülnek kiadásra.

Gyakorlati elkülönítés:

• Refaktorálás: a struktúrát javítják, a külső viselkedés változatlan marad. Fókusz: karbantarthatóság, tesztelhetőség, stabilitás, teljesítménytartalékok.
• Restrukturierung/Modernisierung: zusätzlich gezielte Verhaltensänderungen, z. B. neue Schnittstellen, neue Datenbank, neue Plattformziele.
• Rewrite: neue Codebasis, meist neue UI/Architektur; erfordert Migration der Daten, Prozesse, Schnittstellen – oft „Big Bang“ oder lange Übergangsphase.

Für Entscheider ist der Punkt zentral: Refactoring ist kein Selbstzweck, sondern ein Hebel, um Change-Risiken zu reduzieren. Das ist unmittelbar betriebsrelevant, wenn die Anwendung 24/7-Prozesse, Produktionsnahe Abläufe oder kundennahe Portale beeinflusst.

Legacy-Code in Delphi refactoren: Start mit einer belastbaren Bestandsaufnahme

Der erste Schritt ist kein Tool, sondern eine gemeinsame Sicht auf Risiken und Ziele. Ohne diese Sicht landet Refactoring schnell in „wir räumen mal hier auf“ – und genau das ist im Betrieb schwer zu rechtfertigen.

1) Kritikalität und Betriebsrealität erfassen

Erheben Sie, welche Teile wirklich geschäftskritisch sind: Tagesabschluss, Schnittstellen zu ERP/DMS/CRM, Produktionsdatenerfassung, Abrechnung, Rechteverwaltung. Ergänzen Sie Betriebsparameter: Wartungsfenster, Rollback-Möglichkeiten, Monitoring, Datenvolumen, Latenzanforderungen.

Hilfreiche Leitfragen:

• Welche Funktionen müssen auch bei Teilausfällen weiterlaufen (Degradationsfähigkeit)?
• Wo sind „Single Points of Failure“ (z. B. ein zentraler Scheduler)?
• Welche Daten sind regulatorisch oder datenschutzrechtlich sensibel?
• Welche Integrationen sind am störanfälligsten (Datei-Importe, TCP/IP, SOAP/REST, Messaging)?

2) Technische Schulden sichtbar machen – nicht nur Code-Style

In Delphi-Projekten sind technische Schulden oft architektonisch: globale Zustände, zyklische Unit-Abhängigkeiten, schwer testbare Datenzugriffe, oder UI-Events als „Orchestrierung“. Metriken (z. B. Komplexität, Unit-Größe, Abhängigkeitsgraph) helfen, sind aber nur dann wertvoll, wenn sie in Maßnahmen übersetzt werden.

Ein praxistaugliches Raster ist eine 2×2-Betrachtung:

• Häufig geändert & riskant: höchste Priorität fürs Refactoring.
• Häufig geändert & wenig riskant: Prozess/Tests verbessern, kleinere Strukturmaßnahmen.
• Selten geändert & riskant: Stabilisierung/Absicherung (Tests, Logging), nicht zwingend „schön machen“.
• Selten geändert & wenig riskant: bewusst liegen lassen.

3) Abhängigkeiten inventarisieren: Daten, Schnittstellen, Laufzeit

Für Administration und Projektverantwortliche ist entscheidend, was außerhalb des Codes hängt: Datenbank-Backends, ODBC/OLE DB, Dateifreigaben, Druck- und PDF-Strecken, COM/ActiveX, Office-Automation, Windows-Services, geplante Tasks, Zertifikate, Proxy-Konfigurationen.

Hier entstehen Refactoring-Kosten oft indirekt: Eine „kleine“ Änderung kann neue Installer-Logik, neue Rechte oder neue Firewall-Regeln erzwingen. Diese Nebenwirkungen sollten früh in einer technischen Landkarte dokumentiert werden.

Typische Problemzonen in Delphi-Legacy und wie man sie gezielt angeht

Refactoring wird beherrschbar, wenn es auf wiederkehrende Muster zielt. Die folgenden Felder sind in der Praxis häufig die größten Risiko- und Kostenfaktoren.

Monolithische Forms: Wenn die UI das System zusammenhält

Sok VCL-alkalmazás történelmileg „Form-driven” módon nőtt: az űrlap betölti az adatokat, ellenőrzi a szabályokat, visszaír, elindítja a jelentéseket és frissíti a többi űrlapot. Ez működik — amíg több csapat vagy évek módosítási története rá nem hat.

Egy üzemeltetésben bevált megoldás, hogy a UI-t lépésről lépésre tehermentesítjük:

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

A cél nem a „Pattern-Reinheit”, hanem jobb tesztelhetőség és kevesebb mellékhatás: egy validációs vagy számítási módosítás ne veszélyeztesse az egész UI-kattintási útvonalat.

Adat-hozzáférés modernizálása: BDE kiváltása, FireDAC következetesen alkalmazása

Ha még BDE vagy nem egységes adatkomponensek vannak használatban, a refaktorálás gyakran egyben az üzemeltetési kockázat modernizálása is. BDE nemcsak régi, hanem gyakran nehéz üzemeltetni: illesztőprogramok, konfiguráció, 32-bites függőségek és hiányzó modern biztonsági mechanizmusok.

BDE kiváltása natív csatlakozással (a(z) Delphi modern adat-hozzáférési könyvtára) sok esetben ésszerű alapmegoldás, ha következetesen dolgoznak: egységes Connection-paraméterek, egyértelmű tranzakciós határok, timeoutok, pooling és tiszta kivételkezelés. Tipikus refaktorálási intézkedések ebben a területben:

• Kapcsolatkezelés egységesítése: központi Factory/Provider a „minden űrlapnak saját Connection” helyett.
• Transakciók explicitvé tétele: Begin/Commit/Rollback mint a Use-Case része, ne legyen elrejtve a UI-ban.
• Paraméterezett lekérdezések következetes használata az SQL-injekciós kockázatok és speciális karakterek okozta problémák csökkentésére.
• Timeoutok és retry-k definiálása, hogy a hálózati akadozások ne vezessenek „lefagyott” űrlapokhoz.

Az IT-üzemeltetés szempontjából fontos, hogy az új Connection-stratégiákat összehangolják az adatbázis-üzemeltetéssel (pl. maximális kapcsolatok, pool-méretek, deadlock-kezelés, karbantartási ablakok séma-módosítá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 felgyorsítják a mellékhatásokat. Egy apró változtatás egy unitban rebuild-kaszádokat vonhat maga után, vagy megszakíthat rejtett inicializációs sorrendeket.

Pragmatikus lépések, amelyek beváltak legacy-projektekben:

• Függőségi irányok meghatározása: pl. UI → Application Services → Domain/Logik → Data Access → Infrastruktur.
• Inicializáció centralizálása: világos startup-szekvencia az Unit-inicializáció mint rejtett vezérlés helyett.
• Globális változók csökkentése: az állapotot objektumokban tartani, az élettartamot és a tulajdonjogot tisztázni.

Ez a stabilitás javára válik: ha az indítás determinisztikus, a frissítések vagy konfigurációs változások utáni hibák jobban kezelhetők.

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

Sok legacy-alkalmazás az idő során párhuzamosabbá válik: háttérimportok, polling, eszközökkel való kommunikáció, párhuzamos feldolgozás. Szabályok hiányában deadlockok, UI-fagyások vagy versenyhelyzetek (egyszerre történő végrehajtás okozta hozzáférési konfliktusok) alakulhatnak ki.

Az üzemelteté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 a szálak/feladatok számára és meghatározott leállítás (hogy a frissítések/lezárás ne akadjanak).
• Workerenkénti naplózás korrelációs azonosítóval, hogy a folyamatok visszakövethetők legyenek.
• A szinkronizáció minimalizálása és az UI-hozzáférések szigorú kapszulázása (UI-szál szabály).

Ha ebben mélyebben szeretne elmélyülni, érdemes belső hivatkozást elhelyezni egy olyan bejegyzésre a robusztus mintákról TThread és Synchronize használatával, mert ez a téma a legacy-refaktorálásnál gyakran a stabilitás szűk keresztmetszete.

Architektúra célkép: Rétegzés eszközként, nem dogmaként

Egy gyakorlatias célkép sok Delphi-állománymegoldás számára egy világos rétegstruktúra (gyakran „3 rétegűként” értelmezve): prezentáció (UI), alkalmazáslogika (use case-ek/szolgáltatások) és adatelérés (Repositories/DAO). Fontos a működtetési nézőpont: a rétegzés megkönnyíti a teszteket, a frissítéseket és a későbbi interfészkiválasztást.

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

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

Egy realistán felállított célkép figyelembe veszi, hogy a legacy rendszerek ritkán válnak „tiszta” állapotúvá. Döntő, hogy a irány megfelelő legyen, és az új módosítások ne lazítsák fel ismét 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 elérhető rövidtávon. A központi gondolat ezért: célozott tesztelés ott, ahol a kockázat és a változási nyomás nagy.

Golden Master und Regression: Praktisch für Legacy

Egy „Golden Master” az aktuális viselkedés referenciája: a bemeneteket és a várt kimeneteket rögzítik, hogy a módosítások után eltéréseket lehessen felismerni. Ez alkalmas jelentésekre, számításokra, exportokra, import-folyamatokra vagy interfészválaszokra.

Üzemeltetési szempontból fontos: a Golden-Master tesztek csökkentik annak kockázatát, hogy mellékhatások csak a bevezetés után jelentkezzenek – és támogatják a gyors hibajavítási 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 rendszerek határain: tranzakciók, kódolás (pl. Unicode), időbélyegek, tizedeselválasztó, jogosultságok, hálózati zavarok. Ezért az integrációs teszteknek legalább a következő pontokat kell lefedniük:

• Tranzakcióviselkedés hiba esetén (visszagörgetés/Rollback, részleges frissítések, zárolások).
• Kódolás import/export esetén (CSV, XML, JSON), különösen speciális karaktereknél.
• Teljesítményprofilok tipikus adatmennyiségekre, hogy a fokozatos romlásokat felismerjük.

Manuális tesztesetek megmaradnak – de strukturáltan

Ahol az automatizálás (még) hiányzik, strukturált manuális teszttervek segítenek, amelyek kiadásokhoz kötődnek. Adminisztrációs szempontból releváns, hogy a tesztesetek tartalmazzák az üzemeltetési aspektusokat is: 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

In Delphi-rendszerekben az adatbázis-struktúrák éveken át 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émamódosítások érintik az üzemeltetést, a mentés/visszaállítást, a replikációt, a jelentéskészítést és az interfészeket.

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

Bevált megközelítés a világosan verziózott adatbázis-migráció: minden sémaváltozást reprodukálható lépésként kell dokumentálni, visszalépési (rollback) stratégiával együtt. Még ha a migrációk kezdetben kézzel történnek is, a fegyelem döntő: nincs olyan „gyorsan módosítunk a produkcióban” hozzáállás.

A kiadások biztonsága érdekében határozza meg:

• Leállási igény: online migráció lehetséges, vagy karbantartási ablak szükséges?
• Visszalépési stratégia: adatkompatibilitás visszalépés esetén, mentések a migráció előtt, újraindítási terv.
• Kompatibilitási fázis: az alkalmazás átmeneti időszakban képes együttműködni régi és ú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á

Egy refaktorálás gyakran feltár olyan adathibákat, amelyek korábban „beleszürkítve” voltak: érvénytelen értékek, inkonzisztenciák, hiányzó idegen kulcsok. Fontos, hogy szakmai alapon döntsék el, mi a helyes. Technikai szempontból az alkalmazásnak ezután szigorúbban kell validálnia és a hibákat nyomonkövethetően naplóznia, ahelyett hogy csendesen kijavítaná őket.

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

Sok vállalat refaktorálja a Delphi-állományokat, mert az új követelmények integrációkat írnak elő: 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 megoldás, ha az interfészeket egy konszolidált szolgáltatásrétegre helyezzük, amely a refaktorálás során jön létre.

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

• AuthN/AuthZ: a hitelesítés és az autorizáció szigorú szétválasztása; pl. tokenek, SAML 2.0 vállalati SSO-környezetben, egyértelmű szerepkörmodellek.
• Rate limit-ek és time-outok: hogy a külső hívók ne blokkolják a backendet.
• Verziózás: API-verziókat definiálni, 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ő link egy mélyreható cikkhez a REST-API utólagos beépítéséről meglévő szoftverhez itt jól illeszkedhet tartalmilag, mert az interfészek a modernizációs projektekben ritkán „kiegészítők”, sokkal inkább saját üzemtermékek.

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

Legacy gyakran azt jelenti, hogy a biztonsági feltevések régebbiek, mint a mai fenyegetettségi helyzet. 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: nincs jelszó INI-fájlokban vagy a kódban; biztonságos tárolás és rotáció.
• Átvitel titkosítása: TLS az interfészekhez, rendezett tanúsítványkezelés.
• Least Privilege: adatbázis-felhasználók és fájljogosultságok a lehető legkisebb mértékre korlátozva; külön szerepek 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 drága lesz

Sok Delphi-legacy-projekt kevésbé a kód miatt szenved, mint a folyamat miatt: a buildek munkaállomásonként eltérnek, a kiadások manuálisak, a hibák nem követhetők vissza tisztán. A refaktorálásnak ezért mindig a szállítási folyamat stabilizálását is szolgálnia kell.

Build-Reproduzierbarkeit und Konfigurationsmanagement

Adminisztráció és audit szempontjából fontos, hogy egy release reprodukálható legyen: ugyanazok a források, ugyanazok a compiler-/library-verziók, ugyanazok a függőségek. Ide tartoznak a fejlesztéshez, teszthez és éles környezethez világosan elkülönített konfigurációk (z. B. Datenbankendpunkte, Logging-Level, Feature-Flags).

Logging, Monitoring und Supportfähigkeit

„Es ist was passiert“ reicht im Betrieb nicht. Refactoring ist eine gute Gelegenheit, einheitliches Logging einzuziehen: strukturierte Logeinträge, eindeutige Fehlercodes, Kontext (User, Mandant, Auftrag, Schnittstelle) und klare Trennung zwischen technischen Fehlern und fachlichen Validierungen.

24/7-hez közeli folyamatok esetén további elemek hasznosak:

• Health Checks (z. B. Datenbankverbindung, Queue-Stau, Speicherverbrauch),
• Alarmierung nach Schweregrad,
• Runbooks für Wiederanlauf und typische Störungen.

Ein praxistauglicher Refactoring-Fahrplan in 6 Schritten

Damit Refactoring nicht im Tagesgeschäft versandet, hilft ein klarer Fahrplan, der mit Release-Zyklen kompatibel ist. Ein bewährtes Vorgehen:

1. Risiko- und Änderungslandkarte erstellen (Module, Schnittstellen, Daten, Betrieb).
2. Schutznetz spannen: Logging-Standard, erste Regression-/Golden-Master-Tests für kritische Pfade.
3. Architekturtrennlinien einziehen: Service-Schicht und Data-Access-Kapselung als „neue Normalität“ für Änderungen.
4. Hotspots refactoren: die Module, die häufig geändert werden und Ausfälle verursachen (Fehlerstatistik und Change-Historie nutzen).
5. Datenzugriff konsolidieren: FireDAC/Transaktionen/Timeouts vereinheitlichen, Performance messen, Deadlocks prüfen.
6. Modernisierungspfade öffnen: Schnittstellen (REST), Plattformthemen (Unicode/64-Bit), schrittweise UI-Modernisierung, wo sinnvoll.

Der Kern ist die Reihenfolge: Erst Transparenz und Absicherung, dann Strukturmaßnahmen, dann größere Umbauten. So bleibt die Lösung lieferfähig und betriebsstabil.

Wann Refactoring nicht reicht: Signale für eine größere Modernisierung

Es gibt Situationen, in denen reines Refactoring den Engpass nicht auflöst. Typische Signale:

• Technologische Sackgassen: nicht mehr unterstützte Datenbanktreiber, nicht patchbare Komponenten, harte 32-Bit-Abhängigkeiten.
• Architektur passt nicht mehr: z. B. die Anwendung muss als Service-Landschaft betrieben werden, aber alles ist UI-zentriert.
• Skalierung und Verfügbarkeit: Anforderungen an Mandantenfähigkeit, Hochverfügbarkeit oder Remote-Zugriff lassen sich nur mit strukturellen Änderungen erfüllen.
• Sicherheitsanforderungen: Authentifizierung/SSO, Audit, Verschlüsselung sind nicht nachrüstbar ohne größeren Umbau.

Még ebben az esetben is gyakran érdemes a refaktorálást alkalmazni: rendet teremt, lehetővé téve egyes részek célzott kiszervezését ahelyett, hogy az egész rendszert egyszerre cserélnék le.

Összegzés: Refaktorálás, mint technikai felelősség az üzem közbeni működtetés során

A Delphi-ban lévő Legacy-Code refaktorálása elsősorban priorizálás, kockázatkezelés és üzemeltetési közelség kérdése. Ha egy megbízható állapotfelméréssel indít, a kritikus pontokat biztosítja, az adat-hozzáférést és az architektúra-elválasztási vonalakat konszolidálja, valamint a teszteket és a naplózást célzottan a kritikus útvonalakra igazítja, a „rendrakás” irányítható modernizálási projektté válik. Az eredmény nemcsak olvashatóbb kód, hanem egy olyan rendszer, amely megbízhatóbban üzemeltethető, biztonságosabban módosítható és egyszerűbben integrálható.

Ha a Delphi-megoldásának meglévő állományát strukturáltan szeretné stabilizálni vagy modernizálni, szívesen tisztázzuk együtt a kiinduló helyzetet, a kockázatokat és egy reális refaktorálási utat:

A szakmai környezetben fontos szerepet játszanak a Delphi modernizálás és a Delphi refaktorálás, ha az integrációknak, az adatfolyamatoknak és a továbbfejlesztésnek tisztán kell együttműködnie.

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