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
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
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 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ć