Tip of the day: code review

Sve ozbiljne softverske firme imaju praksu code reviewa, što znači da svaki napisani kod mora proći pregled nekog drugog člana tima prije nego što uđe u pogon, tj. postane dio proizvoda. To nije testiranje, koje se obavlja prethodno, tijekom programiranja. To je doslovno čitanje koda. Čak i najboljim zaposlenicima netko drugi mora pročitati kod, iako je prethodno već testiran. Svrha je stvaranje boljeg koda, ne toliko u smislu otkrivanja bugova (iako se nađe onih koje testovi nisu uhvatili), nego uočavanje stvari koje se mogu napraviti drugačije, elegantnije, pravilnije, sigurnije, robusnije, organiziranije, čitljivije za kasnije održavanje/nadogradnju itd.

Ova praksa u natjecateljskom programiranju nije uobičajena. Ako smo riješili zadatak i prolaze svi primjeri, zašto bismo se vraćali na kod koji je ispravan? Ipak, ako je kod ispravan, ne znači nužno da je dobro napisan i da će način na koji smo ga pisali biti dobar i u budućim, težim zadatcima. Zato je korisno baciti oko i na tuđe kodove da bismo iz njih nešto naučili. No jednako je korisno da netko drugi baci oko na naš kod. Tako neki mentori, voditelji grupa ili radionica (u MIOC-u, HSIN-u, ZRS-u…) odvajaju dio svog vremena da barem površno pogledaju kodove svojih učenika i ukažu im na stvari koje se mogu bolje. Čak i za vrlo dobre natjecatelje vrijedi: kad im netko bolji/iskusniji pogleda kod, uočava stvari koje se mogu poboljšati.

Početnički primjeri uključuju:

  • slabu čitljivost koda, npr. škrtarenje s razmacima i redcima (kako ćete debugirati kod koji je napisan gusto i zbrda zdola?),
  • nekonzistentna ili manjkava stilska obilježja (vidi npr. ovaj post),
  • nedeskriptivna imena varijabli – teško ćete se snaći u većem kodu ako vam se varijable zovu a,b,c,d,e,f,g,h,
  • glomazne porcije koda (umjesto organiziranja u funkcije) i kao posljedica kod koji je teško testirati dio po dio i debugirati,
  • duplikacija, tj. isti/sličan dio koda prisutan na više mjesta (lakše se griješi i teže se mijenja) umjesto izdvajanja u funkciju,
  • suvišne varijable i nepotrebno kompliciranje koda (odražava neurednost misli),
  • neefikasne petlje – npr. korištenje dvostruke gdje je dovoljna jedna,
  • neefikasno spremanje podataka u polja/parove/strukture,
  • deklaracije na lošem mjestu (uz neke iznimke, doseg varijabli treba biti najmanji mogući),
  • loše organizirani slučajevi (“puno ifova”) i formule u kojima je lako pogriješiti – te stvari spominjao sam i ovdje,
  • neelegantno baratanje donjim i gornjim granicama intervala (“jel tu sad ide > ili >=? plus jedan ili minus jedan?”),
  • računanje istih podataka više puta, npr. unutar neke petlje, umjesto da se unaprijed izračunaju,

i mnogi drugi. Nakon što se savladaju osnove, poboljšanja koda uglavnom su vezana uz konkretan algoritam i njegove implementacijske varijante. Istina je da vještina kodiranja kod početnika raste jako brzo, a s vremenom sve sporije (logaritamska krivulja), ali čitajući kodove boljih od sebe uvijek se mogu naučiti novi trikovi.

Jedna misao o “Tip of the day: code review

  1. Povratni ping: Tip of the day: granice intervala | Blogaritam

Komentiraj

Popunite niže tražene podatke ili kliknite na neku od ikona za prijavu:

WordPress.com Logo

Ovaj komentar pišete koristeći vaš WordPress.com račun. Odjava /  Izmijeni )

Google photo

Ovaj komentar pišete koristeći vaš Google račun. Odjava /  Izmijeni )

Twitter picture

Ovaj komentar pišete koristeći vaš Twitter račun. Odjava /  Izmijeni )

Facebook slika

Ovaj komentar pišete koristeći vaš Facebook račun. Odjava /  Izmijeni )

Spajanje na %s