Modernizācijas ceļš
Delphi modernizācija pārskatā
Delphi modernizācija reti ir tikai UI projekts. Parasti runa ir par to, lai no jauna sakārtotu profesionāli vērtīgas lietojumprogrammas tā, lai datu piekļuve, biznesa loģika, servisi, integrācijas un nākotnes platformu mērķi atkal saplūstu vienotā, dzīvotspējīgā arhitektūrā.
Saglabāt saturu, nevis izmest zināšanas
Daudzas lietojumprogrammas gadiem ilgi uzkrāj profesionālo loģiku, īpašos noteikumus un procesu zināšanas. Mēs identificējam, kas ir profesionāli vērtīgs, un nepieļaujam, ka šī substance tiek zaudēta akla restartēšanas dēļ.
Monolītus pārvērst pārvaldāmās slāņos
UI tuvs kods, datu piekļuve, atskaites, profesionālie noteikumi un tehniskais mantojums tiek skaidri nodalīti. Tikai tā kļūst ekonomiski iespējami jauni servisi, portāli, testi un paplašinājumi.
REST, saskarnes un platformas paredzēt kopainā
Modernizācija nebeidzas ar jaunu izskatu. REST serveri, fona pakalpojumi, aktuālie datubāzu pieslēgumi un vairāku platformu mērķi apzināti jāintegrē tajā pašā griezumā.
Kā rodas tīrs modernizācijas ceļš
Mēs nesākam ar vēlamo arhitektūru uz papīra, bet ar reālo esošo stāvokli. Kuri procesi ir kritiski, kuras daļas ir trauslas, kur ir sasaistes, kuri datubāzes jautājumi bremzē un kuri profesionālie noteikumi nedrīkst pazust?
- Koda, datubāzes, saskarņu un laidienu ceļu esošā stāvokļa analīze
- UI, biznesa loģikas un datu piekļuves nodalīšana
- Migrācijas ceļa definēšana bez nevajadzīga darbības pārtraukuma
- Sagatavošana REST, servisiem, portāliem vai jaunām klienta mērķplatformām
Modernizācija ir ceļš, nevis kosmētiska iejaukšanās
Mūsu mērķis ir lietojumprogramma, kas atkal ir paplašināma, testējama un ekspluatācijā noturīga. Tieši tur slēpjas atšķirība starp virsmas “relaunch” un īstu tehnisku atjaunošanu.
Tipiskas sākuma situācijas izaugušās Delphi sistēmās
Praksē modernizācijas projekti reti sākas ar skaidri norobežotu prasību specifikāciju. Bieži ir lietojumprogramma, kas profesionāli darbojas, bet tehniski gadu gaitā daudzās vietās ir izaugusi: formās ir iekļauta biznesa loģika, atskaites tieši piekļūst tabulām, palīgprocesi darbojas tikai atsevišķās darba vietās, un datubāzes struktūras atkal un atkal tika paplašinātas, nepārkārtojot kopējo griezumu.
Tieši šādās situācijās ir svarīgi nerunāt tikai par jaunu saskarni. Izšķiroši ir tas, kā lietojumprogramma patiesībā strādā šodien. Kuri profesionālie noteikumi ir kritiski? Kuras lietotāju grupas ar to strādā? Kuras funkcijas nekādā gadījumā nedrīkst izkrist? Kuras daļas var palikt, un kur tehniskā struktūra ir kļuvusi tik trausla, ka jebkurš neliels paplašinājums kļūst nesamērīgi dārgs?
Mēs šādās esošās situācijās regulāri redzam vienus un tos pašus modeļus: cieši sasaistītas datu piekļuves, grūti testējami īpašie ceļi, vēsturiski izauguši pārskati, trūkstoši servisu slāņi un izvietošana (Deployment), kas lielā mērā balstās uz atsevišķu cilvēku pieredzes zināšanām. Tas, kurš šos punktus skaidri atklāj, parasti ātri saprot, ka modernizācija nav abstrakts IT pasākums, bet tiešs sviras punkts uzturamībai, kļūdu novēršanai un nākotnes paplašināmībai.
Biznesa loģika ir iestrādāta formās
Ja noteikumi, plausibilitātes pārbaudes un izņēmuma gadījumi ir radušies tieši UI kodā, katrs paplašinājums kļūst dārgs. Modernizācijai šī loģika ir jāatdala no lietotāja saskarnes konteksta.
Datu bāze un lietojumprogramma ir pārāk cieši savijušās
Tieša piekļuve tabulām, nevienmērīgs SQL un vēsturiskas palīgtabulas bieži noved pie tā, ka ne servisi, ne portāli nevar korekti pieslēgties esošajam risinājumam.
Deployment balstās uz ieradumu, nevis struktūru
Ja būvējumi, konfigurācijas un laidieni darbojas tikai ar klusām īpašām zināšanām, modernizācija kļūst arī par ekspluatācijas projektu. Tieši šīs atkarības mēs padarām redzamas.
Kas mainās pēc labas Delphi modernizācijas
Veiksmīga modernizācija padara lietojumprogrammu ne tikai jaunāku, bet galvenokārt skaidrāku. Atbildības kļūst salasāmas, datu ceļi — izsekojami, un paplašinājumus atkal var plānot. Tas ir īpaši svarīgi uzņēmumiem, kuri nevēlas katru gadu sākt no nulles, bet kuriem nepieciešama stabila sistēma ar attīstāmu pamatu.
Parasti modernizācijas rezultātā rodas labāka biznesa loģikas, datu piekļuves, servisu un saskarnes nošķiršana. No tā izriet konkrēti ekspluatācijas ieguvumi: kļūdas var precīzāk norobežot, jaunus klientus vai portālus var pieslēgt kontrolētāk, REST saskarnēm ir stabils biznesa pamats un atjauninājumiem vairs nav jāizgāžas uz tām pašām vecajām sasaistēm.
Ne mazāk svarīga ir ekonomiskā puse. Uzņēmumi investē modernizācijā nevis lai tehnoloģiski izskatītos moderni, bet lai samazinātu risku, mazinātu laidienu izmaksas un nākotnes prasības atkal īstenotu ar saprātīgu piepūli. Ja jaunas prasības vairs nav jāimprovizē vecajā kodā, bet tās iederas tīrā arhitektūrā, modernizācija pārvēršas par reālu rīcībspēju.
No mantotās lietojumprogrammas līdz kontrolētai mērķarhitektūrai
Neatkarīgi no tā, vai runa ir par BDE aizstāšanu, jauniem REST serveriem un servisiem vai vēlāk par multiplatformu klientu: reālais ieguvums rodas tad, ja visi šie soļi netiek improvizēti atsevišķi, bet tiek plānoti, balstoties vienotā arhitektūrā.
Pēc kā uzņēmumi atpazīst, ka modernizācija tagad ir ekonomiskāka nekā gaidīšana
Ja jaunas prasības vienmēr jāizpilda caur vecajiem ceļiem, laidieni kļūst nervozi un esošais risinājums tomēr paliek biznesā neaizstājams, sakārtota pārbūve parasti ir ekonomiskāka nekā vēlākas avārijas pārbūves no nulles.
Biznesa loģika paliek izmantojama
Mēs esošos noteikumus, pārskatus un izņēmuma gadījumus neuzskatām par balastu, bet par biznesa kapitālu.
Problēmas kļūst redzamas agrīni
Altceļi, datubāzes tēmas, atkarības un migrācijas riski tiek nosaukti, pirms tie vēlāk skar ekspluatāciju.
Posmi, nevis pilnīgs pārrāvums
Modernizācija tiek sagriezta tā, lai ekspluatācija, testi un ieviešana paliktu kontrolējami.
Kas jums pēc pirmās modernizācijas sākotnējās izvērtēšanas ir konkrēti iegūts
Pirmais solis apzināti ir veidots neliels, lai lēmumu pieņēmējiem nebūtu jāpasūta liels projekts tikai tādēļ, lai iegūtu skaidrību.
- pamatota esošās sistēmas, biznesa loģikas un tehnisko bremzējošo punktu izvērtēšana
- prioritizēts skatījums uz datu piekļuvi, saskarnēm, UI-tuvinātu loģiku un ekspluatācijas riskiem
- ieteikums, kas var palikt, kam būtu jāpieskaras vispirms un kas var sekot vēlāk
Sākt modernizāciju bez lidojuma aklumā
Ja vēlaties zināt, kur ir tīrs ieejas punkts, jums vēl nav jāizlemj par relaunch. Jēdzīgi ir vispirms skaidrs tehniskais virziens.
BUJ par Delphi modernizāciju
Kritiskais punkts modernizācijā reti ir tikai saskarne. Parasti runa ir par biznesa loģiku, datiem, atkarībām un migrācijas stratēģiju, kas darbojas ikdienas ekspluatācijā.
Vai veca Delphi lietojumprogramma ir pilnībā jāaizstāj?
Nē. Bieži vien jēdzīgāka ir kontrolēta pārbūve: atjaunot datu piekļuvi, atsaistīt loģiku, papildināt ar servisiem un mērķēti modernizēt saskarnes.
Kā modernizācijā izvairīties no ekspluatācijas pārrāvuma?
Ar skaidriem starpposmiem, tīrām saskarnēm un migrācijas ceļu, kurā vecās un jaunās daļas var kontrolēti pastāvēt līdzās.
Vai esošā biznesa loģika vēlāk var pāriet arī uz servisiem vai portāliem?
Jā. Tieši tāpēc mēs atdalām Business-Logik no UI-tuvināta mantotā koda un ievietojam to struktūrā, ko klienti, servisi un API var izmantot kopīgi.
Lasīt apkopotus papildu jautājumus
Šīs īsās atbildes paliek šeit lapā. Centrālajā BUJ galvenajā lapā mēs tēmu papildus sakārtojam kontekstā ar arhitektūru, modernizāciju, platformām un ekspluatāciju.