Modernizavimo kelias
Delphi-Modernizacijos apžvalga
Paveldas. Struktūra. Ateitis.
Delphi-modernizacija kaip kontroliuojamas pertvarkymas, o ne rizikingas visiškas paleidimas iš naujo.
Delphi-modernizacija retai būna vien tik UI projektas. Dažniausiai siekiama taip pertvarkyti funkcionaliai vertingas programas, kad duomenų prieiga, verslo logika, servisai, integracijos ir būsimų platformų tikslai vėl susijungtų į tvarią architektūrą.
Esmę išsaugoti, o ne atmesti žinias
Daugelis sistemų talpina per metus susikaupusias verslo taisykles, išimtis ir procesų žinias. Mes nustatome, kas yra funkcionaliai vertinga, ir užkertame kelią, kad ši vertė nebūtų prarasta aklai pradedant iš naujo.
Monolitus paversti valdomomis sluoksnėmis
Su vartotojo sąsaja susijęs kodas, duomenų prieiga, ataskaitos, verslo taisyklės ir techninė skola bus aiškiai atskirti. Tik tokiu būdu nauji servisai, portalai, testai ir plėtiniai tampa ekonomiškai įgyvendinami.
REST, sąsajas ir platformas įtraukti į planavimą
Modernizacija neapsiriboja tik nauja išvaizda. REST-serveriai, foniniai servisai, šiuolaikinės duomenų bazių sąsajos ir daugplatformių tikslai turi būti sąmoningai integruoti į tą patį sprendimo išdėstymą.
Kaip susiformuoja aiškus modernizacijos kelias
Nesprendžiame nuo norimos architektūros ant popieriaus – pradedame nuo tikrosios būklės. Kurių procesų veikimas yra kritinis, kurie komponentai yra trapūs, kur yra griežtos priklausomybės, kas stabdo duomenų bazės sluoksnį ir kurios verslo taisyklės neturi būti prarastos?
- Esamos būklės analizė: kodas, duomenų bazė, sąsajos ir leidimų (release) keliai
- Vartotojo sąsajos, verslo logikos ir duomenų prieigos atskyrimas
- Migracijos kelio apibrėžimas be bereikalingo operacijų sutrikdymo
- Paruošimas REST, servisams, portalams ar naujoms kliento tikslinėms platformoms
Modernizacija yra procesas, o ne kosmetinis pakeitimas
Mūsų tikslas – sistema, kuri vėl būtų išplečiama, testuojama ir operaciškai patikima. Būtent čia slypi skirtumas tarp paviršiaus atnaujinimo ir tikros techninės atnaujos.
Tipinės pradinės situacijos išaugusiose Delphi sistemose
Praktikoje modernizacijos projektai retai prasideda nuo aiškaus reikalavimų aprašo. Dažnai yra sistema, kuri funkciškai veikia, bet technine prasme per metus išaugo daugelyje vietų: formos talpina verslo logiką, ataskaitos tiesiogiai skaito lenteles, pagalbiniai procesai veikia tik atskiruose darbo vietose, o duomenų bazių struktūros nuolat plečiamos neperžiūrint viso sprendimo išdėstymo.
Būtent tokiose situacijose svarbu kalbėti ne tik apie naują sąsają. Lemiama yra tai, kaip sistema iš tiesų veikia šiandien. Kurios verslo taisyklės yra kritinės? Kokios naudotojų grupės joje dirba? Ko jokiu būdu negali nutrūkti? Kuriuos komponentus galima palikti tokiais, kokie jie yra, ir kur techninė struktūra tapo tokia trapi, kad kiekvienas mažas plėtimas tampa neproporcingai brangus?
Tokiose esamose situacijose mes reguliariai matome tuos pačius modelius: stipriai susietas duomenų prieigas, sunkiai testuojamus specialius kelių variantus, istorinius ataskaitų sprendimus, trūkstamus paslaugų sluoksnius ir diegimo procesą, stipriai priklausomą nuo kelių asmenų patirties. Kas aiškiai atskleidžia šias problemas, greitai supranta, kad modernizacija nėra abstrakti IT priemonė, o tiesioginis svertas išlaikomumui, klaidų prevencijai ir būsimai išplečiamumui gerinti.
Verslo logika įterpta formose
Kai taisyklės, patikrinimai ir išimtys yra įkoduotos tiesiai į UI kodą, kiekvienas plėtimas brangsta. Modernizacija turi iškelti šią logiką iš sąsajos konteksto.
Duomenų bazė ir programa per stipriai susipynę
Tiesioginiai lentelių užklausimai, nevienodas SQL ir istorinės pagalbinės lentelės dažnai trukdo tam, kad servisai ar portalai galėtų tvarkingai prisijungti prie esamos bazės.
Diegimas remiasi įprotį, o ne struktūrą
Jei build’ai, konfigūracijos ir leidimai veikia tik dėl neišsakytų žinių, modernizacija tampa ir operacijos projektu. Būtent tokias priklausomybes mes padarome matomas.
Kas keičiasi po geros Delphi modernizacijos
Sėkminga modernizacija daro sistemą ne tik naujesnę, bet ir labiau suprantamą. Atsakomybės tampa įskaitomos, duomenų keliai – sekami, o plėtojimas vėl tampa planuojamas. Tai ypač svarbu įmonėms, kurios nenori kasmet pradėti nuo nulio, o siekia tvarios sistemos su tobulinamos vertės pagrindu.
Tipiškai modernizacija duoda geresnį verslo logikos, duomenų prieigos, servisų ir sąsajos atskyrimą. Iš to kyla konkrečios operacinės naudos: klaidas galima aiškiau lokalizuoti, nauji klientai ar portalai gali būti prijungti kontroliuojamai, REST-sąsajos turi stabilų funkcionalų pagrindą ir atnaujinimai nebėra sutrikdomi tomis pačiomis senomis priklausomybėmis.
Ne mažiau svarbi yra ir ekonominė pusė. Įmonės investuoja į modernizaciją ne tam, kad atrodytų techniškai modernios, o tam, kad sumažintų riziką, sumažintų leidimų išlaidas ir vėl galėtų įgyvendinti naujus reikalavimus pagrįstomis sąnaudomis. Kai nauji reikalavimai nebėra improvizuojami į seną kodą, o įsilieja į aiškią architektūrą, modernizacija tampa tikra veiksmų galimybe.
Nuo senos programos iki kontroliuojamos tikslo architektūros
Ar tai būtų BDE-pakeitimas, nauji REST-serveriai ir servisai ar vėlesnis daugplatforminis klientas: tikroji nauda atsiranda, kai visi šie žingsniai planuojami ne atskirai improvizuojant, o iš tos pačios architektūros.
Kaip įmonės atpažįsta, kad modernizacija dabar ekonomiškesnė už laukimą
Jei nauji reikalavimai visada turi eiti per senus keliukus, leidimų procesai tampa nervingi, o esama sprendimo dalis vis tiek yra nepakeičiama, tvarkingas pertvarkymas dažnai yra ekonomiškesnis už vėlesnį skubotą naujos sistemos kūrimą.
Verslo logika lieka naudojama
Mes nevertiname esamų taisyklių, ataskaitų ir išimčių kaip našto, o kaip funkcionalų kapitalą.
Problemos matomos anksti
Senieji keliai, duomenų bazių klausimai, priklausomybės ir migracijos rizikos yra identifikuojamos prieš tai, kol jos paveiks operacijas.
Etapai vietoje visiško lūžio
Modernizacija yra suskirstoma taip, kad operacijos, testavimas ir įdiegimas liktų kontroliuojami.
Ką konkrečiai turite po pirmos modernizacijos įvertinimo
Pirmasis žingsnis yra sąmoningai mažas, kad sprendimų priėmėjams nereikėtų užsakyti didelio projekto vien tam, kad gautų aiškumą.
- patikima esamos būklės, verslo logikos ir techninių stabdžių įvertinimo išvada
- prioritetinė perspektyva į duomenų prieigą, sąsajas, UI artimą logiką ir operacines rizikas
- rekomendacija, kas gali likti, kas turėtų būti paliesta pirmiausia ir kas gali sekti vėliau
Pradėkite modernizaciją be skrydžio aklai
Jei norite sužinoti, kur yra tvarkingas startas, jums dar nereikia nuspręsti dėl pilno relaunch. Pirmiausia verta turėti aiškią techninę kryptį.
DUK apie Delphi-modernizaciją
Kritinė modernizacijos vieta retai būna tik sąsaja. Dažnai esmė yra verslo logika, duomenys, priklausomybės ir migracijos strategija, kuri veikia kasdienėje operacijoje.
Ar seną Delphi programą reikia visiškai pakeisti?
Ne. Dažnai labiau verta kontroliuojamas pertvarkymas: atnaujinti duomenų prieigą, atskirti logiką, pridėti servisus ir tiksliai modernizuoti sąsajas.
Kaip išvengti operacijų sutrikimo modernizacijos metu?
Per aiškias tarpines stadijas, tvarkingas sąsajas ir migracijos kelią, kuriame senos ir naujos dalys gali kontroliuojamai egzistuoti lygiagrečiai.
Ar esama verslo logika vėliau gali būti perkelta į servisus ar portalus?
Taip. Būtent todėl mes iškeliame verslo logiką iš su UI susijusio seno kodo ir perkeliam ją į struktūrą, kurią kartu gali naudoti klientai, servisai ir API.
Skaitykite daugiau DUK
Šie trumpi atsakymai lieka čia puslapyje. Centrinėje DUK apžvalgos puslapio dalyje temą papildomai išdėstome kartu su architektūra, modernizacija, platformomis ir eksploatacija.