Technologie

Technologie nenasazujeme podle módy, ale podle provozní reality, životnosti, integračních potřeb a schopností týmu. Rozhodující není buzzword, ale to, zda systém zůstane později čistě provozovatelný, rozšiřitelný a převzatelný.

Kdy dává který směr smysl

Modernizace Delphi v praxi

Pokud je stará aplikace Delphi po odborné stránce stále hodnotná, nemodernizujeme naslepo. Nejprve analyzujeme, jak systém skutečně funguje, které procesy nese, kde se lámou datové toky a které historické zátěže brzdí provoz. Z toho vzniká modernizační cesta, která nepůsobí čistě jen na papíře, ale zůstává nosná i v každodenním provozu.

V mnoha vyvíjených aplikacích neleží skutečná hodnota v uživatelském rozhraní, ale v letech doménové logiky, speciálních pravidel, výjimek a zkušenostního know-how. Tuto substanci člověk nevyhazuje lehkovážně. Čistě oddělujeme odpovědnosti, znovu uspořádáme databázi, nahradíme staré přístupové cesty, vytvoříme nová rozhraní REST a podle potřeby doplníme klienty pro Windows, macOS a Linux na stejném odborném základě. Nevzniká tak tvrdý zlom, ale srozumitelný další vývoj s jasným technickým vymezením.

Často to také znamená vrátit historicky vyrostlé monolity do podoby, která bude udržitelná, testovatelná a rozšiřitelná. Stabilizuje se přístup k datům, business logika se uvolní z kódu uživatelského rozhraní, rozhraní se stanou plánovatelnými a budoucí rozšíření už není potřeba prosazovat proti stávajícímu stavu. Cílem není kosmetická modernizace, ale systém, který firmě znovu dá prostor pro nové požadavky.

Služby a servery jako součást téže architektury

Mnoho podnikových systémů dnes nepotřebuje jen klienta, ale také služby na pozadí, služby Windows nebo Linux a servery REST. Právě proto tyto části neplánujeme jako dodatečnou nástavbu, ale jako součást téže architektury. Služba, která se jen později nějak přidá, se téměř vždy stane výjimkou.

Pokud mají být data distribuovaně zpracovávána, rozhraní poskytována, exporty spouštěny, importy sledovány nebo úlohy časově řízeně vykonávány na pozadí, musí být technická odpovědnost vyjasněna od samého začátku. Které části běží v klientovi, které ve službě, které na serveru, jak se chyby stanou viditelnými, jak budou změny stavu dohledatelné, jak zůstane doménová logika konzistentní? Na tyto otázky odpovídáme včas, aby z jednotlivých stavebních bloků vznikl robustní celek.

To je rozhodující zejména u multiplatformních projektů. Desktopový klient na Windows, macOS nebo Linux nesmí z hlediska domény znamenat něco jiného než doprovodný server REST nebo služba na pozadí. Proto vždy uvažujeme společně datový model, procesy, oprávnění, integrace a provoz. Tak vzniká architektura, ve které klienti, služby a servery mluví stejným jazykem.

Náš princip

Technologie pro nás není systém víry. Rozhodující je, aby architektura, týmová proveditelnost, provoz a budoucí rozšíření odpovídaly firmě. Nevyhrává nejhlasitější platforma, ale ta, se kterou lze rozumně řídit riziko, udržovatelnost a růst.

Některé úlohy řešíme záměrně pomocí Delphi, protože tam vyzrálá business logika, výkonné klienty a multiplatformní schopnost uplatňují své silné stránky. Jiné požadavky se lépe hodí pro C#, pro služby, pro portál nebo pro kombinaci obojího. Dobrá architektura nevzniká z módy, ale z jasnosti: jakou odpovědnost má která část systému, jaká životnost se dá očekávat, jak velký je tým, jak kritický je provoz a jaká rozšíření v příštích letech realisticky přijdou?

Právě tam pro nás začíná profesionální vývoj softwaru. Nechceme dodat jen něco, co dnes funguje, ale vytvořit technický základ, který bude i později srozumitelný, převzatelný a ekonomicky udržitelný.

Časté otázky k technologiím a architektuře

Technologická rozhodnutí musí odpovídat týmu, doméně i provozu. Právě proto tyto otázky neřešíme abstraktně, ale vždy na konkrétním systému.