Tak jak w tytule. Myślałem, że commity po ang to standard. A może się myliłem?
Np. commit msg: "zrobione" - wtf?
0
7
Zdaje sobie sprawę że będzie to dziwnie wyglądać jak ja to napiszę, ale zagram se diabła i zapytam - po co angielski?
Czy masz w teamie ludzi którzy nie znają Polskiego lub w najbliższej przyszłości sądzisz, że tacy dołączą?
Jeżeli twój team średnio czuje się z angielskim, to co będzie łatwiejsze w utrzymaniu i rozeznaniu w commitach - łamany angielskawy czy polski?
W jakiej dziedzinie operuje wasz software? jeżeli jest w niej dużo bardzo specyficznej nomenklatury - trudnej lub słabo tłumaczalnej, to chyba utrudnicie sobie (i przyszłym devom) życie
LGTM czy jest ok, dawaj dawaj deploy w commicie jest równie bezwartościowe niezależnie od języka :D
4
Czyli Twój zespół w ogóle nie potrafi korzystać z gita. Bo rozumiem że w takim razie nikt nie przegląda historii. O revert'ach już nie mówię :)
Jeśli macie jakieś narzędzie typu jira, to wówczas przydałby się nr taska przy którym dana zmiana była wykonywana. Wtedy jesli jest to duży projekt, można się zorientować po co ktoś to robił tak a nie inaczej :)
1
A rozmawiałeś w ogóle z kimś z zespołu na ten temat ?
Czy szukasz jakiegoś magicznego rozwiązania i niech inni się dopasują
0
Jeśli piszecie commit po polsku to stawiam że to jest polska firma. I troche śmierdzi to Janusz $oftem .
Dlatego są dwa rozwiązania tej sytuacji:
- Powiedzieć im że jednak jest to bardziej profesjonalniej, a dwa robisz sobie dobre nawyki i później w firmie w której będzie to standard, nie będziesz się zastanawiał jak pisać wiadomości w commitach
- Jeśli jesteś tam juniorem/midem to zmienić firmę bo pewnie nauczysz się więcej złego niż dobrego.
- Jeśli jesteś tam seniorem w górę to nie powinieneś mieć problemu z przeforsowaniem tego. Jeśli jedna się nie uda to zmienić firmę ;)
2
Jedyny argument jaki widzę, to że jeśli commity będą po angielsku to obcokrajowiec będzie mógł kod czytać. Jak to nie jest argumentem, to wszystko inne jest nieistotne, bo po co pisać po angielsku w Polsce? Żeby ćwiczyć angielski? Są lepsze metody.
5
jeśli taski w jirze jest po polsku to wg mnie opis commita po angielsku tylko po to, żeby był to idiotyzm. Jeśli natomiast taski są po angielsku to to commit po angielsku to jest oczywistość
1
@Xorxorxor: Ponieważ język, biblioteki i dokumentacja jest po angielsku, teraz wprowadzając nazwy zmiennych i metod po polsku część będzie po polsku a część po angielsku jak getUzytkownik bo get jest wymagany przez framework co wygląda dziwnie a w tej metodzie wywołanie .fetchUser z jakiejś biblioteki. Przyjdzie inna osoba i napisze kolejną zduplikowaną metodę getUser bo szukając po wszystkich metodach nie znajdzie jak wpisze getUser w wyszukiwanie. Albo weźmie i zmieni na getUser i będzie syf w historii klasy. To samo tyczy się komentarzy, które mogą zawierać odniesienia do nazw użytych w kodzie i jeden będzie pisał user a drugi użytkownik bo nie będzie wspólnego języka albo jeden odniesie się do nazwy metody a drugi do nazwy biznesowej a trzeci do nazwy metody w zewnętrznej bibliotece. I teraz wyobraź sobie że mnie tam zatrudniacie i jak ja to zobaczę to za trzy dni mnie już u Was nie ma.
1
Przede wszystkim w commit msg musi być wiadomo czego dotyczą zmiany, a do tego najlepiej nadaje się nr taska. Jeśli do tego zadania są dobrze opisywane to mamy o wiele więcej informacji i właściwie od razu w pewnym sensie dokumentację.
To czy napiszesz "zrobione. " czy "done." nie ma znaczenia, bo i tak nie opisuje wprowadzonych w commicie zmian.
1
Kiedyś próbowałem przeforsować w pewnym projekcie pisanie code review po angielsku, bo wszystko inne było jak Pan Jezusek przykazał, po angielsku - identyfikatory w kodzie, komentarze, wiadomości w commitach, opisy tasków itd. W związku z tym, dlaczego nie iść na całość i nie komunikować się również i tam po angielsku? Angielski wszyscy znają bezproblemowo, a zarchiwizowane komentarze do kodu też są jakąś informacją, którą może kiedyś będzie przeglądał jakiś przyszły zatrudniony obcokrajowiec.
No i nie udało się. Świecenie przykładem nic nie dało, podobnie podnoszenie tematu na spotkaniach i próba przekonywania również, generalnie spłynęło, że to w sumie pierdoła, więc co się przejmować, są ważniejsze rzeczy warte uwagi. W końcu też przestałem, bo cenię sobie spójność i odpowiadanie po angielsku na komentarze po polsku, czego nikt nie naśladował mnie drażniło. Potem projekt padł.
Ogółem wniosek z tego doświadczenia, jak i innych obserwacji w innych teamach jest, że niesławne "dobre praktyki" każdy szanuje, ale próba ich wprowadzenia to walka z wiatrakami o ile nie ma się jakiejś pozycji architekta/leada by takie rzeczy wymuszać na poziomie całego zespołu.
Obecnie w firmie mamy inny rodzaj tego samego problemu. Mamy dla sprawniejszego zarządzania kilka teamów, które pracują nad wspólnym kodem, każda ze swoim mini-managerem. Ten nasz usiłuje poprawić jakość code review, a pozostali generalnie tego nie podchwytują. Mamy na ten przykład zasadę, że każdy kod może zostać zmergowany do całości wtedy i tylko wtedy, gdy dostał przynajmniej jedną zieloną fajkę of jakiegoś czytelnika. Reszta teamów traktuje to luźniej, uznając, że jeżeli wszystko, co kod robi to poprawia mały bug w dwóch linijkach, to szkoda czasu na pełen proces, a code review winien raczej być zarezerwowany na większe zmiany (gdzie zatem przebiega granica...? no mnie nie pytajcie). No i nie dadzą się przekonać. Były i apele i dyskusje na Slacku (które szybko zdychały) i prezentacje na wspólnych seminariach o dobrych praktykach (które wszyscy mają gdzieś). Raz za czas zaglądam na historię zmergowanych PR-ów od niektórych devów i obserwuję całkiem sporo takich, które przeszły bez jakiejkolwiek weryfikacji i czasem mnie korci by zrobić z tego tytułu nieco rabanu, ale ostatecznie przeważnie macham ręką, bo węsze bezcelowość takich działań. Ludziom zbyt wygodnie. Z drugiej strony, nie przywiązujemy się do naszego kodu bo sporo regularnie i tak trzeba wyrzucać i przerabiać ze względu na szybko zmieniające się warunki i wymagania, a klient zdaje się akceptować obecność błędów w zamian za szybsze dostarczanie, więc nadmierny reżim procesów jakościowych i dążenie do perfekcji też może nie być najbardziej odpowiedni (ten argument indagowani managerzy innych zespołów często wysuwali). No ale przynajmniej w ramach naszego zespołu jest spokój i porządek, jak Bóg przykazał...
1
Jeżeli obecna praca Ci się podoba to się po prostu dostosuj do reszty zamiast zmuszać resztę żeby dostosowała się do Ciebie. Pomyśl o osobach które może gorzej niż ty znają angielski (a uwierz mi zrozumiały polski komentarz jest o niebo lepszy niż niezrozumiały angielski) oraz o tym jaką korzyść przyniesie to twojej firmie? Jeżeli korzyść będzie żadna, to ma to znamiona świętej wojny (moje taby lepsze niż twoje spacje) i lepiej odpuścić. Jeżeli kochasz pisać po angielsku to zmień pracę, ja mam kod po angielsku, maile po angielsku, spotkania po angielsku, kolegów w zespole którzy mówią tylko po angielsku a ostatnio nawet kolędy po angielsku. Na dodatek pies sąsiadów wabi się Lili a ich dzieci (podstawówka) śpiewają angielskie piosenki, więc ja już angielskim wymiotuję...
Jeżeli koniecznie chcesz już coś zmieniać, to po pierwsze dowiedz się dlaczego np. kod jest po angielsku a komentarze w komitach jednak nie. Może zespół boi się że projekt pójdzie do Indii? Słaby angielski? A może jest tylko jedna czy dwie problematyczne osoby, a reszta powiedzmy 6 osób piszę po ang? Wtedy można by to podnieść na jakimś retro i przedyskutować.
Generalnie jeżeli nie jesteś tam team-leadem, ani seniorem to bardzo prawdopodobne że zostaniesz zlany. Sprawę możesz podnieść, po prostu przygotuj się na to że nic z tego może nie wyjść i wtedy będziesz musiał odpuścić.
3
Kiedyś pracowałem w bardzo fajnym zespole. Z gita i commit mssg korzystaliśmy dość mocno, nie było tam "added" "done" tylko ladne opisy... Po polsku. Jak postanowiliśmy przejść na angielski to ładne opisy się skończyły. To jednak jest co innego we własnym języku się wyrazić a co innego po angielsku. Wróciliśmy do polskich commitów.
Jeśli masz problem typu ludzie nie piszą opisu tylko "Zrobione" to przejście na angielski nic nie da. Jeśli już piszą fajne mssg - to zostaw to w spokoju.