Ehhh, pull request na 25 plików i 42 commity... co ci juniorzy to ja nie wiem. A potem płacz, że AI zabiera pracę. ( ͡° ͜ʖ ͡°)
#heheszki #programowanie #gownowpis #zalesie
Ehhh, pull request na 25 plików i 42 commity... co ci juniorzy to ja nie wiem. A potem płacz, że AI zabiera pracę. ( ͡° ͜ʖ ͡°)
#heheszki #programowanie #gownowpis #zalesie
@LondoMollari Wolałbyś na 2500 plików?
@Ragnarokk Tak... Wtedy bym nawet nie próbował przeglądać. ( ͡°( ͡° ͜ʖ( ͡° ͜ʖ ͡°)ʖ ͡°) ͡°)
@LondoMollari This guy ITis.
@LondoMollari - powodzenia w review
@LondoMollari niech to zesquashuje a nie taki burdel w historii robi
@owczareknietrzymryjski - to już zależy od przyjętej konwencji w zespole
@koszotorobur Na przykład konwencja burdelowa na to pozwala
@ataxbras - ba, ona to wymusza
Nie wiem jaki znaczenie ma liczba komitów, 25 plików to bez problemu 4 nowe komponenty w jakimś ficzerze w angularze jak są templatki i style obok. dx
No to zrób review za pomocą AI, co to za problem. Wtedy AI odbierze tobie prace xD.
Klasyczne: it depends.
Jeżeli każdy jeden commit sensownie ma opisane co on robi i dlaczego on to robi to takie review to przyjemność.
Ale sądząc po frustracji to historia zmian to:
Stuff
More stuff
Oh...now it works
Adding file
Ooops, removing file
To slabo. Bardzo slabo.
Jeżeli historia zmian to smietnik, squashuj w cholere. I tak nic nie wyciągniesz.
@Swbd squashuj, a potem przejrzyj co się da wyciągnąć w autonomiczne commity i podziel zgodnie z zakresem, a nie progresem. Wrzucanie wszystkiego w jeden commit to też antypattern, bo utrudnia troubleshooting. Kto chociaż raz musiał użyć git blame, git bisect czy git revert ten wie.
@lurker_z_internetu ależ oczywiście. Ale IMO to reviewer powinien prosić o taki podział a nie robić to sam.
Reviewer nie powinien osobiście ingerować w historie. A sugerować, typu Ej tu wprowadzasz zmianę a dwa commity dalej ja fixujesz bo była źle na początku. Interaktywny rebase jest mega potężny żeby to osiągnąć.
@Swbd nie no pewnie, to co opisałem to robota dla autora. Reviewer powinien wymagać takich zmian zanim zaakceptuje. Junior się nastęka, ale się nauczy czegoś.
Jak miałem pod sobą juniora kiedyś i sprawdzałem po kilku dniach jego progres to miałem opisy commitow typu: " Ale jestem zmeczony", "zjadlbym kebsa", "ide po colę i potem dokończę" xd
@Czokowoko fan SVN
@lurker_z_internetu kurde, skąd wiedziałeś? XD
@Czokowoko bo studenci tak się uczą wersjonować swoje prace:
* gotowe.jpg
* gotowe_poprawki.jpg
* gotowe_poprawki_final.jpg
* gotowe_poprawki_final_FINAL.jpg
Potem niektórzy odkrywają, że SVN rozwiązuje dla nich problem głupich nazw plików przerzucając go na problem głupich nazw commitów. Commitów i tak nikt nie czyta, bo zazwyczaj pracują nad projektami sami.
Przejście na git wiąże się z wdrapanien na pewien learning curve. Jest dramatycznie lepszy, ale zasadniczo różny. To samo tyczy się nauczycieli i opiekunów legacy code niestety.
Zaloguj się aby komentować