Platformas stratēģija
Delphi Daudzplatformu pārskats
Delphi mums ir īpaši spēcīgs tur, kur kopā strādā nobriedusi biznesa loģika, veiktspējīgi darbvirsmas procesi un vairākas mērķa platformas. Multiplatforma mums nav mārketinga solījums, bet apzināti plānots tehniskais griezums pāri Windows, macOS un Linux.
Kopīga loģika, skaidras platformu robežas
Biznesa noteikumi, datu modeļi un integrācijas loģika tiek strukturēti tā, lai ne katra platforma izdomātu savu atsevišķu biznesa versiju.
Darbvirsmas procesi ar reālu produktivitāti
Īpaši uzņēmumu lietotnēs nozīmīgi ir īsinājumtaustiņu ceļi, tabulas, druka, atskaites un datu konteksts. Šīs stiprās puses var arī multiplatformas režīmā korekti pārnest.
Pakošanu, parakstīšanu un ekspluatāciju plānot savlaicīgi
Multiplatforma bieži izgāžas nevis koda dēļ, bet gan dēļ novēloti izdomātiem build-, packaging- un release jautājumiem. Tieši šos punktus mēs noskaidrojam agrīni.
Kas multiplatformu padara ekonomiski jēgpilnu
Vairāki klienti ir pamatoti tad, ja procesiem dažādās darba vietās jāpaliek konsekventiem, kamēr ir spēkā tā pati biznesa loģika, tie paši dati un tās pašas tiesības. Tieši tad kopīga koda un arhitektūras stratēģija rada reālu vērtību.
Kopīgs datu modelis
Darbvirsmai, servisam un portālam ir jārunā vienā un tajā pašā biznesa valodā. Tas sākas ar datu modeli un beidzas ar apstiprinājumiem, lomām un žurnalēšanu.
Skaidras integrācijas robežas
REST-API, fona servisi un lokālās funkcijas tiek sagrieztas tā, lai platformas jautājums neradītu biznesa nekonsekvenci.
Reālistiski mērķa attēli
Ne katrai funkcijai katrā platformā jāizskatās identiski. Izšķiroši ir, lai kopējā sistēma atbilstu reāliem darba procesiem.
Kas Delphi multiplatformā praksē patiešām ir izšķirošs
Multiplatformu projekti reti izgāžas tāpēc, ka logu nevar atvērt vairākās sistēmās. Patiesie izaicinājumi ir dziļāk: failu sistēma, parakstīšana, druka, pakošana, ārējās bibliotēkas, datubāzu draiveri, atjauninātāji, lietotāju tiesības un mērķa sistēmu ikdienas darba atšķirības ir jādara redzamas savlaicīgi.
Īpaši uzņēmumu lietotnēs nepietiek panākt vienotu lietotāja saskarnes stāvokli. Svarīgāk ir, lai biznesa loģika, datu modelis un procesu noteikumi pāri Windows, macOS un Linux paliktu konsekventi. Laba multiplatformu sistēma lietotājam neizskatās kā trīs tehniski varianti, bet kā kopīga biznesa līnija ar apzināti noteiktām platformu robežām.
Tāpēc mēs multiplatformu neplānojam kā kosmētisku papildinājumu. Mēs pārbaudām, kurām funkcijām jāpaliek lokālām, kuras labāk kopīgi nodrošināt caur servisiem vai REST-serveriem, un kur plattformspecifiskās atšķirības jāapstrādā apzināti. Tā no kopīgās koda bāzes rodas ekspluatējama sistēma, nevis demo ar daudziem īpašajiem gadījumiem.
Platformai tuvas funkcijas kontrolēti atsaistīt
Druka sistēma, failu sistēma, lokālās integrācijas un parakstīšana ir apzināti jānošķir, lai biznesa loģika pati nepieķertos atsevišķām mērķplatformām.
Kopīga servera loģika atslogo klientus
Ja darbvirsmas klientiem nav vieniem pašiem jānes visa biznesa atbildība, daudzplatformu ieceres bieži kļūst ievērojami robustākas un vienkāršākas ekspluatācijā.
Build- un piegādes ceļus definēt agrīni
Saprātīga daudzplatformu pieeja par paketēšanu, atjaunināšanas ceļiem, testēšanas matricu un ieviešanu domā nevis tikai beigās, bet jau lietojumprogrammas sadalījumā.
Kad daudzplatformu pieeja ir jēgpilna un kad nē
Ne katrs projekts automātiski iegūst no vairākiem klienta mērķiem. Ekonomiski daudzplatformu pieeja kļūst tur, kur no tās ilgtermiņā iegūst biznesa domēns, komanda, mērķgrupas un ekspluatācijas modelis. Dažkārt pietiek ar spēcīgu Windows-klientu. Citkārt tieši kopīgā stratēģija Windows, macOS un Linux ir īstā konkurences priekšrocība.
Tāpēc mēs agrīni noskaidrojam, kurām lietotāju grupām ir kādas prasības, kuras platformas ir produktīvi nozīmīgas un kurām biznesa loģikas daļām obligāti visur jāpaliek vienādām. No tā izriet reālistisks mērķa attēls: reizēm īsts daudzplatformu klients, reizēm darbvirsmas un serverpakalpojumu kombinācija, reizēm hibrīds no Delphi-klienta un portāla.
Ja šis lēmums tiek pieņemts korekti, daudzplatformu pieeja nav pašmērķis, bet ekonomisks arhitektūras būvbloks. Uzņēmumi tad iegūst ne tikai vairākas mērķplatformas, bet struktūru, kurā jau ir ieplānoti nākotnes paplašinājumi, jaunas platformas un vēlākie ekspluatācijas jautājumi.
Pēc kā uzņēmumi atpazīst, ka Delphi daudzplatformu pieeja stratēģiski der
Daudzplatformu pieeja ir vērtīga nevis etiķetes dēļ, bet tad, ja vairākām mērķplatformām jāpiekļūst vienam un tam pašam biznesa kodolam, neļaujot procesiem izklīst.
Kopīgs biznesa pamats samazina turpmākās izmaksas
Ja noteikumi, datu modelis un procesu loģika nav jābūvē vairākkārt, paplašinājumi paliek kontrolējami.
Platformu atšķirības tiek atmaskotas agrīni
Failu sistēma, druka, parakstīšana, draiveri un paketēšana kļūst redzami, pirms tie nobloķē ieviešanu.
Darbvirsma, pakalpojumi un mobilie ceļi var tīri sadarboties
Laba daudzplatformu stratēģija kontrolēti sagatavo arī vēlākas API, portālus vai mobilos atzarojumus.
Kā tiek sagatavots saprātīgs daudzplatformu lēmums
Pirms tiek investēts, ir vajadzīga pamatota atbilde uz to, kurām daļām patiešām jāpaliek kopīgām un kur apzināti būtu jānošķir.
- produktīvi nozīmīgo mērķplatformu un lietotāju grupu klasifikācija
- tehnisks skatījums uz kopīgo biznesa loģiku, platformai specifiskajiem klupšanas akmeņiem un izvietošanu
- ieteikums, vai ekonomiskāks ir īsts daudzplatformu klients, hibrīdmodelis vai ar serveri balstīta sadale
Daudzplatformu pieeju plānot bez demo slazda
Ja ir vairāki mērķa risinājumi, lēmumam nevajadzētu balstīties uz intuīciju, bet gan uz arhitektūru, ekspluatāciju un reālu lietošanas uzvedību.
Biežāk uzdotie jautājumi par Delphi multiplatformu
Multiplatforma darbojas tīri tikai tad, ja koda bāze, datu modelis, platformu atšķirības un izvietošana tiek apzināti izplānoti. Tieši tur rodas patiesā projekta vērtība.
Vai viena un tā pati lietotne tiešām var darboties uz Windows, macOS un Linux?
Jā, ja lietotāja saskarne, biznesa loģika, platformas īpatnības un laidienu procesi netiek sajaukti, bet tiek skaidri strukturēti.
Kāda ir visbiežāk pieļautā kļūda multiplatformu projektos?
Pārāk vēlu sākt domāt par failu sistēmu, drukāšanu, parakstīšanu, mērķa platformām, pakotņošanu un UI atšķirībām. Tad multiplatforma ātri kļūst dārga un nekonsekventa.
Vai pakalpojumi un API var izmantot to pašu biznesa loģiku?
Jā. Laba arhitektūra nodrošina, ka ne katra platforma izveido savu atsevišķu domēna ceļu.
Lasīt apkopotus papildu jautājumus
Šīs īsās atbildes paliek šeit, šajā lapā. Centrālajā FAQ nolaišanās lapā mēs tēmu papildus sakārtojam kontekstā ar arhitektūru, modernizāciju, platformām un ekspluatāciju.