Co warto sprawdzić przed commitem?

Polecane linki

• Inspekcje kodu w IntelliJ
• SonarLint – wtyczka do statycznej analizy kodu dla różnych IDE

Transkrypcja

Dzisiejszy temat to co warto sprawdzić przed commitem. Z tego odcinka dowiesz się jak stworzyć własną checklistę lub udoskonalić tą którą już masz. Od czego zacząć? Zobacz jak wygląda moja podstawowa checklista 🙂 

Kompilacja i testy

Pierwszą najważniejszą sprawą jest to czy kod się kompiluje? Niby prozaiczna sprawa ale niech pierwszy rzuci kamieniem, kto nigdy nie wrzucił do repozytorium kodu który się nie kompiluje. Skompilowany kod to jeszcze nie wszystko – potrzebne są jeszcze testy, które sprawdzą czy ten kod działa dobrze i czy jest poprawnie napisany.

Jeśli chodzi o testy to sprawdzam nie tylko to czy pokryłam wszystkie przypadki testowe które chciałam, czy pokrycie procentowe kodu jest odpowiednie, ale także to jakiego rodzaju są to testy. Czy są to testy jednostkowe, czy integracyjne? Jakich testów potrzebuje aktualnie w projekcie? Na jaki rodzaj testów umówiłam się z zespołem? Jaki rodzaj testów będzie korzystniejszy w tym przypadku?

Statyczna analiza kodu

Kolejnym punktem na mojej checkliście jest sprawdzenie uwag od narzędzia do statycznej analizy kodu. Jest to bardzo istotny krok, dlatego, że pozwala uniknąć wielu drobnych pomyłek, które później bardzo szybko wyszłyby na code review i zwyczajnie z szacunku dla czasu innych osób myślę, że każdy powinien to robić przed zacommitowaniem swojego kodu.

Na codzień korzystam z IntelliJ od firmy JetBrains, który ma w sobie wbudowane inspekcje kodu opierające się na statycznej analizie kodu. Również można zainstalować wtyczkę SonarLint, która sprawdza się całkiem nieźle. Polecam od czasu do czasu zajrzeć do ustawień takich inspekcji czy takich wtyczek i sprawdzić co faktycznie jest weryfikowane. Może jakieś reguły powinny zostać dodane, albo usunięte. To już do decyzji Twojej i Twojego zespołu.

Gałęzie

W następnym kroku przechodzę do sprawdzenia czy gałąź na której się znajduję jest odpowiednia i przede wszystkim czy jest aktualna. Nie raz zdarzało mi się, że w ostatnim momencie orientowałam się, że ktoś dodał nowe zmiany do repozytorium, których u mnie nie ma,  a powinnam je u siebie uwzględnić. Zawsze weryfikuję aktualność gałęzi jeszcze tuż przed samym zrobieniem commita.

Sam sposób aktualizacji gałęzi zależy od tego jaki model zarządzania gałęziami obowiązuje w danym projekcie. Przykładowo jeżeli jest to GitFlow to wtedy aktualizuje swój feature brach. Jeżeli nie ma tych gałęzi zbyt dużo, przykładowo jest to Trunk Based Development, to wtedy upewniam się, że mam zaciągnięte zmiany z gałęzi master / trunk / mainline – nazwa nie ma żadnego znaczenia. Najważniejsze jest to, żeby wprowadzać zmiany i commbitować na aktualnym repozytorium.

Własne code review

Jeżeli już wiem, że jestem na odpowiedniej gałęzi i jest ona aktualna to przechodzę do robienia code review samej sobie. To znaczy przeglądam kod plik po pliku w trybie poglądu zmian. Czyli tak jak zazwyczaj przeglądają osoby podczas code review. 

Sprawdzam tam kilka rzeczy. Przede wszystkim to czy commit jest atomowy. Staram się spojrzeć na niego z lotu ptaka – czy on nie powinien być podzielony na więcej niż jeden commit? Czy faktycznie wszystkie zmiany są spójne i nie można by ich rozdzielić na mniejsze commity?

Czy mój kod spełnia podstawowe zasady takie jak Don’t Repeat Yourself, You Aren’t Gonna Need It itd. Oczywiście biorę też pod uwagę wszystkie zasady, które wprowadziliśmy jako zespół w tym projekcie, których wszyscy chcemy się trzymać. 

Zwracam również uwagę na komentarze. Wyszukuję te, które są zbędne. Jeżeli edytowałam kod w okolicy istniejących komentarzy to sprawdzam czy one dalej mają sens.

