Konwencjonalne komity nie uratują twoich wiadomości commit

Szybkie wyszukiwanie w internecie ujawni mnóstwo artykułów uczących cię, jak pisać wiadomości commit. 90% z tych artykułów mówi ci, abyś korzystał z konwencjonalnych commitów. Jednak znaczna liczba deweloperów wciąż ma z tym problem. Wiedzą, że powinni przestrzegać tych konwencji, ale trudno im je zastosować w praktyce. Za każdym razem, gdy commitują kod, zastanawiają się, czy napisać "refactor" czy "chore". Widziałem nawet projekty, gdzie lista wiadomości commit składała się wyłącznie z jednej i tej samej wiadomości: "feat: add page", ponieważ pisanie wiadomości commit było dla nich zbyt trudne i po prostu się poddali.

Jest za wcześnie, aby mówić o konwencjonalnych commitach#

Nie mówię, że konwencjonalne commity są złe. Mają wiele dobrze znanych zalet:

• Zapewniają jednolity format, czyniąc wiadomości commit bardziej znormalizowane
• Są łatwe do parsowania przez narzędzia automatyczne, umożliwiając automatyczne generowanie changelogu
• Pomagają członkom zespołu zrozumieć cel i zakres zmian w kodzie
• Umożliwiają szybkie identyfikowanie różnych typów zmian w kodzie

Jednak, gdy deweloper wciąż ma problem z pisaniem dobrych wiadomości commit nawet po zastosowaniu konwencji commitów, podsunięcie mu artykułu o tym, jak używać konwencjonalnych commitów, nauczenie, co oznacza typ feat, co oznacza typ fix, jest w rzeczywistości bezsensowne. To jak przekazanie zaawansowanej książki kucharskiej komuś, kto nie wie, jak gotować, bez nauczenia go, jak używać podstawowych składników i przyborów. A jednak takie artykuły są wszędzie w internecie. Niewielu z nich wie, że konwencjonalne commity mogą być naprawdę skuteczne tylko wtedy, gdy deweloperzy mają jasne myślenie i umiejętność precyzyjnego podziału zadań.

Więc konwencjonalne commity nie są złe, ale zanim do tego dojdzie, musimy ustanowić właściwe podejście do rozwoju i korzystać z naukowego myślenia deweloperskiego.

Kluczowe myślenie dla pisania dobrych wiadomości commit#

Zmiany w kodzie powinny robić jedną rzecz na raz#

W rozwoju oprogramowania "robienie jednej rzeczy na raz" to ważna zasada. Dotyczy ona nie tylko pisania kodu, ale także commitowania kodu. Kiedy skupiamy się na jednym konkretnym zadaniu lub zmianie naraz, nasz kod staje się bardziej przejrzysty, a nasze intencje bardziej zrozumiałe. Ta metoda nie tylko poprawia czytelność kodu, ale także znacznie upraszcza proces przeglądu kodu. Recenzenci mogą łatwiej zrozumieć i zweryfikować cel każdej zmiany.

Co więcej, ta metoda zapewnia wygodę dla potencjalnych wycofań kodu. Jeśli wystąpią problemy, możemy łatwiej zlokalizować i odwrócić konkretne zmiany, nie wpływając na inne, niezwiązane części. Co najważniejsze, gdy każda zmiana robi tylko jedną rzecz, wiadomość commit opisująca tę zmianę naturalnie staje się bardziej precyzyjna i znacząca.

W praktyce oznacza to, że musimy jasno określić zadanie do wykonania przed rozpoczęciem kodowania. Po ukończeniu zadania powinniśmy natychmiast commitować kod, a nie czekać, aż wiele zadań zostanie ukończonych przed ich wspólnym commitowaniem. Jeśli podczas kończenia bieżącego zadania odkryjemy inne obszary wymagające modyfikacji, najlepszym podejściem jest ich zanotowanie i rozpatrzenie osobno po ukończeniu bieżącego zadania. Na przykład, gdy wdrażasz funkcję i odkrywasz istniejące błędy, nie powinieneś od razu naprawiać błędu wraz z nowym kodem funkcji, ale raczej wdrożyć najpierw funkcję, a następnie naprawić odkryty błąd w innym commitcie lub najpierw naprawić błąd, a potem commitować funkcję.

Wiadomości commit istnieją przed napisaniem kodu#

Wielu deweloperów zaczyna myśleć o tym, jak pisać wiadomości commit dopiero po zakończeniu pisania kodu, lecz w rzeczywistości, wiadomości commit powinny istnieć, zanim zaczniemy kodować. Dzieje się tak, ponieważ wiadomości commit zasadniczo odzwierciedlają kroki, które podejmujemy, aby ukończyć zadanie. Innymi słowy, są to nasze punkty do wykonania.

