Jestem zwykłym komisarzem i uważam, że mi to odpowiada, ale co prawda moje komunikaty o zatwierdzeniach są prawie zawsze takie,
Age: 9 mins [*] Working on implementing and testing PaintSystem.
Age: 17 mins [*] Working on implementing and testing PaintSystem.
Age: 37 mins [*] Working on implementing and testing PaintSystem.
Age: 52 mins [*] Working on implementing and testing PaintSystem.
Nie mogę więc dokładnie powiedzieć, że dokonywanie tak częstych i nawykowych zobowiązań w moim oddziale (merkurialne) dokładnie zachęca do najbardziej szczegółowych dzienników zatwierdzeń. Czasami nawet popełniam kod zrobiony w połowie, jeśli powiedzmy, że moja żona prosi mnie, żebym poszedł na obiad, w którym to momencie po prostu pospiesznie skopiuję i użyję poprzedniego komunikatu „Praca nad [...]”.
Moje wzorce protokołów zatwierdzania są zwykle takie, "Working on [...] Working on [...] Working [...] Completed [...] Started working on [...] Working on [...] Completed [...] Started working on [...]"
Z drugiej strony jednak uratował mi tyłek. Czasami wpadam na przypadek, którego nie przewidywałem i nie testowałem, w którym to momencie częste zatwierdzenia pomagają mi zorientować się, gdzie dokładnie popełniłem błąd.
Więc nie wiem o najlepszych nawykach i na pewno nie jestem kimś, kto słucha idealnych nawyków rejestrowania zmian, ale z pewnością mogę powiedzieć, że częstsze zatwierdzanie może zdecydowanie pomóc, gdy trzeba wykonać regresję.
Czy każda zmiana jednowierszowa powinna otrzymać zatwierdzenie?
Popełniłem wcześniej zmiany w jednej linii, ale zwykle były to trudne i być może zabrakło mi czasu. Moje zobowiązania nie zawsze przypominają idealne i kompletne jednostki pracy lub zmiany. Jak już powiedziano, czasami są one wynikiem tego, że moja żona poprosiła mnie, żebym niespodziewanie wyszedł na obiad.
TBH, wiele moich zobowiązań, które wynikają z tego "Working on [...]"logu, nie modelują spójnych jednostek zmian (dlaczego często nie mogę wymyślić lepszego komunikatu "Working on [...]"), ale po prostu wynik mojego wzięcia oddechu, jak zrobienie sobie filiżanki kawy. "Completed [...]"Wiadomość oznacza koniec tej jednostce pracy, a tam często piszą dużo bardziej szczegółowy komunikat wraz z pierwszych "Started working on [...]"komunikatów typu, jeśli po prostu zacząć pracować nad czymś. Jeśli uśredniasz zatwierdzenia jak raz na 15 minut, wtedy wiadomości „Praca nad [...]” są bardziej jak pośrednie dla tego, co ktoś może zatwierdzić w jednym obszerniejszym zatwierdzeniu z bardziej szczegółowym komunikatem.
Czy powinienem popełnić przed jakimkolwiek testem (np. Przynajmniej w przypadku błędów składniowych / kompilacyjnych, a następnie całkowicie go cofnąć; pomysł nie zadziałał lub wiadomość jest kłamstwem)?
Po prostu kontynuuję i zatwierdzam to przed czasem nawet przeprowadzeniem testów (ponownie, gdybym miał nieoczekiwane zdarzenie). Ponadto, mimo że jestem solo, pcham na serwer (tylko ten działający tutaj w domu w sieci LAN), który obsługuje CI. To może wydawać się przesadą, ale nie wiem, przyzwyczaiłem się do tego w moich poprzednich miejscach pracy. Poza tym nie chcę, aby za każdym razem ręcznie przeprowadzałem wszystkie testy jednostki i integracji. Lubię mieć to wszystko związane z pchaniem. Jeśli test się nie powiedzie, łatwo jest pracować w sposób postępowy, w którym wykonuję regresję, poprawiam błąd w najnowszej wersji i kontynuuję. To powiedziawszy, przynajmniej buduję kod w oparciu o kompilację debugowania przed zatwierdzeniem.
Czy powinienem upewnić się, że zobowiązuję się każdego ranka / popołudnia, zanim przestanę pracować na obiad, gdy jest jeszcze świeży?
Lubię robić, zanim wyjdę i mam przerwę między programowaniem. Nie zastanawiałem się nad tym, dlaczego dokładnie, dopóki nie spotkałem się z tym pytaniem. Podejrzewam, że ma to uniemożliwić sobie wzięcie tego, gdzie skończyłem bez dziennika zmian w miejscu, w którym skończyłem, że mogę się różnić i tak dalej. Hmm, muszę do ciebie wrócić, ponieważ może nie jest to teoretycznie potrzebne, biorąc pod uwagę, jak często popełniam. Nadal czuję się bardziej komfortowo, popychając i pchając, zanim wyjdę z komputera z jakiegokolwiek powodu. Niektóre z nich mogą być dawnym lękiem psychologicznym, powiedzmy, komputer płonął po moim odejściu i miałam kierowników projektów w czasach, gdy korzystaliśmy z SVN, a deweloperzy czasami pracowali tygodniami, nie robiąc oddechu i stale przypominając nam, aby sprawdzać kod tak często, jak to możliwe, przypominając nam, że nasz kod jest własnością firmy. Jest to również trochę bardziej wydajne, szczególnie w przypadku wypychania, dzięki czemu mój proces CI może rozpocząć wykonywanie wszystkich testów, gdy mnie nie ma, abym mógł wrócić i zobaczyć wyniki.
Aha, a czasem się upijam po odejściu i zwykle jest to zły pomysł, aby pisać skomplikowany kod po pijanemu (choć nie zawsze; pewnego razu wymyśliłem naprawdę fajny system menu kontekstowego po tym, jak byłem pijany przez eurekę, ale miałem tylko 6 piw i kodowanie nie było tak skomplikowane). Jeśli spróbuję to zrobić, przynajmniej popełniłem trzeźwo napisany kod, zanim odszedłem, aby powrócić do zamiast mieszania pijanego kodu z trzeźwym kodem, w którym to momencie mój dziennik zatwierdzeń może odczytać, "Reverting back to code written before Jagermeister shots."nie robię tego bardzo często, chyba że dostałem inspirację od pijanego kodu, ale w tych rzadkich przypadkach naprawdę pomogło mi, że popełniłem coś, zanim wyszedłem i upiłem się.