Delphi posodobiti brez izgube poslovne logike

Delphi-aplikacije v številnih podjetjih delujejo že leta stabilno – in zanesljivo zajemajo prav tisto poslovno logiko, ki varuje prihodke, kakovost storitev in skladnost. Pri modernizaciji zato redko gre za »nov uporabniški vmesnik«, temveč za kontrolirano nadaljnjo nadgradnjo, pri kateri se ohranijo pravila, posebni primeri in zgodovinsko procesno znanje.

V tem prispevku prikazujemo prakso preverjen postopek za postopno modernizacijo Delphi: od popisa stanja prek odklopa UI/dostopa do podatkov do tehnične modernizacije (Unicode/64‑Bit, BDE-zamenjava, API/storitve) – vključno z zaščito prek testov, nadzora in vzporednega obratovanja. Cilj je arhitektura, ki je modernizabilna, brez Big-Bang-Rewrite in brez izgube logike.

Modernizacije v praksi redko spodleti zaradi prevajalnika ali ogrodja, temveč zaradi napačnih predpostavk o vedenju sistema. Dolgo rastoče Delphi-aplikacije običajno vsebujejo poslovna pravila v GUI-eventih, SQL v logiki obrazcev, variante na stranko/mandanta, zgodovinsko pogojene posebne primere ter integracije, dokumentirane le »v obratovanju«.

Big-Bang-Rewrite prisili ponovno rekonstruiranje tega znanja – vključno z napakami, ki jih stari sistem že dolgo ne povzroča več. Boljši pristop je, da se poslovna logika obravnava kot sredstvo: izolirati jo, zavarovati in nato korak za korakom modernizirati.

Smiselna ciljna arhitektura za procesno kritične B2B-sisteme ni »vse na novo«, temveč takšna, ki omogoča spremembe – brez ogrožanja tekočega obratovanja:

• jasna ločitev UI, domenske logike, dostopa do podatkov in integracij
• testnost in merljivost (regresija, logging, monitoring, reproducibilni buildi)
• postopna zamenljivost (modernizirati UI brez takojšnje migracije DB – ali obratno)
• podpora za API (npr. REST), za povezovanje portalov, mobilnih aplikacij ali sistemskih integracij
• obratovalno primerna deployanja z možnostjo rollbacka

Delphi se za to dobro prilega, saj je mogoče obstoječe Units in domenske razrede ponovno uporabiti, medtem ko se zunanja plast modernizira.

Preden se koda prilagodi, je potrebna zanesljiva podlaga za odločanje – ne popolna dokumentacija. Učinkoviti so bili ti trije izidi:

• Zemljevid poslovne logike: kritični primeri uporabe, pravila/izračuni, variante (mandanti/države/stranke), vmesniki, opravila/serijski zagoni.
• Profil tveganja: področja z visoko občutljivostjo na napake, kakovost podatkov, regulatorne zahteve, ozka grla v obratovanju (zmogljivost, stabilnost, vzdrževanje).
• Backlog modernizacije: prioritetni paketi po poslovni vrednosti in tveganju (kaj mora ostati stabilno, kaj se lahko spremeni, kaj pride pozneje).

S tem je modernizacijo mogoče načrtovati: z jasnimi inkrementi namesto enega samega »vse-ali-nič« projekta.

Da poslovna logika ne bo »po pomoti« spremenjena, je potrebna zaščita, ki deluje neodvisno od UI-refaktoriranja. Tipični gradniki:

• Characterization/Golden-Master-Tests: obstoječe vedenje se preko reprezentativnih vhodov/izhodov fiksira (poročila, izračuni, procesni koraki).
• Regresijski testi na ravni primerov uporabe: poslovno kritične poti se avtomatizirano ali polavtomatizirano obnovijo.
• Telemetrija: logiranje, metrike in profili napak se naredijo primerljivi pred in po spremembi.
• Vzporedno obratovanje & kontroliran prehod: novi moduli tečejo vzporedno s podatkom (Feature Toggles, pilotne skupine), z jasno strategijo rollbacka.

Šele ko so ta varnostna omrežja vzpostavljena, se dejanska tehnična modernizacija izplača – ker se tveganje in ponavno delo drastično zmanjšata.

Najpogostejši razlog za izgubo logike je prepletanje UI, dostopa do podatkov in poslovnih pravil. Modernizacija se zato začne z razvezavo – ne z zamenjavo UI-okraja.

Pragmatičen cilj je struktura s 3 plastmi:

• Presentation: VCL/FMX, Presenter/ViewModel, samo UI-povezana validacija (format, obvezna polja)
• Business: domenski modeli, storitve, pravila, logika stanj, izračuni
• Data/Integration: repozitoriji, dostop do DB, adapterji za ERP/DMS/CRM, REST-Clients, sporočanje

