Kraj pregledanja koda red po red

Problem tradicionalne revizije koda

Tradicionalni proces provere izvornog koda u softverskoj industriji decenijama počiva na ljudskom čitanju svake linije napisane promene. Programeri u ulozi recenzenata sede pred monitorima i analiziraju razlike između stare i nove verzije fajlova. Takav pristup je bio održiv u vreme kada je obim napisanog koda bio znatno manji, a brzina izbacivanja novih funkcija spora. Danas, sa masovnom primenom generativne veštačke inteligencije, količina generisanog koda prevazilazi ljudske kapacitete za detaljno čitanje. Timovi često zapadaju u zamku gde modeli automatski generišu rešenja, dok ljudi površno prelistavaju rezultate i klikću dugme za odobrenje.

Glavni nedostatak ovog modela leži u činjenici da modeli veštačke inteligencije nemaju uvid u širi kontekst specifične baze koda. Oni ne poznaju nepisana pravila određenog tima, niti imaju svest o prethodnim poslovnim odlukama koje su oblikovale arhitekturu sistema. Kada se od modela zatraži da oceni sopstveni rad ili rad drugog modela, javljaju se iste sistemske praznine u razumevanju. Ljudi sa druge strane postaju usko grlo sistema jer troše sate na traženje sitnih grešaka umesto da se bave suštinskim arhitektonskim izazovima.

Odgovornost za softver u proizvodnji uvek mora pripadati ljudima, dok mašine mogu služiti kao alat za verifikaciju. Kada se sav teret provere prebaci na ljudsko oko koje je već umorno od svakodnevnih zadataka, kvalitet neizbežno opada. Zbog toga industrija traži nove načine organizovanja procesa razvoja softvera. Cilj nije odbacivanje modernih alata, već njihovo postavljanje na pravo mesto u radnom okruženju.

Uvođenje trajnih pravila i invarijanti

Temelj novog pristupa proveri koda čine takozvane invarijante, odnosno kodifikovana pravila koja tim postavlja pre nego što bilo kakva izmena počne da se piše. U tradicionalnom okruženju, pravila o tome kako se piše kod nalaze se uglavnom u glavam iskusnih inženjera i ispoljavaju se kroz komentare tokom revizije. Primeri takvih pravila uključuju obavezno korišćenje određenog tipa podataka za novčane iznose, zabranu direktnog upisivanja u korisničke tabele baze podataka ili obavezno emitovanje brojača grešaka na svakoj putanji izuzetka. Kada ova pravila nisu jasno zapisana, programeri i generativni modeli ih neizbežno ponovo krše.

Invarijante predstavljaju pisana pravila koja automatski skriptovi ili specijalizovani verifikacioni modeli proveravaju na svakoj novoj promeni koda. Umesto da se oslanjaju na pamćenje pojedinaca, timovi stvaraju registar pravila na osnovu istorije prethodnih komentara u sistemima poput Githuba. Alati za verifikaciju mogu automatski da analiziraju stare komentare tima i predlože nacrte pravila. Svaki predlog prolazi kroz ljudsku kontrolu pre nego što postane zvanično pravilo tima.

Uspeh ovog koncepta zavisi od tri ključna elementa: vlasništva, formulacije i opsega. Vlasništvo znači da svaki nacrt pravila mora da odobri tim na koji se ono odnosi. Formulacija mora da se fokusira na željeni ishod, a ne na samu implementaciju, kako pravilo ne bi gubilo smisao prilikom preimenovanja fajlova. Opseg osigurava da se pravila primenjuju samo tamo gde imaju smisla, poput odvajanja provera za korisnički interfejs od migracija baze podataka.

Snimanje namere i kriterijuma prihvatanja

Razumevanje razloga zbog kojeg je neka izmena uopšte napravljena predstavlja suštinski deo svake kvalitetne revizije. Tradicionalni način dokumentovanja namere oslanja se na pisanje opsežnih specifikacija unapred ili kreiranje detaljnih zadataka u sistemima za upravljanje projektima. Specifikacije često gube korak sa stvarnošću jer se pišu pre nego što programeri uđu u sam proces kodiranja i suoče se sa tehničkim preprekama.

Najprecizniji podaci o nameri izmene nastaju tokom same sesije programiranja između inženjera i veštačke inteligencije. Kada model zastane da postavi pitanje, a inženjer donese odluku, kriterijumi prihvatanja se definišu u realnom vremenu. Umesto da se te informacije izgube po završetku sesije, savremeni alati za verifikaciju automatski izdvajaju nameru i kriterijume direktno iz radne sesije pre nego što se kôd pošalje na dalju obradu.

Namera precizno definiše zbog čega je određena promena napravljena, dok kriterijumi prihvatanja opisuju kako sistem treba da se ponaša nakon izmene. Inženjer ima priliku da pregleda i ispravi ove automatski izvučene podatke pre podnošenja koda. Na taj način recenzenti kasnije dobijaju jasan uvid u polaznu tačku zadatka bez potrebe da rekonstruišu misli autora kroz čitanje sirovog koda.

Beleženje ključnih odluka tokom rada

Tokom svake sesije razvoja softvera donosi se veliki broj odluka koje nikada ne dospeju u konačni pregled koda. Odluke o tome gde se čuva stanje aplikacije, šta se dešava kada zataji spoljna zavisnost ili da li treba ponovo iskoristiti postojeću pomoćnu funkciju ostaju nevidljive u običnom prikazu razlika koda. Kada softver piše veštačka inteligencija, broj ovakvih skrivenih odluka drastično raste jer model samostalno pravi izbore tokom generisanja rešenja.

