Kako danes razvijamo InDoc EDGE
Pogovor s člani razvojne ekipe - Jernej Janež, Jure Knafeljc, Emil Avdič
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.
Kako se dolgoletne izkušnje ekipe Mikrocopa odražajo pri razvoju InDoc EDGE?
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.
Kako bi svoje delo opisali nekomu, ki ne pozna IT-ja?
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.
Kako je danes organizirana razvojna ekipa?
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.
Kako izbirate tehnologije - še posebej v času, ko se trendi hitro menjajo?
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.
»Nikoli ne veš, kaj bo čez pet let - lahko pa se odločiš, kaj je danes najbolj smiselno.«

Jure Knafeljc, Vodja enote Razvoj programske opreme
Kako je zasnovana arhitektura sistema InDoc EDGE?
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.
Kako se soočate z obremenitvami, skalabilnostjo in zmogljivostjo?
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.
So se v vseh teh letih zgodile tudi napake?
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š.
»Napake so del razvoja. Odgovornost je v tem, kaj narediš potem.«
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.
Kako skrbite za kakovost kode in testiranje?
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.
Kako potekajo nadgradnje brez vpliva na uporabnike?
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.
Kako poteka sodelovanje z drugimi ekipami?
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.
Kako gledate na uporabniško izkušnjo (UX)?
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.
Jernej Janež, programer
Kakšen je vaš odnos do novih tehnologij, kot je AI?
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.
»Ni vprašanje, ali bo AI, ampak kje ima smisel.«
Kaj vas pri delu najbolj motivira?
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.
Kaj bi rekli, da je največja vrednost Mikrocopa po 50 letih?
Izkušnje. In zavedanje, da zaupanje ne pride iz obljub, ampak iz tega, da stvari delujejo. Tudi takrat, ko je težko.