Praktično pravilo: poslovna pravila se preselijo iz OnClick/OnExit v domenske storitve. SQL se preseli iz Forms v repozitorije. Tako postane logika testna in kasneje ponovno uporabna prek UI, storitev in Jobs.

Pri Strangulation Pattern nastane novo ciljano »poleg« obstoječega: nove funkcionalnosti se že implementirajo v razvezani strukturi, medtem ko star sistem nadaljuje z delovanjem. Korak za korakom nova plast prevzame več odgovornosti, dokler stari deli ne odpadejo.

Primer (tipično B2B):

• Izluščite logiko naročil v domensko storitev.
• Obstoječi VCL-UI najprej uporablja isto storitev (brez prekinitve procesa).
• Vzporedno nastane REST-endpoint za portal strank ali integracijo.
• Po stabilizaciji se posamezni stari Forms zamenjajo – brez potrebe po ponovni izgradnji jedrne logike.

Tako zmanjšate tveganje projekta, ohranite obratovalnost in hitro pridobite merljive koristi (npr. API, zmogljivost, vzdrževanje).

Glede na izhodišče so ti gradniki pogosto relevantni – odločilna je prioritizacija po tveganju in poslovni vrednosti:

• BDE/Legacy-DB-Zugriff ablösen: moderni gonilniki/ponudniki, čiste transakcijske meje, reproducibilni deployments.
• Unicode: upravljanje nizov, baza podatkov/vmesniki, komponente tretjih ponudnikov.
• 64‑Bit: odvisnosti, pomnilnik/zmogljivost, zunanje knjižnice.
• API- und Service-Schicht: REST, Windows-/Linux-Services, integracije.
• Build & Release: CI/CD, upravljanje artefaktov, podpisani namestitveni paketi, rollback.

Pomembno: Te točke je idealno izvesti po razvezavi in zaščiti – potem je mogoče spremembe varno preveriti.

Popoln rewrite je v nekaterih primerih smiseln – pogosto pa je najdražja pot do »sodobne tehnologije«. Ta vprašanja pomagajo pri oceni:

• Je poslovna logika v celoti razumljena in testna – ali je veliko znanja implicitno v obratovanju?
• Ali obstajajo ostri roki (npr. konec platforme, skladnost), ki izključujejo vzporedno obratovanje?
• Kako velika je raznolikost variant (logika strank/mandantov)?
• Kako kritična je razpoložljivost in kako visoka je toleranca do sprememb procesov?
• Kateri deli so res »krivi« (UI, dostop do podatkov, integracije, deployment) – in kateri so stabilni?

V mnogih B2B-scenarijih vodi postopni pristop hitreje do merljivih rezultatov, saj nadzoruje tveganja in ščiti poslovno logiko.

Delphi-Modernizacijski audit (za procesno kritične aplikacije): analiziramo arhitekturo, odvisnosti, področja tveganja in dostavimo prioritizirano roadmapo, kako modernizirati, ne da bi izgubili poslovno logiko.

• Input: izvorna koda (read-only), Build-Setup, 2–3 ključni primeri uporabe, sistemsko okolje (DB, integracije).
• Rezultat: zemljevid poslovne logike/modulov, analiza tveganj in odvisnosti, priporočena ciljna arhitektura, načrt izvedbe v inkrementih vključno z zavarovanjem (testi/vzporedno delovanje).
• Neobvezno: Proof of Concept za ločitev + prvi Golden-Master-test.

Tako dobite zanesljivo podlago za odločanje, preden proračun in čas vložite v tvegan ponoven razvoj.

Ali je mogoče Delphi modernizirati, ne da bi aplikacijo ponovno pisali?
Da. V mnogih primerih se najprej ločita poslovna logika in dostop do podatkov, nato sledi tehnična modernizacija. To zmanjša tveganje in ohranja stabilnost obratovanja.

Kako preprečiti, da bi se poslovna logika »tiho« spreminjala?
S pomočjo Golden-Master-/regresijskih testov, telemetrije ter kontroliranega vzporednega delovanja z jasno rollback-strategijo.

Kateri koraki pogosto prinesejo najhitrejšo korist?
Preglednost (Assessment), razdružitev UI/SQL, BDE-zamenjava in API-/servisna plast za integracije – vsak korak zavarovan s testi.

Koliko časa traja modernizacija?
To je odvisno od kritičnih primerov uporabe, raznolikosti variant in odvisnosti. Revizija običajno v kratkem času zagotovi zanesljiv načrt izvedbe in prioritetne inkremente.