Modernizirati Delphi bez gubitka poslovne logike

Delphi-aplikacije u mnogim tvrtkama rade stabilno već godinama – i točno reproduciraju poslovnu logiku koja osigurava prihode, kvalitetu usluge i usklađenost. Zato se kod modernizacije rijetko radi o „novom sučelju“, već o kontroliranom daljnjem razvoju pri kojem se čuvaju pravila, iznimke i povijesno procesno znanje.

U ovom članku prikazujemo praktično provjeren pristup za postupnu modernizaciju Delphi: od procjene postojećeg stanja, preko odvajanja UI‑a i pristupa podacima do tehničke modernizacije (Unicode/64‑Bit, BDE-zamjena, API/servisi) – uključujući osiguranje putem testova, monitoringa i paralelnog rada. Cilj je arhitektura pogodna za modernizaciju, bez Big-Bang-Rewritea i bez gubitka logike.

Modernizacije u praksi rijetko ne uspiju zbog kompajlera ili frameworka, nego zbog pogrešnih pretpostavki o ponašanju sustava. Tijekom godina razvijene Delphi-aplikacije obično sadrže poslovna pravila u GUI‑eventima, SQL u logici obrazaca, varijante po klijentu/mandantu, povijesno uvjetovane iznimke te integracije koje su dokumentirane samo „u radu“.

Big-Bang-Rewrite prisiljava na rekonstrukciju tog znanja – uključujući i pogreške koje naslijeđeni sustav više ne čini. Bolji pristup je tretirati poslovnu logiku kao imovinu: izolirati, osigurati, pa korak po korak modernizirati.

Realistična ciljana arhitektura za procesno kritične B2B sustave nije „sve novo“, već arhitektura koja omogućuje promjene – bez ugrožavanja tekućeg rada:

• jasna podjela UI‑a, domenske logike, pristupa podacima i integracija
• testabilnost i mjerljivost (regresija, logiranje, monitoring, reproducibilni buildovi)
• postupna zamjenjivost (modernizirati UI bez trenutačne migracije DB‑a – ili obrnuto)
• API‑sposobnost (npr. REST), za povezivanje portala, mobilnih aplikacija ili sistemskih integracija
• operativni deploymenti s opcijom rollbacka

Delphi je za to pogodan, jer se postojeće jedinice i domenske klase mogu ponovno koristiti dok se okolo provodi modernizacija.

Prije prilagodbe koda potrebna je pouzdana osnova za odluke – ne potpuna dokumentacija. Dokazano su korisni ovi trije ishodi:

• Karta poslovne logike: kritični use‑casevi, pravila/izračuni, varijante (mandanti/zemlje/klijenti), sučelja, poslovi/batch‑pokretanja.
• Profil rizika: posebno kritična područja za pogreške, kvaliteta podataka, regulatorni zahtjevi, uska grla u radu (performanse, stabilnost, održavanje).
• Backlog modernizacije: prioritetizirani paketi po poslovnoj vrijednosti i riziku (što mora ostati stabilno, što smije promijeniti, što kasnije).

Time se modernizacija može učiniti planiranom: s jasnim inkrementima umjesto jednoga „sve-ili-ništa“ projekta.

Kako se poslovna logika ne bi „slučajno“ promijenila, potrebno je osiguranje koje radi neovisno o refaktoringu UI‑a. Tipične komponente:

• Characterization/Golden-Master testovi: postojeće ponašanje se zamrzava putem reprezentativnih ulaza/izlaza (reports, izračuni, procesni koraci).
• Regresijski testovi na razini use‑casea: poslovno kritični tokovi se automatski ili poluautomatski reproduciraju.
• Telemetrija: logiranje, metrike i obrasci pogrešaka učine se usporedivima prije i nakon promjene.
• Paralelni rad & kontrolirana promjena: novi moduli rade paralelno uz postojeće (Feature Toggles, pilotne grupe), s jasnom rollback‑strategijom.

Tek kada su te sigurnosne mreže uspostavljene, prava tehnička modernizacija se isplati – jer se rizik i naknadni radovi drastično smanjuju.

Najčešći razlog gubitka logike je miješanje UI-ja, pristupa podacima i poslovnih pravila. Modernizacija zato počinje razdvajanje – ne zamjenom UI-Frameworks.

Pragmatski cilj je struktura od 3 sloja:

• Presentation: VCL/FMX, Presenter/ViewModel, samo validacije bliske UI-ju (format, obavezna polja)
• Business: domenski modeli, servisi, pravila, logika stanja, izračuni
• Data/Integration: Repositories, pristup DB-u, adapteri za ERP/DMS/CRM, REST-klijenti, Messaging

