Kvalitetan kod ne zavisi samo od programera koji ga piše – već i od kolege koji vrši reviziju

O ovoj temi smo razgovarali sa Adrienne Braganza Tacke koja radi kao Senior Developer Advocate u kompaniji Cisco i koja je bila predavač na Shift konferenciji u Zadru. Naša sagovornica je između ostalog i autor knjige “Looks Good To Me: Constructive code reviews” koja je u potpunosti posvećena elementima i praksama kada govorimo o pomenutoj reviziji koda.

Kada govorimo o terminu code review-a (testiranja ili revizije koda), njegova upotreba kao terminologije ali i procesa pojavila se još odavno kada se pod ovim terminom podrazumevalo to da treba uraditi inspekciju određenog koda koji bi kasnije bio deo kompleksnog softvera. Na primer, još u IBM-u su počeli da na vrlo specifičan i sofisticiran način prolaze kroz gotov kod, pokušavajući da pronađu bagove i greške koje bi uticale na funkcionisanje istog.

Štaviše, ovde je reč o veoma stresnom procesu koji zahteva mnogo uloženog vremena, resursa, sastanaka, a mnoge kolege su u stanju da kritikuju napisani kod. Danas, pak, imamo mnoge alate koje koristimo za ove procese, dok se i sam kod (ali i njegovo pisanje) vremenom znatno promenilo. Danas takođe imamo i timove ljudi koji se bave procesom provere kvaliteta koda koji kasnije ide u dalju produkciju i koji mora da odgovara svim potrebama proizvoda. Taj deo procesa revizije se danas zove kao code review.

Iako se na prvi mah čini da je ovde reč o jednostavnom procesu, pojedinac ili tim koji je zadužen da proveri kod suočava se sa nizom izazova, pa slobodno možemo reći da je ovo veoma kompleksan posao. Osoba koja piše određeni kod mora da sarađuje sa kolegom koji taj kod čita i proverava i koji, pritom, mora da razume ono što je napisano u kodu.

Da li izazovi za sve one koji se bave code review procesom zavise od same kompleksnosti koda?

Adrienne: Rekla bih da to jeste slučaj. Jer kompleksnost koda zavisi i od projekta za koji je on namenjen i na kojem određena kompanija radi. Upravo zato, može da dođe do situacije da neko ko se bavi revizijom koda ne bude upoznat da određenim delom projekta, što svakako može dovesti do izazova.

Sa druge strane, postoje i kompeksni kodovi koje je veoma teško pratiti, pa i sa te strane se mogu javiti određeni izazovi. Takođe, moramo imati na umu da ovaj posao rade visokoplaćeni profesionalci koji ako ne razumeju šta se dešava u određenom kodu, onda definitivno nešto nije u redu i treba odmah reagovati, uneti izmene i nove inpute.

Svi koji se bave code review procesom moraju i da razumeju konteks iza tog koda, kao i da razumeju zašto se određene promene unose, da li postoji određena dokumentacija, tačnije sve ono što će na kraju i olakšati sam proces uklanjanja grešaka. Cilj je na kraju da svako ko dobije uvid u određeni kod, da razume isti taj kod i onda pronađe i otkloni postojeće greške.

Koji su najefikasnije i najbolje metode za kvalitetno obavljen code review proces?

Adrienne: Najpopularnije forme su zapravo one koje su bazirane na alatima koji se koriste u ovom procesu. Mnogi ljudi koji se bave developmentom su čuli za GitHub, Bitbucket koji predstavljaju na neki način asistente za developere koji imaju razne delove koda online. Mnogi revjueri mogu da ih pogledaju i da ostave komentare na te iste kodove.

Mnogi ljudi takođe zaborave i na proces pair programming-a, tačnije da ljudi zajedno rade na jednom kodu i samim tim se dopunjuju ili ispravljaju svoje greške i kontinuirano rade reviziju koda, što se takođe može okarakterisati kao deo, odnosno forme code review procesa.

Svaki put kada neko drugi pogleda kod i pruži dodatnu proveru, tačnije da je to neke treća strana, a ne vaše oči, onda to takođe smatram dobrom metodom code review-a. Ne morate nužno da se oslanjate na alate i izvore kao što je Githhub, ali je obavezno da neko drugi pogleda vaš kod, da ga pročita i pruži feedback.

Šta timovi treba da unaprede kada je reč o procesu revizije koda i šta oni zapravo rade pogrešno? 

Adrienne: Ono što timovi prvo i osnovno treba da urade jeste da naprave, ono što ja kažem, jednu vrstu team agreement-a. Ovo predstavlja na neki način timski dogovor gde vi zajedno treba da se dogovorite o načinu na koji način izvršiti code review, tačnije da li ćete da koristite alate ili ćete da se fokusirate na pair programming. Poenta je napraviti plan i kompromis, staviti se na papir i onda započeti određeni proces. Ovo nije dobra praksa samo za code review proces, već i za bilo koji drugi proces unutar jedne IT kompanije koja radi na kompleksnim tech projektima.

Šta tačno podrazumeva 4DORA Metrics?

Adrienne: DORA metrike koriste DevOps timovi da bi izmerili svoj učinak i otkrili da li su oni sa “slabim performansama” u odnosu na “elitne izvođače”. Četiri korišćene metrike su učestalost implementacije (DF), vreme za promene (LT), srednje vreme do oporavka (MTTR) i stopa neuspeha promene (CFR).

• Deployment Frequency: Odnosi se na učestalost uspešnih izdavanja softvera u proizvodnju.
• Lead Time for Changes: Snima vreme između urezivanja promene koda i njegovog stanja u kome se može primeniti.
• Mean Time to Recovery: Meri vreme između prekida usled primene ili kvara sistema i potpunog oporavka.
• Change Failure Rate: Označava koliko često promene ili hitne ispravke tima dovode do grešaka nakon što je kod postavljen.

Iza akronima, DORA je skraćenica za DevOps tim za istraživanje i procenu. U okviru sedmogodišnjeg programa, ova Google istraživačka grupa je analizirala DevOps prakse i mogućnosti i uspela je da identifikuje četiri ključne metrike za merenje razvoja softvera i performansi isporuke.

Postoje li neki drugi alati kada je reč o reviziji koda?

Adrienne: Naravno, ima ih dosta. Mnogi u šali kažu da bi AI mogao da zameni proces code review-a. Pored toga, postoje programi, tačnije alati koji mogu da procene koliko je vremena potrebno da se napravi jedna revizija koda. Ovi alati su tu ne da zamene one koji se bave ovim procesom, već da im pruže dodatnu pomoć.

Sa druge strane, smatram da su AI rešenja tu da nam pomognu, a ne da nas zamene. Način na koji ja vidim upotrebu AI tehnologije jeste to da nam ona bude kao asistent, na primer da nas podseti za neke stvari za koje se mi ne bismo setili u određenom procesu. AI ne može da zameni ljudsku procenu i razumevanje koda.

Kao Senior Developer Advocate, koji je tvoj savet za najbolji način na koji se može obaviti code review proces?

Adrienne: Zapravo, pišem jednu knjigu na tu temu koja se zove “Looks good to me – Constructive code reviews” i koja bi uskoro trebalo da bude dostupna. Mislim da se sve svodi na sam kontekst i komunikaciju. Najbitnije je da što bolje pružimo kontekst svima u timu, da razgovaramo sa ljudima na koji način uraditi jedan proces i razumeti kod što bolje. Sve se zasniva na tome koliko dobro možemo da razumemo kod i njegovu primenu kasnije i kako ga možemo napraviti još boljim kroz komunikaciju.