Novi sistemi za reviziju beleže ove odluke uporedo sa namerom izmene. Softver jasno odvaja odluke koje je doneo veštački model od onih koje je doneo čovek. Recenzent tako tačno zna ko je doneo koju odluku i ima mogućnost da preispita upravo te kritične tačke umesto da gubi vreme na sintaksu. Fokus se sa prostog prebrojavanja linija koda pomera na preispitivanje logike i rešenja.

Praćenje odluka donosi viši nivo transparentnosti u radu inženjerskih timova. Kada se pojavi greška u produkciji, lakše se ulazi u trag uzroku jer postoji zabeležen zapis o tome zašto je izabrano baš to tehničko rešenje. Time se smanjuje zavisnost od pojedinaca i olakšava prenošenje znanja na nove članove tima koji dolaze u organizaciju.

Testni planovi i automatski dokazi

Kada se izmena koda pošalje na reviziju, sistem kombinuje definisanu nameru, kriterijume prihvatanja i primenjive invarijante u jedinstven testni plan. Umesto da se testovi pišu ručno za svaki pojedinačni slučaj, verifikacioni alati automatski generišu scenarije ponašanja iz samih zahteva. Ova faza odvaja proces verifikacije od procesa generisanja koda, čime se eliminišu zajedničke slepe mape u kojima isti model piše i proverava sopstveni rad.

Sistem pokreće izdvojeno okruženje za pregled u kojem specijalizovani verifikacioni agenti izvršavaju definisane scenarije. Ovi agenti sakupljaju konkretne dokaze u vidu snimaka ekrana, stanja baze podataka i server logova. Ukoliko se radi o promeni na korisničkom interfejsu, agenti samostalno klikću kroz aplikaciju kako bi potvrdili da sve funkcioniše prema dogovorenim kriterijumima prihvatanja. Svaka ocena sistema direktno je potkrepljena prikupljenim dokazima iz radnog okruženja.

Korišćenje izolovanih okruženja za testiranje pruža objektivnu osnovu za donošenje odluka. Recenzent više ne mora da nagađa da li će promena raditi u produkciji jer ima uvid u vizuelne i sistemske dokaze sa testiranja. Time se otklanja subjektivnost u proceni i obezbeđuje viši standard pouzdanosti softverskih izmena.

Nova uloga ljudskog recenzenta

U ovom modelu uloga ljudskog recenzenta postštaje kvalitativno drugačija i mnogo bliža stvarnom inženjerskom upravljanju. Umesto čitanja stotina linija koda, recenzent proučava nameru, pregledava ključne tačke gde su donete važne odluke i analizira dokaze koje su prikupili verifikacioni agenti. Tok radnog procesa ostaje prepoznatljiv jer se rezultati prikazuju kroz standardne sisteme za upravljanje izvornim kodom, ali se sadržaj revizije radikalno menja.

Recenzent sada odgovara na samo jedno ključno pitanje: da li priloženi dokazi odgovaraju onome što je tim dogovorio da izgradi. Na osnovu toga čovek odobrava promenu, vraća je na doradu zbog neke odluke, traži dodatni testni scenario ili odobrava preskakanje određenog pravila uz valjano obrazloženje. To predstavlja pravu ljudsku procenu za koju je potrebna odgovornost, a koju nijedan automatizovani model ne može u potpunosti da preuzme.

Uvođenje ovakvog sistema zahteva privikavanje tima kroz prelazni period. Tokom prvog meseca rad može delovati kao dvostruki napor dok se registar pravila ne popuni i dok se ljudi ne priviknu na čitanje dokaza umesto koda. Već u drugom mesecu pravila hvataju dovoljno grešaka da se vreme revizije značajno skrati, dok u trećem mesecu proces postane potpuno prirodan i efikasan.

Održavanje i osvežavanje pravila

Tradicionalne revizije koda imaju tendenciju da izgube svako stečeno iskustvo onog trenutka kada se promena spoji sa glavnom granom koda. Komentari i pouke ostaju zarobljeni u arhiviranim zahtevima za povlačenje, pa se iste greške ponavljaju u narednim ciklusima razvoja. Sistem vođen invarijantama trajno čuva znanje koje je tim stekao tokom svake pojedinačne revizije softvera.

Kada neko pravilo iz nekog razloga ne prođe na proveri, autor izmene može podneti obrazloženje za izuzeće, navodeći da se pravilo u ovom slučaju ne primenjuje ili da je zastarelo. Tim koji upravlja tim pravilima ima jasan uvid u statistiku: vide koja se pravila najčešće krše, koja se previše često izuzimaju i gde sistem stvara lažna upozorenja. Pravila koja se stalno zaobilaze bivaju korigovana ili u potpunosti uklonjena, čime registar ostaje relevantan i koristan.

Ovakav pristup pretvara statične smernice u dinamičan mehanizam koji se neprestano razvija uporedo sa projektom. Početak primene ne mora da bude radikalan jer timovi mogu početi samo sa definisanjem osnovnih pravila iz svoje postojeće istorije komentara. Postepena automatizacija oslobađa ljudske resurse za kreativni rad i strateški razvoj proizvoda.

Izvor: The New Stack · Fotografija: Pexels / Freepik (ilustracija)