Forum » Programiranje » Kaj uporabljate oz. priporocate za code review?
Kaj uporabljate oz. priporocate za code review?
mojca ::
V sluzbi uporabljamo Crucible, ampak stvar je obupna. Zdi se, da je to mrtev konj, ki so ga kupili in nehali vzdrzevat, samo enkrat letno naredijo nekaj kozmeticnih popravkov, da lahko zaracunajo novo licencnino.
Problemi:
Izkusnje imam z odprtokodnim projektom na GitHub-u, kjer se CR-ji obnesejo kar ok, vendar gre tam skoraj praviloma za en manjsi commit na pull request, za katerega se "nihce ne sekira", ce traja vec casa, da je sprejet. Pull requeste gledajo nakljucni razvijalci, ko imajo pac cas. Tisti, ki prispevajo kodo, morajo praviloma popravljati zgodovino, da imajo vedno en cist commit z lepim sporocilom itd. ... in za take atomarne spremembe dela perfektno. (Sicer v vseh teh letih se nisem ugotovila, kako bi nasla vse pull requeste, kjer za review cakajo moj zegen.)
Na podjetju smo presaltali na GitLab s precej podobno filozofijo kot GitHub. (Cisto na frisno, tako da smo zaenkrat na free planu, ni pa nujno, da tam tudi ostanemo. Je pa problem, da ce bi npr. hoteli zavreci Jiro, bi potrebovali plan za 100 USD na mesec na clana, pa se mi zdi overkill, da za vsakega obcasnega zunanjega cloveka ali studenta, ki pride za tri tedne na prakso, placas 1200 USD samo zato, da dobi account za tiste tri tedne.)
Na free planu je code review neuporaben, ampak tudi na nekih visjih paketih je kup stvari, ki npr. delajo slabse od Crucibla:
Razumem, da je obicajna paradigma ta, da spremenis najvec dvajset vrstic in odpres merge request. Ampak vcasih ne gre. Vcasih so veliki reworki / refaktoring, kjer vec tisocih vrstic sprememb enostavno ne mores dat v master vejo po kosckih oz. je treba pogledati celostno.
Kaj za code review uporabljate oz. priporocate ostali?
Problemi:
- Ce pogosto rebase-as commite, ti ohrani vseh sto kopij enega in istega commita, nemogoce je ugotoviti, katerega bi dal v code review, se tezje ugotoviti, katerega se nisi dal.
- Sortiranje commitov je po author timestamp-u namesto topolosko (ali vsaj po commit timestamp-u). Ko das v code review vec commitov iz ene veje, ki si jo vlekel dlje casa (pa takrat se ni bila nared za CR), je ful tezko najti stare commite.
- Sto let traja, da se repozitorij posinhronizira. Pushas vejo, naredis merge request, zazene se CI, ... code review pa morda, ce imas sreco, lahko naredis cez 5, 10, 15, ... minut, ker prej koda ni vidna. Morda se da to se kje natjunat, poskusali smo ze, ampak izgleda, da ima stvar performancne probleme, ko ima 100+ repozitorijev.
- Zagonili smo ure za usposobit OAuth, brez uspeha.
- V CR das spremembo A, ki spremeni dve vrstici. Kasneje v isti datoteki v isti veji spremenis 200 vrstic (sprememba B) in das to v locen CR. Sodelavec predlaga popravek A-ja, naredis commit C, ki spremeni par znakov v eni od obeh vrstic. Ampak reviewer zdaj vidi A + B + C.
- Program ne podpira prikaza vec kot treh vrstic okrog spremenjene kode. GitHub / GitLab imata to precej bolje reseno. Samo kliknes za expand.
- Slaba integracija s preostalim workflow-om, ampak predpostavimo, da je to sprejemljivo, ce bi orodje delalo bolje.
Izkusnje imam z odprtokodnim projektom na GitHub-u, kjer se CR-ji obnesejo kar ok, vendar gre tam skoraj praviloma za en manjsi commit na pull request, za katerega se "nihce ne sekira", ce traja vec casa, da je sprejet. Pull requeste gledajo nakljucni razvijalci, ko imajo pac cas. Tisti, ki prispevajo kodo, morajo praviloma popravljati zgodovino, da imajo vedno en cist commit z lepim sporocilom itd. ... in za take atomarne spremembe dela perfektno. (Sicer v vseh teh letih se nisem ugotovila, kako bi nasla vse pull requeste, kjer za review cakajo moj zegen.)
Na podjetju smo presaltali na GitLab s precej podobno filozofijo kot GitHub. (Cisto na frisno, tako da smo zaenkrat na free planu, ni pa nujno, da tam tudi ostanemo. Je pa problem, da ce bi npr. hoteli zavreci Jiro, bi potrebovali plan za 100 USD na mesec na clana, pa se mi zdi overkill, da za vsakega obcasnega zunanjega cloveka ali studenta, ki pride za tri tedne na prakso, placas 1200 USD samo zato, da dobi account za tiste tri tedne.)
Na free planu je code review neuporaben, ampak tudi na nekih visjih paketih je kup stvari, ki npr. delajo slabse od Crucibla:
- Ce je v CR-ju datoteka z veliko spremembami, se zafolda in skrije, da jo spregledas.
- Nikjer nimas nekega orodja, da bi si zacahnal, katere datoteke si ze pregledal in katerih se ne.
- Nikjer nimas opcije, da bi si oznacil, katere commite si ze pregledal in katerih se ne. Oz. tezko je npr. razbiti nek merge request na neke smiselne celote, ki jih je mogoce pregledati eno po eno. V Cruciblu si je avtor naklikal, kar je hotel (tocno tiste commite, ki jih je v enem CR-ju hotel skupaj).
- Nekomu ne mores dat v CR samo dolocenih commitov. All-or-nothing na celoten merge request.
- Za GitLab ne vem, ampak na GitHub-u das status "Rejected", ker nekaj manjka. Ko uporabnik to popravi, bi pricakovala, da je zraven tistega "Rejected" se nek indikator, da je status zastarel in da so na voljo novi commiti. Seveda to velja v obe smeri. En reviewer odobri merge request, nato avtor pusha nekaj spornega, status prvega reviewerja pa je se kar "Accepted".
- Reviewer pregleda in odobri kodo. Razvijalec doda se dva commita. Nimam pojma, kako bi lahko reviewer videl, da mora obdelati le se tista zadnja dva.
- Na free planu je orodje itak neuporabno. Ce das deset komentarjev, dobi razvijalec deset locenih mailov itd.
Razumem, da je obicajna paradigma ta, da spremenis najvec dvajset vrstic in odpres merge request. Ampak vcasih ne gre. Vcasih so veliki reworki / refaktoring, kjer vec tisocih vrstic sprememb enostavno ne mores dat v master vejo po kosckih oz. je treba pogledati celostno.
Kaj za code review uporabljate oz. priporocate ostali?
trulex ::
Pred kratkim smo šli iz GitLab Enterprise na GitHub, in moram rečt da sem bil z GitLabom bolj zadovoljen (verjetno tudi stvar navade). Nimamo sprememb v takšnem obsegu kot si omenila, tako da nimamo enakih težav. Glede na napisano mi deluje da nobeno od omenjenih treh orodij najraje ne bi uporabljali, tako da bi mogoče bilo smiselno preveriti še JetBrainsov Upsource https://www.jetbrains.com/upsource/. Sicer nimam izkušenj ampak glede na to da je ostalo kar pride iz njihove hiše res na nivoju, bi mogoče bilo primerno.
Ne vidim problema pri tem da bi uporabljali hkrati jiro in gitlab (ok, nekaj stane, ampak z razlogom), saj imaš kar nekaj možnosti za integracije.
Na podjetju smo presaltali na GitLab s precej podobno filozofijo kot GitHub. (Cisto na frisno, tako da smo zaenkrat na free planu, ni pa nujno, da tam tudi ostanemo. Je pa problem, da ce bi npr. hoteli zavreci Jiro, bi potrebovali plan za 100 USD na mesec na clana, pa se mi zdi overkill, da za vsakega obcasnega zunanjega cloveka ali studenta, ki pride za tri tedne na prakso, placas 1200 USD samo zato, da dobi account za tiste tri tedne.)
Ne vidim problema pri tem da bi uporabljali hkrati jiro in gitlab (ok, nekaj stane, ampak z razlogom), saj imaš kar nekaj možnosti za integracije.
kr?en ::
https://www.reviewboard.org/
Se mi zdi veliko boljsi in preglednejsi kot merge requesti v Gitlabu. Plus nisi vezan na neke merge requeste, naredis locen review za vsak file posebej, ce ti sede.
Se mi zdi veliko boljsi in preglednejsi kot merge requesti v Gitlabu. Plus nisi vezan na neke merge requeste, naredis locen review za vsak file posebej, ce ti sede.
Zgodovina sprememb…
- spremenil: kr?en ()
mojca ::
Hvala za link na Upsource. Po pregledu 4-minutnega videa sem navdusena, tudi cena je znosna.
Nekako mi "klikne", da je to tocno to, kar bi nucala. Moderen dizajn, precej vgrajene inteligence, pregledni commiti, pregledna koda, fleksibilni komentarji, navigacija po kodi (uaaaaaaau), ... in dejansko vse tisto, kar res potrebujes. Imajo integracijo z Jiro (karkoli ze to pomeni). Z GitLab-om uradno ne, ampak trdijo, da podpirajo sinhronizacijo komentarjev z merge requesti, kar se slisi kot en "uau" feature, ce res dela. Celo v njihovih editorjih naj bi delal CR (kar samo delno pomaga, ker skoraj nihce ne uporablja njihovih editorjev, samo plugin za VS).
Upsource mi deluje kot res kul projekt, kjer so dejansko prisluhnili uporabnikom (oz. so tudi sami heavy-duty uporabniki).
Saj trenutno uporabljamo tako Jiro kot GitLab. Po eni strani bi bilo lepse, ce bi se uporabljal samo GitLab za vse od A do Z (potem tudi lazje upravicis npr. drazjo narocnino), vendar cena paketa, ki omogoca epic-e, 1.200 na userja na leto, ... nekako ne pije vode, sploh zato, ker 99% ostalih featurjev v Ultimate paketu ne nucamo, in te cene tudi ne moremo placevati za studente na kratki praksi.
Za Review Board bi si morala vzeti kar nekaj casa, da bi nastudirala, v cem je stos. Obcutek imam, da je to en sicer zelo zelo spodobno napisen OpenSource project z MIT licenco, ampak predvsem za hekerje, ki jim ni problema memorizirat morja ukazov v terminalu, da sploh ustvaris code review, in ki jim ni problem, ce stvar malo bolj storasto dela (lahko pa z njo z nekaj truda naredis skoraj karkoli). Da bodo enkrat, ko bo prilika, podprli "post-commit" review-je (aka pull/merge requeste), zdaj moras pa sam pazit na to, da das v review, preden commitas. Kul se mi slisi, da lahko review-jas PDF-je in take in drugacne stvari, ni mi pa se potegnil kot celota. Mozno tudi, da imajo samo precej slab marketing in je sam produkt precej boljsi od prvega vtisa.
Nekako mi "klikne", da je to tocno to, kar bi nucala. Moderen dizajn, precej vgrajene inteligence, pregledni commiti, pregledna koda, fleksibilni komentarji, navigacija po kodi (uaaaaaaau), ... in dejansko vse tisto, kar res potrebujes. Imajo integracijo z Jiro (karkoli ze to pomeni). Z GitLab-om uradno ne, ampak trdijo, da podpirajo sinhronizacijo komentarjev z merge requesti, kar se slisi kot en "uau" feature, ce res dela. Celo v njihovih editorjih naj bi delal CR (kar samo delno pomaga, ker skoraj nihce ne uporablja njihovih editorjev, samo plugin za VS).
Upsource mi deluje kot res kul projekt, kjer so dejansko prisluhnili uporabnikom (oz. so tudi sami heavy-duty uporabniki).
Saj trenutno uporabljamo tako Jiro kot GitLab. Po eni strani bi bilo lepse, ce bi se uporabljal samo GitLab za vse od A do Z (potem tudi lazje upravicis npr. drazjo narocnino), vendar cena paketa, ki omogoca epic-e, 1.200 na userja na leto, ... nekako ne pije vode, sploh zato, ker 99% ostalih featurjev v Ultimate paketu ne nucamo, in te cene tudi ne moremo placevati za studente na kratki praksi.
Za Review Board bi si morala vzeti kar nekaj casa, da bi nastudirala, v cem je stos. Obcutek imam, da je to en sicer zelo zelo spodobno napisen OpenSource project z MIT licenco, ampak predvsem za hekerje, ki jim ni problema memorizirat morja ukazov v terminalu, da sploh ustvaris code review, in ki jim ni problem, ce stvar malo bolj storasto dela (lahko pa z njo z nekaj truda naredis skoraj karkoli). Da bodo enkrat, ko bo prilika, podprli "post-commit" review-je (aka pull/merge requeste), zdaj moras pa sam pazit na to, da das v review, preden commitas. Kul se mi slisi, da lahko review-jas PDF-je in take in drugacne stvari, ni mi pa se potegnil kot celota. Mozno tudi, da imajo samo precej slab marketing in je sam produkt precej boljsi od prvega vtisa.
Lonsarg ::
Jaz sem v naši firmi uspešno speljal migracijo na Azure DevOps, zadeva je zgolj 6EUR/mesec na developerja, tisti ki imamo VS Subscriber licenco pa imamo zastonj.
Zdaj Code review težko primerjam z drugimi rešitvami, ker se prej code review niti nismo šli. Pull(merge) reguesti v Azure DevOps se mi zdijo precej pregledni in funkcionalni. Je zaenkrat še odprt en issue ko lahko kaže napačen diff(preveč zajetega) če source branch in destination diviirata kar bodo hopefuly kmalu odpravili. Drugač pa je zadeva res profi z custom branc policy kjer lahko nastaviš marsikaj vključno z tem da se approvali resetirajo če je nov commit.
Mi smo kljub temu da DevOps ima nek svoj task/project managment ostali na tem kar imamo že od prej, na Wrike. Delamo pa na custom integraciji da bi se taski prenašali iz Wrike še v DevOps da bo možno tagat na comitih/PRjih.
Zdaj Code review težko primerjam z drugimi rešitvami, ker se prej code review niti nismo šli. Pull(merge) reguesti v Azure DevOps se mi zdijo precej pregledni in funkcionalni. Je zaenkrat še odprt en issue ko lahko kaže napačen diff(preveč zajetega) če source branch in destination diviirata kar bodo hopefuly kmalu odpravili. Drugač pa je zadeva res profi z custom branc policy kjer lahko nastaviš marsikaj vključno z tem da se approvali resetirajo če je nov commit.
Mi smo kljub temu da DevOps ima nek svoj task/project managment ostali na tem kar imamo že od prej, na Wrike. Delamo pa na custom integraciji da bi se taski prenašali iz Wrike še v DevOps da bo možno tagat na comitih/PRjih.
Zgodovina sprememb…
- spremenil: Lonsarg ()
[SkA] ::
Do sedaj sem uporabljal Upsource in GitLab Community Edition (self hosted). Pri tem opozarjam, da sem Gitlab za reviwe uporabljal občutno manj časa in bil pred tem navajen dela z Upsource. Tako da je za vzeti vse skupaj z neko rezervo.
Na splošno se mi je zdel Gitlabov review vmesnik manj pregleden. Tudi na QHD monitorju mi je manjkala širina pri vzporedni primerjavi razlik. Pri Pregledovanju zgodovine sprememb sem se ves čas zgubljal. Se torej strinjam z nekaterimi splošnimi opazkami, ki si jih napisala.
Kar mi pri Upsource všeč:
- IDEA plugin: da se razumemo, spletni vmesnik je dober, morda s celo bolje obnese pri urejanu daljših komentarjev. Plugin naredi celotno izkušnjo ogleda reviewa sorodno z ogledovanjem sprememb po zgodovini, primerjam lahko s svojim lokalnim branchom itn, navigiram enako kot po kodi itn. Če si ogledujem projekt v IDEA, so vsi nerazrešeni komentarji prisotni tudi neposredno v samem urejevalniku kode, torej mimo "review okna".
- samodejno izklapljanje že ogledanih commitov: ko pregledaš spremembe, in npr. stisneš 'raise concern', se review do naslednje spremembe zate smatra kot končan, vsak nadaljni commit pa review ponovno "odpre". Takrat imaš v seznamu spremenjenih datotek samo še tiste, ki so se spremenile po zadnjem pregledu. Filtracijo commitov seveda lahko kadarkoli urejaš tudi ročno.
- kompaktnejše diff okno (ne dam roke v ogenj, da se v Gitlab vmesniku ne da kaj personalizirati - toliko se nisem poglabljal)
- notifikacije: komentarji, omembe, spremembe stanja commitov v reviewu ipd. dogodki generirajo e-mail ali pa popup v IDEA. Ni bojazni, da bi kaj spregledal ali zamudil.
- boldanje datotek v reveiwu, ki si jih še nisi odprl (nisem sicer prepričan, če deluje tudi v spletnem vmesniku).
Na splošno se mi je zdel Gitlabov review vmesnik manj pregleden. Tudi na QHD monitorju mi je manjkala širina pri vzporedni primerjavi razlik. Pri Pregledovanju zgodovine sprememb sem se ves čas zgubljal. Se torej strinjam z nekaterimi splošnimi opazkami, ki si jih napisala.
Kar mi pri Upsource všeč:
- IDEA plugin: da se razumemo, spletni vmesnik je dober, morda s celo bolje obnese pri urejanu daljših komentarjev. Plugin naredi celotno izkušnjo ogleda reviewa sorodno z ogledovanjem sprememb po zgodovini, primerjam lahko s svojim lokalnim branchom itn, navigiram enako kot po kodi itn. Če si ogledujem projekt v IDEA, so vsi nerazrešeni komentarji prisotni tudi neposredno v samem urejevalniku kode, torej mimo "review okna".
- samodejno izklapljanje že ogledanih commitov: ko pregledaš spremembe, in npr. stisneš 'raise concern', se review do naslednje spremembe zate smatra kot končan, vsak nadaljni commit pa review ponovno "odpre". Takrat imaš v seznamu spremenjenih datotek samo še tiste, ki so se spremenile po zadnjem pregledu. Filtracijo commitov seveda lahko kadarkoli urejaš tudi ročno.
- kompaktnejše diff okno (ne dam roke v ogenj, da se v Gitlab vmesniku ne da kaj personalizirati - toliko se nisem poglabljal)
- notifikacije: komentarji, omembe, spremembe stanja commitov v reviewu ipd. dogodki generirajo e-mail ali pa popup v IDEA. Ni bojazni, da bi kaj spregledal ali zamudil.
- boldanje datotek v reveiwu, ki si jih še nisi odprl (nisem sicer prepričan, če deluje tudi v spletnem vmesniku).
mojca ::
Zanimivo mi je, da se Upsource ne pojavlja skoraj nikjer, ko v iskalnik vpises "best code review tools". Se na Wikipedijini strani ga ni, medtem ko npr. Crucible, ki umira na obroke, zasledis na marsikateri strani kot "best CR tools in 2020".
Je fora v tem, da je "prevec nov"?
Je fora v tem, da je "prevec nov"?
napsy ::
Mi uporabljamo reviewboard in se izkaze za kar dobro resitev.
Prednosti:
- zelo dober pregled nad revizijam (changes slider)
- multiple reviewers
Slabosti:
- tezje za razumet za zacetnike
- nedokumentiran HTTP API, tezko izdelovat integracije/razsiritve
Prednosti:
- zelo dober pregled nad revizijam (changes slider)
- multiple reviewers
Slabosti:
- tezje za razumet za zacetnike
- nedokumentiran HTTP API, tezko izdelovat integracije/razsiritve
"If you die, you die. But when you live you live. There is no time to waste."
strawman ::
Pri nas diff sprintamo na list papirja. Če ustreza je poštempljan, drugače roma v koš. 
Po uporabi več različnih orodij se mi najbolj dopade GitLab, čeprav je preglednost večjih sprememb kdaj precej slaba. Sicer pa so moje izkušnje, da je precej bolj kot orodje pomembna dobra integracija code review-a v proces samega razvoja.
Po uporabi več različnih orodij se mi najbolj dopade GitLab, čeprav je preglednost večjih sprememb kdaj precej slaba. Sicer pa so moje izkušnje, da je precej bolj kot orodje pomembna dobra integracija code review-a v proces samega razvoja.
Spura ::
Atlassianovi tooli so tipicno overengineered garbage (sploh ko zacnes z APIji delat). Klikat dolocene commite v code review je kolosalno bedasta ideja od katere so sami problemi, in to se je vedno pocelo, ko so bile neke mučke ker je bil developer trash.
Upsource je dost decent, ampak se tut na githubu da, in se mi zdi da za vecino zahtevanih features je razlog preprosto ideja da mora biti vse avtomatsko. Ker folk ne zaupa svojim developerjem in noben noce komunicirat kva pocne.
Oziroma, pri tujih firmah je vedno bil Github zadost. Slovenske firme so pa napaljene na Upsource zaradi avtomatike, pa da ni treba s folkom govort.
Tvojih pripomb v kontekstu Githuba :
Stvar natancnosti.
Tadruga zgodba je pa stvar kulture v podjetju. Ce dodajas commite po tem ko je bil acceptan PR, potem moras kliknit re-request review.
Ostale stvari pa drzijo.
Upsource je dost decent, ampak se tut na githubu da, in se mi zdi da za vecino zahtevanih features je razlog preprosto ideja da mora biti vse avtomatsko. Ker folk ne zaupa svojim developerjem in noben noce komunicirat kva pocne.
Oziroma, pri tujih firmah je vedno bil Github zadost. Slovenske firme so pa napaljene na Upsource zaradi avtomatike, pa da ni treba s folkom govort.
Tvojih pripomb v kontekstu Githuba :
Ce je v CR-ju datoteka z veliko spremembami, se zafolda in skrije, da jo spregledas.
Stvar natancnosti.
Nikjer nimas nekega orodja, da bi si zacahnal, katere datoteke si ze pregledal in katerih se ne.V githubu je to mogoce.
Nikjer nimas opcije, da bi si oznacil, katere commite si ze pregledal in katerih se ne. Oz. tezko je npr. razbiti nek merge request na neke smiselne celote, ki jih je mogoce pregledati eno po eno. V Cruciblu si je avtor naklikal, kar je hotel (tocno tiste commite, ki jih je v enem CR-ju hotel skupaj).Se enkrat, mutne vode. Mergal se bo cel branch zato se reviewa cel branch. Pa v github PRjih lahko naklikas katere commite hoces gledat naekrat, ne more pa to developer zate narest.
Za GitLab ne vem, ampak na GitHub-u das status "Rejected", ker nekaj manjka. Ko uporabnik to popravi, bi pricakovala, da je zraven tistega "Rejected" se nek indikator, da je status zastarel in da so na voljo novi commiti. Seveda to velja v obe smeri. En reviewer odobri merge request, nato avtor pusha nekaj spornega, status prvega reviewerja pa je se kar "Accepted".Imas knof da re-requestas review. Ko avtor pusha in je zadovoljen ga klikne.
Tadruga zgodba je pa stvar kulture v podjetju. Ce dodajas commite po tem ko je bil acceptan PR, potem moras kliknit re-request review.
Reviewer pregleda in odobri kodo. Razvijalec doda se dva commita. Nimam pojma, kako bi lahko reviewer videl, da mora obdelati le se tista zadnja dva.developer klikne re-request review
Ostale stvari pa drzijo.
Zgodovina sprememb…
- spremenil: Spura ()
techfreak :) ::
Nikjer nimas opcije, da bi si oznacil, katere commite si ze pregledal in katerih se ne. Oz. tezko je npr. razbiti nek merge request na neke smiselne celote, ki jih je mogoce pregledati eno po eno. V Cruciblu si je avtor naklikal, kar je hotel (tocno tiste commite, ki jih je v enem CR-ju hotel skupaj).Tukaj se mi zdi predvsem v problem v gromozanskih PRjih. Naj se funkcionalnost/sprememba logicno razdeli na vec PRjev, ter vsak loceno merga. Kvalitetno reviewat velik PR je precej nemogoce.
Za GitLab ne vem, ampak na GitHub-u das status "Rejected", ker nekaj manjka. Ko uporabnik to popravi, bi pricakovala, da je zraven tistega "Rejected" se nek indikator, da je status zastarel in da so na voljo novi commiti. Seveda to velja v obe smeri. En reviewer odobri merge request, nato avtor pusha nekaj spornega, status prvega reviewerja pa je se kar "Accepted".AFAIK lahko na GitHubu nastavis, da avtomatsko requesta ponovni approval, ce se na branch kaj novega pushne.
galu ::
Izkusnje imam z odprtokodnim projektom na GitHub-u, kjer se CR-ji obnesejo kar ok, vendar gre tam skoraj praviloma za en manjsi commit na pull request, za katerega se "nihce ne sekira", ce traja vec casa, da je sprejet. Pull requeste gledajo nakljucni razvijalci, ko imajo pac cas. Tisti, ki prispevajo kodo, morajo praviloma popravljati zgodovino, da imajo vedno en cist commit z lepim sporocilom itd. ... in za take atomarne spremembe dela perfektno.
Torej dober tool, ki povrh tega še enforca dobre prakse? :P
Tako to gre.
mojca ::
Tvojih pripomb v kontekstu Githuba :
Ce je v CR-ju datoteka z veliko spremembami, se zafolda in skrije, da jo spregledas.
Stvar natancnosti.
Moja pripomba je letela primarno na GitLab. Pri GitHubu je malenkost bolje, se vedno pa ne idealno. Pri Cruciblu enostavno ne mores spregledati datoteke. Dokler ne kliknes nanjo in jo vsaj preletis, ostaja zacahnana kot nevidena.
Nikjer nimas nekega orodja, da bi si zacahnal, katere datoteke si ze pregledal in katerih se ne.V githubu je to mogoce.
Uh, hvala! Ta zadeva je sorazmerno "frisna", cca. leto dni in me je kar sram, da je se nisem opazila. Res je sicer, da zadnje case precej manj uporabljam CR na GitHubu kot leta nazaj, ampak vseeno.
Vendar migracija na GitHub samo zavoljo "Mark file as viewed" se ni upravicena.
Nikjer nimas opcije, da bi si oznacil, katere commite si ze pregledal in katerih se ne. Oz. tezko je npr. razbiti nek merge request na neke smiselne celote, ki jih je mogoce pregledati eno po eno. V Cruciblu si je avtor naklikal, kar je hotel (tocno tiste commite, ki jih je v enem CR-ju hotel skupaj).Se enkrat, mutne vode. Mergal se bo cel branch zato se reviewa cel branch. Pa v github PRjih lahko naklikas katere commite hoces gledat naekrat, ne more pa to developer zate narest.
Valda se bo merge-al cel branch. Ampak ce imas v tem branchu recimo 70 commitov in spremenjenih par tisoc vrstic kode (pa predpostavimo, da je bilo to ze pregledano), nakar dodas se dva trivialna commita, za katera bi zelel, da jih pregleda nekdo drug (kot tisti, ki je pregledal preostanek brancha), sledi se pet commitov za prvega reviewer-ja ... kako zavraga bos tole sploh zreview-jal v enem pull requestu?
Kaj je tu nujno "mutnega"? Razvijas nov feature, za katerega moras refaktorizirati se precej stare kode, in ne mores merge-at, dokler stvari nisi do konca razstavil in na novo sestavil, do onemoglosti stestiral, ... Vsak commit zase je lep, vmes imas kaksen clang-format, ... Commiti se navezujejo eden na drugega oz. je njihov vrstni red pomemben, tako da ne mores enostavno odpreti vecih neodvisnih pull requestov.
Bos odprl 70+ pull requestov (veja A s spremembo 1 v master, veja B s spremembo 2 v vejo A, veja C s spremembo 3 v vejo B, veja D s spremembo 4 v vejo C, ...)? Reviewer ti pregleda PR iz veje C v B, potrdi, tester klikne merge, ... in potem reviewer pregleduje vejo A s spremembama 1 + 2 (kar je ze pregledal in kar zasmeti spremembo 1), medtem ko veje D ne more vec zmerge-at, ker se je veja C vmes zbrisala (zmerge-ala)?
mojca ::
Tukaj se mi zdi predvsem v problem v gromozanskih PRjih. Naj se funkcionalnost/sprememba logicno razdeli na vec PRjev, ter vsak loceno merga. Kvalitetno reviewat velik PR je precej nemogoce.
1: Natanko tako.
2: Takrat, ko lahko naredis vec neodvisnih enot, ni treba razbijat, saj ze v startu odpres vec vej in merge-as vsako posebej. Ampak pogosto imas gromozanski PR, ki ga ni niti enostavno niti racionalno (niti mogoce?) razstaviti. Sestavljen iz majhnih atomarnih commitov, ne pa takih, ki bi jih lahko kar bilokje vsakega zase merge-al v glavno vejo.
3: Natanko tako.
Lonsarg ::
Moje osebno mnenje je da če je zadeva enkrat tako velika potem natačni code review ni sploh več smiselen (gain vs time spent) ampak pregledaš zadevo kot celoto funkcionalno ter zgolj določene delčke podrobno.
Code review ki traja dlje kot 15 min je meni big no-go in s tem je tudi vse kar rabim en aprove gumb per PR. Vidim pa da je ponekod kultura bistveno bolj birokratsko/pikolovska...
Code review ki traja dlje kot 15 min je meni big no-go in s tem je tudi vse kar rabim en aprove gumb per PR. Vidim pa da je ponekod kultura bistveno bolj birokratsko/pikolovska...
Zgodovina sprememb…
- spremenil: Lonsarg ()
darkolord ::
Vidim pa da je ponekod kultura bistveno bolj birokratsko/pikolovska...Čisto odvisno, kaj delaš.
Pri nekaterih projektih je važno, da se stvari premikajo naprej in se morebitni bugi že popravijo.
Pri drugih projektih so zadeve mission critical in vsak nepokrit edge case lahko zelo veliko stane. Tam je primarno, da stvari neprekinjeno delujejo in se potem ni za hecat ...
mojca ::
Moje osebno mnenje je da če je zadeva enkrat tako velika potem natačni code review ni sploh več smiselen (gain vs time spent) ampak pregledaš zadevo kot celoto funkcionalno ter zgolj določene delčke podrobno.
Code review ki traja dlje kot 15 min je meni big no-go
Tema gre malenkost off-topic (debata je bila o namigih za orodja, ne o filozofiji pregledovanja kode), pa vseeno. Kaže, da se vsaj v eni stvari povsem strinjava: code review, ki traja neskončno dolgo, je neuporaben.
AMPAK.
Kdo pravi, da mora to v EN SAM code review? Kaj, če imamo kar naenkrat 70 code review-jev namesto enega, in je za vsakega od njih sprejemljiv čas pregleda (recimo) 10 minut, še raje pa ciljamo na 2-5 minut. Potem smo pa kar naenkrat na 2-6-ih urah v idealnih razmerah, oz. postane 12 ur povsem sprejemljivih, kajneda? Ne govorim, da se mora teh 12 ur zgoditi v enem dnevu. Morda se veja (projekt) s presledki vleče pol leta, da se koda stabilizira, stestira itd. in je zrela za merge. Včasih imaš pač dober dan in odpreš 10 CR-jev, nato se tri tedne kode ne dotakneš zaradi drugih prioritet (in ti je vseeno, kako dolgo se vmes tvoja koda pregleduje), ...
Vidim pa da je ponekod kultura bistveno bolj birokratsko/pikolovska...
Brez pikolovstva seveda ne moreš pisati dobrega programja. ("Koga sploh gane, če se program nepovratno sesuje, ko uporabnik vpiše negativno številko tja, kjer si je programer zamislil pozitivno, npr. za računanje logaritmov? Koga zanimajo robni pogoji, off-by-one napake, prepisovanje spomina, ...")
Ne gre pa za zbirokratiziranost, če si iskreno želiš, da bi tvoje delo videl še drugi par oči, te navdahnil z boljšo idejo, ti prihranil ure in ure razhroščevanja pol leta pozneje, ... samo da GitLab-ov model pač nikoli ni razmišljal o tvojih potrebah oz. jih dovolj visoko prioretiziral (sam pa nimaš časa, da bi se dovolj poglobil v njihov codebase oz. bi pri tem izgubil fokus).
Švicarski nožek je krasno orodje. Ampak za kakšno stvar moraš pač poseči po bolj specializiranem orodju.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Izsiljevalski napad na nezaščitene repozitorije GitOddelek: Novice / Varnost | 4009 (3212) | jype |
| » | Evropska komisija dovolila Microsoftov prevzem GithubaOddelek: Novice / Nakupi / združitve / propadi | 9340 (6906) | Ales |
| » | GitHub PomočOddelek: Pomoč in nasveti | 5320 (3582) | BivšiUser2 |
| » | Programerski softwareOddelek: Programiranje | 3538 (2663) | Qushaak |
| » | Source version control za domačo uporabo?Oddelek: Programiranje | 6521 (5592) | MrBrdo |