Pravila iz prakse: poslovna pravila se premještaju iz OnClick/OnExit u domenske servise. SQL se premješta iz Forms u Repositories. Tako postaje logika testabilna i kasnije ponovno iskoristiva preko UI-ja, servisa i poslova (Jobs).

Kod Strangulation Pattern nastaje novo ciljano „neben“ postojećeg: nove funkcije se implementiraju u odvojenu strukturu, dok stari sustav nastavlja raditi. Korak po korak novi sloj preuzima više odgovornosti, dok stari dijelovi ne budu uklonjeni.

Primjer (tipično B2B):

• Izdvajate logiku narudžbi u domenski servis.
• Postojeći VCL-UI u početku koristi isti servis (bez prekida procesa).
• Paralelno nastaje REST-Endpunkt za portal za klijente ili integraciju.
• Nakon stabilizacije zamjenjuju se pojedini stari Forms – bez da se jezgra logike mora graditi iznova.

Tako smanjujete rizik projekta, održavate operativnost i brzo ostvarujete mjerljivu korist (npr. API, performanse, održivost).

Ovisno o početnoj situaciji, ove komponente su često relevantne – ključno je prioritiziranje prema riziku i poslovnoj vrijednosti:

• BDE/Legacy-DB-Zugriff zamijeniti: moderni Treiber/Provider, jasne granice transakcija, reproducibilna Deployments.
• Unicode: rukovanje nizovima, baza podataka/sučelja, komponente trećih strana.
• 64‑Bit: ovisnosti, memorija/performanse, vanjske Libraries.
• Sloj API-ja i servisa: REST, Windows-/Linux-servisi, integracije.
• Build & Release: CI/CD, Artefaktmanagement, potpisani Installer, Rollback.

Važno: Ove točke se idealno provode nakon razdvajanja i osiguranja – tada se promjene mogu sigurno verificirati.

Potpuni Rewrite je u nekim slučajevima smislen – često je to međutim najskuplji put do „moderne Technik“. Ova pitanja pomažu pri procjeni:

• Je li poslovna logika potpuno shvaćena i testabilna – ili je puno znanja implicitno u pogonu?
• Postoje li strogi rokovi (npr. kraj platforme, Compliance) koji isključuju paralelni rad?
• Kolika je raznolikost varijanti (Kunden-/Mandantenlogik)?
• Koliko je kritična dostupnost i kolika je tolerancija za promjene procesa?
• Koji su dijelovi zaista „krivi“ (UI, pristup podacima, integracije, deployment) – i koji su stabilni?

U mnogim B2B scenarijima postepeni pristup brže vodi do mjerljivih rezultata, jer kontrolira rizike i štiti poslovnu logiku.

Delphi-Modernisierungs-Audit (za procesno-kritične aplikacije): analiziramo arhitekturu, ovisnosti, područja rizika i isporučujemo prioritetiziranu roadmapu kako modernizirati bez gubitka poslovne logike.

• Input: Codebasis (read-only), Build-Setup, 2–3 Kern-Use-Cases, Systemumfeld (DB, Integrationen).
• Rezultat: Karta poslovne logike/modula, analiza rizika i ovisnosti, preporučena ciljna arhitektura, plan implementacije u inkrementima uključujući osiguranje (testovi/parallelni rad).
• Opcionalno: Proof of Concept za odvajanje + prvi Golden-Master-test.

Tako dobivate pouzdanu osnovu za donošenje odluka prije nego što se budžet i vrijeme ulože u rizični rewrite.

Može li se Delphi modernizirati bez ponovnog pisanja aplikacije?
Da. U mnogim slučajevima se prvo odvaja poslovna logika i pristup podacima, zatim se tehnički modernizira. To smanjuje rizik i održava stabilan rad.

Kako spriječiti da se poslovna logika „tiho“ mijenja?
Kroz Golden-Master-/regresijske testove, telemetriju te kontrolirani paralelni rad s jasnom rollback-strategijom.

Koji koraci često donose najbržu korist?
Transparentnost (Assessment), odvajanje UI/SQL, BDE-zamjena i API-/servisni sloj za integracije – svaki osiguran testovima.

Koliko dugo traje modernizacija?
To ovisi o kritičnim slučajevima uporabe, raznolikosti varijanti i ovisnostima. Audit obično u kratkom roku daje pouzdanu roadmapu i prioritetne inkremente.