Obrazac M97/CC, šalter 4
Hteo si da rešiš svoj PR i pridružiš ga ostatku projekta? Imaš li potvrdu BOB22-R? Imaš? Osiguranje od NullPointerException-a? I to imaš? A obrazac M97/CC? Ne? Šalter 4, moliću. Da, onaj na kome je najveća gužva. Ne, nema veze što je u pitanju samo ispravka slovne greške; pa nismo valjda divljaci, mora da se poštuje red! Drugi čekaju, pa sačekajte i vi!
Pull Request je smišljen za kontribuciju na open-source projektima. U pitanju je asinhroni proces u kome vreme obrade PR-a nije u prvom planu. Pročitajte prethodnu rečenicu još jednom i iskreno poželite takav proces u dinamičnom softverskom projektu. Stvari idu dotle da se zahteva da svaki i baš svaki komit prođe kroz PR avanturu kliktanja po Githubu od strane jednog, dva, pa zašto i ne tri (ko da više!?) člana tima. Poseban pakao čeka one kojima se dve procedure uklješte: obavezan PR i nekakva CI procedura, na primer, objava nove verzije u tri laga(d)na koraka. Slek tada opravda svoju cenu: poruke “Može neko da mi apruvuje PR? Častim piće.” zapljusnu kanale.
Skupa budalaština, zar ne?
Recenzija posla je dobra stvar; naročito u softverskom razvoju, gde čovek neprestano proizvodi funkcionalan kod i bagove. Ako nešto znamo to je da smo skloni greškama: iskusniji ih samo prave ređe. Zato vredi pregledati urađeno pre nego što se nađe u zajedničkom prostoru.
Da otkrijem tajnu: ne zahteva svaka promena pažnju ili reviziju. Postoje izmene koje koštaju manje nego vreme provedeno u procedurama. Postoje izmene koje se tiču drugih procedura (ciklus objave nove verzije, na primer.) Postoje izmene koje se ne tiču koda (dokumentacija, razvojno okruženje itd.)
Ne znam da li je ikada mereno (verovatno nije, pošto se bavimo razvojem softvera): verujem da je cena slepog pridržavanja procedura veća od cena grešaka na ne-produkcijskom delu projekta.
Zašto sam programer ne bi odlučivao o tome da li njegova izmena treba recenziju? Radikalno poverenje. Ili, da se pomaknemo korak unazad: zašto revizija ne bi počela na početku rada? Zašto ne bi bila kontinualna? Zašto ne uvedemo alate koji sprečavaju neželjeno (“mali Perica prvi dan na poslu pustio kod u produkciju”), a ne ometaju željeni tok posla? Većina procesa se može pragmatično automatizovati.
Procedure moraju da služe timu. Ako ne služe, nešto se mora menjati - odmah. Setimo se onoga šta Taiichi Ohno nije rekao:
Procedura koja ometa kontinualno izvršavanje posla zahteva hitnu reviziju. 諦めないで!
Idemo dalje.