Autor: Ivan Periša, Abysalto, Software Engineer – student, Power, Utility and Transport Squad, eTicketing Unit
Prvi ozbiljan projekt obično promijeni način na koji developeri gledaju na razvoj softvera. Fakultetski zadaci uglavnom imaju jasno definirane uvjete i kontrolirano okruženje, dok rad na stvarnom sustavu vrlo brzo otvori pitanja koja se tijekom studiranja rijetko pojavljuju. Upravo se to dogodilo nama, grupi studenata koji smo kroz projekt u Abysaltu prvi put radili s embedded Linuxom, modernim C++-om i sustavima koji moraju dugoročno raditi stabilno u produkcijskim uvjetima.
Kada development postane stvarni sustav
Projekt je od početka uključivao suradnju senior inženjera i studenata, što se pokazalo važnim jer je riječ bila o sustavu s velikim brojem međusobno povezanih komponenti. Seniori su imali širu sliku arhitekture, komunikacije između uređaja i backenda te ograničenja koja proizlaze iz rada na stvarnom hardveru. Studenti su postupno preuzimali implementaciju pojedinih dijelova sustava, ali paralelno s time učili kako razmišljati o stabilnosti, održavanju i ponašanju aplikacije u situacijama koje nije moguće jednostavno simulirati lokalno.
U praksi je to značilo rad sa SDK-ovima za NFC, barcode i QR čitače, ekran i audio sustav, ali i razumijevanje svega što dolazi nakon prvog uspješnog builda. Svaka nova funkcionalnost otvarala je pitanja o tome što se događa ako uređaj izgubi konekciju, kako će se problem dijagnosticirati na terenu ili kako će se sustav ponašati nakon nekoliko tjedana neprekidnog rada.
Tehnologija je bila posljedica problema koji smo rješavali
Zbog toga su i tehnološke odluke bile vrlo pragmatične. Za validatore i centralni uređaj korišten je C++ jer su uređaji imali ograničene resurse i zahtijevali stabilne performanse. Istovremeno, backend je razvijan u C# .NET-u, tehnologiji u kojoj je tim već imao iskustvo i uspostavljene procese.
Za vremenski osjetljive operacije, poput validacije karata i obrade kupnji, korišten je gRPC, dok je REST ostao rezerviran za sinkronizaciju stanja, metrike i operacije koje nisu zahtijevale komunikaciju u stvarnom vremenu.
Takve odluke studentima su bile posebno korisne jer su pokazale kako se tehnologija u produkciji bira prema konkretnom problemu koji treba riješiti. Tijekom studiranja rasprave o tehnologijama često ostaju na razini mogućnosti i trendova, dok produkcijski sustavi vrlo brzo pokažu da su stabilnost, održavanje i dugoročna pouzdanost puno važniji kriteriji.
Problem koji na papiru izgleda jednostavno
Sama poslovna logika također je bila složenija nego što se na prvi pogled činilo. Korisnik kupi kartu i očekuje da validacija odmah radi, ali iza tog procesa postoji niz ograničenja.
Validatori nemaju direktan pristup internetu nego komuniciraju s centralnim uređajem, a centralni uređaj dalje razmjenjuje podatke s backendom. Sustav je pritom morao funkcionirati i u offline scenarijima bez vidljivog utjecaja na korisničko iskustvo.
Dodatnu složenost stvarala je činjenica da je isti NFC čitač morao podržavati dvije različite vrste kartica: ZET-ove MIFARE kartice i kreditne kartice kroz tap-to-pay integraciju s vanjskim partnerom. Takva integracija zahtijevala je jasno definirane granice odgovornosti između komponenti sustava, ali i pažljivo upravljanje komunikacijom i stanjem uređaja.
Upravo u takvim situacijama postaje jasno koliko su produkcijski sustavi složeniji od onoga što korisnik vidi na površini.
Najveća promjena dogodila se u načinu razmišljanja
Kako smo ulazili dublje u projekt, postalo je jasno da najveći izazovi nisu vezani uz sintaksu ili pojedini framework. Moderni C++ razlikovao se od onoga što smo ranije koristili na fakultetu, ali važnije od samog jezika bilo je razumijevanje posljedica koje određene odluke imaju u dugotrajnom radu sustava.
Pitanja o upravljanju memorijom, stabilnosti konekcije ili ponašanju uređaja nakon višednevnog rada postala su svakodnevni dio razvoja. Upravo je tu mentorski dio projekta imao najveću vrijednost.
Tijekom code review procesa seniori nisu samo pregledavali implementaciju, nego su nas usmjeravali prema problemima koje sami još nismo znali prepoznati. Razgovori su često uključivali pitanja o dijagnostici, praćenju ponašanja sustava i mogućnosti održavanja aplikacije nakon deploya.
Produkcija počinje tek kada nešto pođe po krivu
To se posebno vidjelo na primjeru logiranja i monitoringa. Na početku projekta razvili smo vlastiti logger jer nam se činilo da je to dovoljno za potrebe aplikacije. Međutim, kroz razgovore sa seniorima vrlo brzo se otvorilo pitanje kako će se problem analizirati ako uređaj prestane raditi na terenu ili kako će se prepoznati postupni rast memorije tijekom duljeg vremenskog razdoblja.
Kao rezultat toga uvedene su metrike za stanje uređaja, memoriju, latency i uptime, a logovi su sinkronizirani prema backendu uz rotaciju i nadzor rada uređaja.
Takve promjene pokazale su nam koliko se produkcijski sustavi razlikuju od razvojnih okruženja u kojima je većina problema odmah vidljiva developeru. Upravo u tom trenutku postalo nam je jasno zašto iskusni inženjeri toliko pažnje posvećuju stvarima koje junior developerima u početku često djeluju sporedno.
Softver ne završava deploymentom
Paralelno s glavnim projektom razvijan je i interni sustav za upravljanje uređajima na terenu. Sustav je omogućavao pregled verzija softvera, praćenje logova i metrika te udaljeno slanje naredbi za konfiguraciju, restart ili deployment novih verzija aplikacije.
CI/CD pipeline radio je build i release aplikacije, dok su uređaji preuzimali nove verzije tek nakon kontrolirane naredbe za update. Takav pristup bio je važan jer se kod velikog broja uređaja mora voditi računa o stabilnosti cijelog sustava. Istovremeni restart ili update svih uređaja mogao bi stvoriti dodatne probleme, pa je način upravljanja deploymentom postao jednako važan kao i sama implementacija funkcionalnosti.
Lekcije koje ostaju i nakon projekta
Kada danas gledamo na projekt, najveće lekcije nisu vezane uz pojedinu tehnologiju nego uz način razmišljanja koji razvoj produkcijskog softvera zahtijeva.
Kroz rad sa seniorima naučili smo koliko je važno promatrati sustav dugoročno, koristiti postojeća i provjerena rješenja kada za to postoji razlog te razumjeti da kvaliteta softvera ne ovisi samo o tome radi li određena funkcionalnost u trenutku razvoja.
Najvažnije iskustvo ipak je bilo razumijevanje uloge mentorstva u razvoju mladih inženjera. Kroz projekt smo vidjeli koliko kvalitetan code review i pravovremena pitanja mogu ubrzati proces učenja i pomoći junior developerima da postupno počnu razmišljati o sustavu iz šire perspektive.
Upravo je to bio dio projekta koji je dugoročno ostavio najveći utjecaj na način na koji danas pristupamo razvoju softvera.