Jeżeli decyduje się na wprowadzenie nowego komentarza, to upewniam się, że on dotyczy np. publicznego API, albo opisuje szczególną sytuację, której kod nie jest samoopisujący się, albo okoliczności są dziwne. Warto zwrócić uwagę na to, że najlepiej dawać komenatrze nie o tym co rob kod, ponieważ to programista z łatwością sobie odtworzy, ale dlaczego ten kod tak działa, z jakiego powodu został tak napisany. 

Przechodząc plik po pliku sprawdzam również czy kod faktycznie robi to co powinien robić pod kątem biznesowym. Czy realizuje potrzebę biznesową albo techniczną. Czasami dopiero jak się spojrzy na szerszy kontekst to widać czy ten kod w całości robi to co powinien robić.

Wiadomość commita

Jeżeli jestem spokojna o kod i o repozytorium – wiem, że wszystko zmierza w dobrą stronę – to zabieram się za pisanie wiadomości commita. Wbrew pozorom jest to bardzo istotna sprawa, dlatego, że znacznie częściej przeglądamy kod niż go piszemy. Każdy z nas miliony razy czyta kod, przegląda repozytorium, przeszukuję historię zmian, więc nadawanie odpowiednich wiadomości commitom jest bardzo istotne.

Pierwsza sparawa to czy wiadomość zawiera numer zadania z Jiry lub innego narzędzia do zarządzania projektami, odpowiadającego za tą konkretną zmianę. 

Następnie jak już upewnie się, że jest ten numer to piszę krótką wiadomość. Upewniam się, że jest ona zgodna z przyjętymi konwencjami np. jest w odpowiednim języku, czy w odpowiednim stylu. 

Ważne jest również to, żeby ta wiadomość była zwięzła. Chociaż nie można też przesadzać. Nazwy typu „Fix” i nic więcej powodują, że później jeżeli chcę coś znaleźć w tym repozytorium i przeglądam historię commitów to trwa to o wiele dłużej. 

Jeżeli uznasz, że potrzebujesz dłuższego opisu to polecam zrobić pierwsze zdanie tego opisu jako dość krótkie i zwięzłe – ogólnie opisujące co chciałeś zrobić. Dopiero w kolejnej linijce zamieścić dłuży opis. 

Jeżeli Twój commit jest częścią jakiegoś większego feature to warto na początku tej wiadomości podać nazwę tego feature. Przykładowo jeżeli programowałabym formularz kontaktowy, to mogłabym rozpocząć nazwę wiadomości commita od Contact Form i po myślniku dodać np. Add button.

Tagi

Ostatnią rzeczą nad którą się zastanawiam mając już poprawną wiadomość commita, zacommitowany kod, ale jeszcze przed wypchnięciem zmian do zdalnego repozytorium to czy na tym commicie nie powinno być taga. 

Przykładowo może być potrzeby przy zakończeniu większej funkcjonalności, może to jest akurat commit z zamknięciem wersji. To wszystko zależy od praktyk w zespole i warto to wziąć pod uwagę.

Aktualizacja

Jak sam widzisz, tych kroków wcale nie jest tak dużo. Ważne jest to, żeby sprawdzać czy Twoja checklista jest aktualna. Jeżeli zauważysz, że jakiś punkt nie przystaje do niej, jest zbędny, albo po prostu z niego nie korzytsasz, nie przynosi Ci korzyści to go usuń.

Analogicznie jeżeli na review ktoś notorycznie zwraca Ci uwagę, że popełniasz jakiś błąd to dodaj to jako punkt do checklisty. Wtedy przed commitem upewnisz się, że załatwiłeś tą sprawę i nie będziesz musiał się więcej o to martwić. 

Przechowywanie

Jeżeli chcesz zrobić własną checklistę to polecam spisać wszystkie punkty na kartce i powiesić w okolicy monitora. Ewentualnie użyj swojej ulubionej aplikacji do której często zaglądasz i w której trzymasz notatki.

Nie polecam takiej checklisty trzymać w głowie. Z dwóch powodów:

Pierwszy z nich jest taki, że ta lista, przynajmniej na początku będzie często aktualizowana. Lepiej zaoszczędzić sobie czasu i kłopotów podczas przypominania sobie tego, co aktualnie na niej mamy.

Druga sprawa to taka, że szczególnie na początku możesz zapominać o tym, że przed commitem powinieneś coś jeszcze zrobić. Taka kartka obok monitora będzie Ci o tym stale przypominać. To będzie punkt zaczepienia, który jeżeli tylko na niego zerkniesz to przypomni Ci, że jeszcze jest coś do zrobienia.

Czas

Posiadając taką checklistę możesz ją systematycznie ulepszać, tak żeby pasowała do Twojego stylu pracy. Z doświadczenia wiem, że im krótsza – tym lepiej.

Nie ma co przesadzać, ale też warto skupić się na najistotniejszych kwestiach. Przejście przez wszystkie punkty nie powinno zająć więcej niż kilka minut.