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

Komentarze (18)

Ragnarokk

@LondoMollari Wolałbyś na 2500 plików? Albo jeden wielki commit?

LondoMollari

@Ragnarokk Tak... Wtedy bym nawet nie próbował przeglądać. ( ͡°( ͡° ͜ʖ( ͡° ͜ʖ ͡°)ʖ ͡°) ͡°)

Ragnarokk

@LondoMollari This guy ITis.

koszotorobur

@LondoMollari - powodzenia w review

owczareknietrzymryjski

@LondoMollari niech to zesquashuje a nie taki burdel w historii robi

koszotorobur

@owczareknietrzymryjski - to już zależy od przyjętej konwencji w zespole

ataxbras

@koszotorobur Na przykład konwencja burdelowa na to pozwala

koszotorobur

@ataxbras - ba, ona to wymusza

Deykun

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

Catharsis

No to zrób review za pomocą AI, co to za problem. Wtedy AI odbierze tobie prace xD.

Swbd

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.

d01edd77-4993-4a23-81e6-4b6246f77d13
lurker_z_internetu

@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.

Swbd

@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ąć.

lurker_z_internetu

@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ś.

Czokowoko

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

@lurker_z_internetu kurde, skąd wiedziałeś? XD

lurker_z_internetu

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