Razvoj InDoc EDGE ni zgodba o funkcionalnostih, ampak o odločitvah, ki morajo zdržati skozi čas.
Z razvojno ekipo smo se pogovarjali o tem, kako v praksi nastaja sistem, ki ga uporabljajo zahtevna okolja - in zakaj pri tem niso pomembni trendi, ampak zanesljivost.
Pozna se predvsem v načinu razmišljanja. Ne razvijamo stvari za hitro zmago, ampak za dolgoročno uporabo. Ko delaš s strankami, ki sistem uporabljajo leta, včasih desetletja , zelo hitro ugotoviš, da trendi pridejo in gredo, posledice odločitev pa ostanejo.
Zato je pri razvoju vedno prisotno vprašanje: bo to zdržalo tudi čez nekaj let? Ne samo danes.
Razvijamo in vzdržujemo platformo, ki mora delovati zanesljivo tudi takrat, ko je kompleksna, obremenjena in pod pritiskom. Ne gre samo za dodajanje funkcionalnosti, ampak za to, da sistem ostaja stabilen, pregleden in obvladljiv skozi čas.
Velik del našega dela ni viden navzven. Pogosto gre za izboljševanje, popravljanje in poenostavljanje stvari, ki so bile v preteklosti narejene hitreje, kot bi jih danes.
Razvoj pri tem ni linearen proces. Bolj je kot sestavljanje zgodbe ali sestavljanke. Imaš vizijo, potem pa skozi čas dodajaš posamezne dele, včasih kakšnega zamenjaš, včasih ugotoviš, da je treba kakšen kos sestaviti drugače. InDoc EDGE se gradi na ta način - postopno, skozi izkušnje in realne situacije.
Razvoj je razdeljen na frontend in backend, vendar v praksi delujemo zelo povezano. Backend predstavlja jedro sistema- podatke, procese, pravice in integracije. Frontend skrbi za uporabniško izkušnjo in dostopnost funkcionalnosti.
Čeprav uporabnik vidi eno platformo, v ozadju deluje več povezanih komponent. To pomeni, da moraš pri vsaki spremembi razmišljati širše, ne samo o tem, kaj bo delovalo, ampak kaj bo imelo posledice drugje.
Zelo zavestno. Tehnologij ne izbiramo zato, ker so nove ali popularne, ampak zato, ker so stabilne, preverjene in vzdrževane.
Na frontendu na primer postopno prehajamo na React - ne zato, ker je moderen, ampak ker ima dolgoročno podporo in omogoča vzdrževanje tudi v prihodnje. Na backendu uporabljamo preverjene tehnologije, dokumente pa dolgoročno ločujemo od podatkovne baze, ker se je to v praksi izkazalo kot nujno za zmogljivost.
Jure Knafeljc, Vodja enote Razvoj programske opreme
Iskreno. InDoc EDGE je zrasel kot monolit. To ni bila idealna arhitekturna odločitev, ampak realna posledica hitre rasti in potrebe, da se v kratkem času pokrije veliko funkcionalnosti.
Sčasoma se je pokazalo, da tak pristop prinaša omejitve. Spremeniš eno stvar, pa nehote vplivaš na drugo. To so izkušnje, ne teorija.
Danes sistem postopno razbijamo na bolj ločene module. Ne čez noč in ne na silo. Ob vsaki verziji del časa namenimo tudi tehničnim izboljšavam - ker vemo, da brez tega dolgoročno ne gre.
Razvoj danes pomeni tudi odgovornost za pretekle odločitve. Ne delaš na praznem listu, ampak na sistemu, ki ima svojo zgodovino.In to zgodovino moraš razumeti, ne ignorirati.
Največje obremenitve v praksi ne povzročajo količine dokumentov, ampak procesi: avtomatizirani postopki, masovne spremembe pravic, kompleksne logike.
Ko pride do težav, jih ne skrivamo. Sistem spremljamo z monitoringom, iščemo konkretna ozka grla in jih odpravljamo, včasih z optimizacijo kode, včasih s spremembo logike, včasih z infrastrukturo.
Pomembno je, da vemo, kje iskati vzrok in da ga tudi odpravimo, ne samo omilimo.
Seveda. Razvoj kompleksnega sistema brez napak ne obstaja.
Imeli smo primere, ko so se omejitve pokazale šele pri večjih obremenitvah. Takrat smo se ustavili, postavili simulacijska okolja in ugotovili, kaj v osnovi ne deluje. Nekaterih težav ne rešiš z več strežniki - takrat moraš popraviti temelje.
Razlika ni v tem, ali se napake zgodijo, ampak v tem, kako se nanje odzoveš.
Včasih to pomeni tudi počasnejši razvoj, kot bi si ga kdo želel. A dolgoročno je to edini način, da sistem ostane stabilen in obvladljiv.
Testiranje ni zadnji korak, ampak sestavni del razvoja. Vsak razvijalec testira svojo kodo, pogosto pa se ravno pri pisanju testov pokažejo napake ali slabe odločitve.
Zavedamo se, da lahko popravek ene stvari vpliva na drugo. Testi so tam zato, da to odkrijemo čim prej in ne šele pri uporabnikih. Takšen pristop je ključen tudi zato, ker delujemo v okoljih, kjer so sledljivost, varnost in certifikacije nujne, ne opcijske.
Vsaka verzija gre najprej v demo okolje. Tam jo testiramo mi in stranke.Predvsem integracije in specifične procese, ki so za njih ključni.
Vemo, da je nadgradnja občutljiva stvar. Zato se migracije izvajajo programsko, brez ročnih posegov, in šele, ko smo dovolj prepričani, gre verzija v produkcijo.
Razvoj ni zaprt v svoj mehurček. Tesno sodelujemo s poslovnimi rešitvami, ekipo QAja, produktnim vodenjem in drugimi ekipami.
Včasih pride do trenj, zaradi prioritet, rokov ali zahtev, ampak ravno to sodelovanje pomaga, da se odločitve sprejemajo z realnim razumevanjem posledic.
Razvijalci sistem poznamo od znotraj, kar pomeni, da marsikaj toleriramo, ker vemo, kaj se dogaja v ozadju. Uporabniki ne poznajo notranjega delovanja sistema – in tega jim ni treba. Kar pričakujejo, je jasnost in zanesljivost.
Če sistem nekaj časa potrebuje, mora to jasno pokazati. Če uporabnik ne ve, kaj se dogaja, hitro izgubi zaupanje, tudi če sistem v ozadju deluje pravilno.
Zato uporabniško izkušnjo razumemo kot del zanesljivosti, ne kot dodatek.
AI danes uporabljamo kot podporo razvoju. Za vključitev AI v sam produkt ne hitimo.
Najprej mora biti jasno, kje AI res pomaga uporabniku in kje bi bil samo dodatek zaradi trenda. Ne želimo funkcionalnosti, ki dobro zvenijo v predstavitvah, a ne rešujejo realnih problemov.
Ekipa. Dejstvo, da si lahko iskren, vprašaš, narediš napako in jo skupaj popraviš. In občutek, da razvijaš produkt, ki se uporablja v resnih okoljih in kjer zanesljivost ni samo lepa beseda.
Izkušnje. In zavedanje, da zaupanje ne pride iz obljub, ampak iz tega, da stvari delujejo. Tudi takrat, ko je težko.