Tehnoloogiad

Me ei vali tehnoloogiaid moevoolu järgi, vaid lähtudes käitamise reaalsusest, elutsüklist, integratsioonivajadustest ja meeskonna kompetentsist. Määrav ei ole märksõna, vaid see, kas süsteem jääb hiljem puhtalt käideldavaks, laiendatavaks ja üleantavaks.

Millal milline suund on mõistlik

Delphi-moderniseerimine praktikas

Kui vana Delphi-rakendus on valdkondlikult endiselt väärtuslik, ei moderniseeri me pimesi. Analüüsime kõigepealt, kuidas süsteem tegelikult töötab, milliseid protsesse see kannab, kus andmevood katkestuvad ja millised pärandkoormad pidurdavad käitamist. Sellest kujuneb moderniseerimistee, mis ei mõju puhas ainult paberil, vaid püsib igapäevaselt toimiv.

Paljudes välja kasvanud rakendustes ei peitu tegelik väärtus mitte kasutajaliideses, vaid aastate jooksul kogunenud äriloogikas, erireeglites, erandites ja kogemuslikus teadmises. Seda substantsi ei visata kergekäeliselt minema. Me eristame vastutused puhtalt, korrastame andmebaasi, eemaldame vanad ligipääsuteed, loome uued REST-liidesed ning lisame vajadusel kliendid Windows, macOS ja Linux jaoks samal ärilisel alusel. Nii ei teki järsku murdu, vaid jälgitav edasiarendus selge tehnilise lõikega.

Sageli tähendab see ka ajalooliselt kujunenud monoliitide viimist tagasi vormi, mis muutub hooldatavaks, testitavaks ja laiendatavaks. Andmetele ligipääs stabiliseeritakse, äriloogika eraldatakse kasutajaliidese koodist, liidesed muutuvad planeeritavaks ning tulevasi laiendusi ei pea enam olemasoleva vastu välja võitlema. Eesmärk ei ole kosmeetiline moderniseerimine, vaid süsteem, mis annab ettevõttele taas õhku uute nõuete jaoks.

Teenused ja serverid sama arhitektuuri osana

Paljud ettevõttesüsteemid ei vaja täna mitte ainult klienti, vaid ka taustateenuseid, Windows- või Linux-teenuseid ja REST-servereid. Just seetõttu ei planeeri me neid osi hilisema juurdeehitusena, vaid sama arhitektuuri osana. Teenus, mis lisandub alles hiljem kuidagi juurde, muutub peaaegu alati erandjuhtumiks.

Kui andmeid tuleb jaotatult töödelda, liideseid pakkuda, eksporti käivitada, importi jälgida või ülesandeid ajastatult taustal täita, peab tehniline vastutus olema algusest peale selge. Millised osad jooksevad kliendis, millised teenuses, millised serveris, kuidas muutuvad vead nähtavaks, kuidas on olekumuutused jälgitavad, kuidas püsib äriloogika järjepidev? Neile küsimustele vastame varakult, et üksikutest komponentidest kujuneks kandev terviksüsteem.

See on eriti oluline multiplatvormi projektides. Töölauaklient Windows, macOS või Linux peal ei tohi äriliselt tähendada midagi muud kui seda saatev REST-server või taustateenus. Seetõttu mõtleme andmemudeli, protsessid, õigused, integratsioonid ja käitluse alati koos. Nii tekib arhitektuur, milles kliendid, teenused ja serverid räägivad sama keelt.

Meie põhimõte

Tehnoloogia ei ole meie jaoks ususüsteem. Otsustav on, et arhitektuur, meeskonnale sobivus, käitlus ja tulevased laiendused sobituksid ettevõttega. Ei võida kõige valjem platvorm, vaid see, millega saab riski, hooldatavust ja kasvu mõistlikult juhtida.

Mõned ülesanded lahendame teadlikult Delphi-ga, sest seal toovad välja oma tugevused välja kasvanud äriloogika, jõudsad kliendid ja multiplatvormivõimekus. Teised nõuded sobivad paremini C#-ga, teenustega, portaaliga või nende kombinatsiooniga. Hea arhitektuur ei sünni moest, vaid selgusest: milline vastutus on millisel süsteemiosal, millist eluiga on oodata, kui suur on meeskond, kui kriitiline on käitlus ja millised laiendused on järgmistel aastatel realistlikult tulemas?

Just sealt algab meie jaoks professionaalne tarkvaraarendus. Me ei taha tarnida üksnes midagi, mis täna töötab, vaid luua tehnilise aluse, mis on ka hiljem arusaadav, üle võetav ja majanduslikult hooldatav.

Sagedased küsimused tehnoloogia ja arhitektuuri kohta

Tehnoloogilised otsused peavad sobituma tiimi, valdkondliku sisu ja käiduga. Just seetõttu ei selgita me neid küsimusi abstraktselt, vaid alati konkreetse süsteemi pinnalt.