Kiedy zaczynamy zadanie, powinniśmy najpierw pomyśleć, jakie konkretne kroki są potrzebne do jego ukończenia. Te kroki to nasza lista rzeczy do zrobienia, a jednocześnie przyszłe wiadomości commit. Mając tę listę, każda nasza zmiana w kodzie ma cel, utrzymując nas w skupieniu podczas kodowania i zapobiegając odchodzeniu od zadania.

Co ważniejsze, ta metoda może znacząco poprawić naszą wydajność. Kiedy ukończymy krok, odpowiednia wiadomość commit jest już przygotowana, a my możemy jej bezpośrednio używać, redukując czas poświęcony na zastanawianie się, jak opisać zmianę. Jednocześnie, ponieważ te wiadomości commit są tworzone, gdy mamy pełne zrozumienie zadania, zazwyczaj są wyższej jakości i bardziej informatywne.

Przypuśćmy, że musisz wdrożyć nową funkcję rejestracji użytkownika. Możesz zaplanować kroki zadania w ten sposób:

1. Refaktoryzacja istniejącego komponentu formularza, aby był bardziej ogólny i wielokrotnego użytku
2. Stworzenie formularza rejestracji użytkownika
3. Wdrożenie integracji API dla rejestracji użytkownika
4. Dodanie testów jednostkowych dla funkcji rejestracji użytkownika
5. Aktualizacja dokumentacji dotyczącej funkcji rejestracji użytkownika

Odpowiadające tym krokom wiadomości commit mogą wyglądać następująco:

1. refactor: usprawnienie istniejącego komponentu formularza dla wielokrotnego użytku
2. feat: stworzenie formularza rejestracji użytkownika
3. feat: wdrożenie integracji API dla rejestracji użytkownika
4. test: dodanie testów jednostkowych dla rejestracji użytkownika
5. docs: aktualizacja dokumentacji dotyczącej funkcji rejestracji użytkownika

W ten sposób masz jasne kroki zadania i odpowiadające im zwięzłe wiadomości commit przed rozpoczęciem kodowania. Te wiadomości commit są rzeczywiście twoją listą rzeczy do zrobienia, prowadząc cię przez cały proces wdrażania funkcji.

Gdy ukończysz każdy krok, możesz użyć odpowiedniej wiadomości commit, aby commitować swój kod. To nie tylko pomaga lepiej organizować i realizować zadania, ale także zapewnia, że każdy commit koncentruje się na konkretnym kroku, czyniąc cały proces rozwoju bardziej przejrzystym i zarządzalnym. Jeśli podczas rzeczywistego kodowania trzeba nieco dostosować wiadomość commit, można wprowadzić drobne modyfikacje, aby dokładniej opisać faktyczne zmiany.

Konwencjonalne commity stają się naturalnym wyborem#

Kiedy rozwijamy właściwe podejście do rozwoju, używanie konwencjonalnych commitów staje się naturalne. Na tym etapie zauważysz, że wybór odpowiedniego prefiksu typu (takiego jak feat, fix, refactor, itd.) staje się prosty, ponieważ twoje wiadomości commit już jasno odzwierciedlają kroki twojego zadania.

Jeśli chcesz dowiedzieć się więcej o tym, jak używać konwencjonalnych commitów, online jest wiele doskonałych artykułów. Ale pamiętaj, te standardy mogą być naprawdę skuteczne tylko wtedy, gdy są zbudowane na fundamentach właściwego podejścia do rozwoju.

Podsumowanie#

Pisanie dobrych wiadomości commit nie polega tylko na przestrzeganiu pewnego formatu. Wymaga to od nas utrzymywania jasnego myślenia w trakcie procesu rozwoju, wyjaśnienia celu każdej zmiany i zastanowienia się, jak opisać naszą pracę przed rozpoczęciem kodowania.

Konwencjonalne commity są rzeczywiście użytecznym narzędziem, ale mogą osiągnąć maksymalny efekt tylko wtedy, gdy są połączone z właściwym podejściem do rozwoju. Praktykując dwie zasady "robić jedną rzecz na raz" i "zastanawiać się nad wiadomościami commit z wyprzedzeniem", możemy nie tylko poprawić jakość wiadomości commit, ale także zwiększyć ogólną efektywność rozwoju i jakość kodu.

Mam nadzieję, że ten artykuł pomoże ci przemyśleć twój proces rozwoju i zachęci do wypróbowania tych metod. Pamiętaj, dobre nawyki rozwojowe wymagają czasu na ich wypracowanie, ale gdy już się ukształtują, znacznie poprawią twoją efektywność pracy i jakość kodu.