Svi (ili bar većina 😀) programera želi da piše čitak i jasan kod koji se lako održava i svi želimo da naš dobro napisan (i istestiran) kod brzo stigne na main granu.
Problem nastaje u tome što, koliko god da vi to želite da bude brzo, vrlo često zavisite od vaših kolega (što samih programera, što od strane QA) koji moraju da pregledaju i testiraju kod koji ste vi napisali.
PR-ovi su preveliki
U ovih nekoliko meseci, primetio sam veličinu samog PR-a kao veliki problem, jer vreme potrebno za odobravanje PR-a dosta zavisi i od njegove veličine.
Od skoro smo u timu počeli da praktikujemo tokom sprint planning-a raščlanjivanje većih feature-a (koji i ovako pripadaju jednom epicu), na još sitnije celine, koje bi mogle da stanu u više manjih PR-ova.
Nemanje vremena za pregledanje
Bez obzira na veličinu PR-a, postoji velika šansa da će vas neko zamoliti da pregledate PR koji niste lično kreirali. U takvim situacijama može se pojaviti izazov, posebno ako ste u tom trenutku potpuno posvećeni svom radu, kucajući neke od najboljih linija koda u svojoj karijeri, ili ste zauzeti sastankom. U tim okolnostima, može biti teško odmah se posvetiti recenziranju zadatog PR-a.
Jedno od rešenja koja je moj tim nedavno počeo da primenjuje, a koje se u protekle dve nedelje pokazalo kao efikasno, uključuje rezervisanje oko deset minuta u poslovnom kalendaru svakog člana tima, u najpogodnijem delu dana (idealno na početku i kraju radnog vremena), za pregled PR-ova koje su kreirale druge kolege. Dakle, svaki član tima posvećuje ukupno oko dvadeset minuta dnevno za ovu aktivnost.
Razume se, potrebno je naglasiti da je ovo prilično specifičan scenario za moj tim, s obzirom da nas ima samo pet. Ipak, bio bih veoma zainteresovan da u komentarima pročitam mišljenja i iskustva kolega iz većih timova.
0 komentara