Kiedy zatwierdzić kod?

Podczas pracy nad projektem kod może zostać opracowany dość szybko w ciągu jednego dnia lub kawałek po kawałku przez dłuższy okres kilku tygodni / miesięcy / lat. Ponieważ zatwierdzenia kodu stają się uważane za miarę rozwoju projektu, tak naprawdę nie oznacza to, że napisano więcej kodu niż projekt o mniejszej liczbie zatwierdzeń.

Pytanie brzmi, kiedy naprawdę dokonać zatwierdzenia w repozytorium, aby zatwierdzenie było uzasadnione?

Jako dodatek: Czy poprawną praktyką jest mierzenie rozwoju projektu na podstawie jego zobowiązań?

Zobowiązujesz się, gdy osiągniesz stan bazy kodu, który chcesz zapamiętać. Istnieje wiele powodów, dla których możesz chcieć zapamiętać konkretny stan bazy kodu, więc nie może być żadnych sztywnych reguł określających, kiedy dokonać zatwierdzenia. Jednak liczba zatwierdzeń zdecydowanie nie jest miarą jakości ani postępu.

W tym kontekście lubię myśleć o kodowaniu jako o wspinaczce skalnej. Wspinasz się trochę, a następnie umieszczasz kotwicę w skale. Jeśli kiedykolwiek upadniesz, ostatnią posadzoną przez ciebie kotwicą jest punkt, który cię zabezpiecza, więc nigdy nie spadniesz z odległości większej niż kilka metrów. To samo z kontrolą źródła; trochę kodujesz, a kiedy osiągniesz nieco stabilną pozycję, popełniasz poprawkę. Jeśli okropnie zawiedziesz, zawsze możesz wrócić do ostatniej wersji i wiesz, że jest stabilna.

To powiedziawszy, jeśli pracujesz w zespole, zwykle upewniasz się, że wszystko, co popełniasz, jest kompletne, ma sens, buduje się czysto i nie niszczy rzeczy innych. Jeśli chcesz wprowadzić większe zmiany, które mogą zakłócać pracę innych ludzi, stwórz oddział, abyś mógł dokonywać zmian bez przeszkadzania innym.

Zależy to również od używanego systemu SCM. Systemy rozproszone zazwyczaj sprawiają, że scalanie i rozwidlanie jest bezbolesne i szybkie, a można zatwierdzać lokalnie; oznacza to, że powinieneś dużo popełnić i pchnąć / scalić, kiedy wykonałeś znaczną ilość pracy. W przypadku scentralizowanych systemów, takich jak svn lub cvs, zatwierdzanie jest bardziej kosztowne i wpływa na wszystkich. Rozgałęzienie częściowo rozwiązuje ten problem, ale ponieważ dzieje się to na serwerze, może być boleśnie powolne, a scalanie może być kłopotliwe. Dlatego w scentralizowanych SCM często zachowuje się bardziej ostrożną kulturę, w której dokonuje się zobowiązania dopiero po wykonaniu znacznej ilości pracy.

Jeśli chodzi o dodatek: Proszę, nie rób tego. Linie kodu, liczba zatwierdzeń, liczba znalezionych / rozwiązanych błędów itp. Są bardzo złymi pomiarami jakości, a nawet ilości.

Jeśli korzystasz z DVCS, takich jak Mercurial lub Git, powinieneś zobowiązać się do lokalnego repozytorium, ilekroć wykonasz znaczną ilość pracy. Pchaj go jednak do współużytkowanego repozytorium tylko wtedy, gdy działa, samodzielna zmiana, która została przetestowana.

W przypadku nie dystrybuowanego VCS (jak np. SVN) stosuje się tę samą logikę, zamiast lokalnego repozytorium użyj gałęzi prywatnej zamiast push - scal do gałęzi głównej.

Powinieneś popełniać wcześnie i często.

Znam ludzi, którzy popełniają tak często, jak co 90 sekund. Poważnie. Wydaje się, że działa dla nich. Eksperymentowałem z zatwierdzaniem za każdym razem, gdy zapisuję plik, co jest prawdopodobnie częściej niż 90 sekund. Dzisiaj prawdopodobnie popełniam co 15 minut. VCS, który pozwala zgnieść wiele zatwierdzeń w jeden i który pozwala na zatwierdzenie lokalne (np. Git), czyni to o wiele łatwiejszym.

Jak często powinieneś robić? Trudno powiedzieć, ale prawdopodobnie częściej niż teraz. Kontynuuj zaangażowanie coraz częściej, znajdź punkt, który wydaje się absurdalnie zbyt często, a następnie trochę się wycofaj. Są szanse, że skończysz z czymś rozsądnym.

Mierzysz rozwój produktu na podstawie wartości dostarczanej jego użytkownikom. Nie ma innego dokładnego pomiaru.

Zatwierdzenia są elementami składowymi dowolnych danych / kodu kontrolowanych wersjami. Każde zatwierdzenie powinno wykonać dokładnie jedną z następujących czynności:

• Dodaj nowy fragment danych lub funkcji
• Napraw jeden lub więcej błędów (jeden zatwierdzenie dla każdej poprawki, jeśli to możliwe), gdzie poprawka może być:
  • Poprawa wydajności
  • Korygowanie nieprawidłowego działania kodu
  • Usuwanie błędów typograficznych
• Refaktoryzacja kodu lub danych bez zmiany semantyki. To zawiera:
  • Przepisywanie kodu, który zachowuje się identycznie jak oryginał
  • Zmiana reprezentacji danych na inny format
  • Formatowanie kodu lub danych w celu spełnienia wytycznych formatowania projektu
• Scal zmiany z innego oddziału (albo w górę / w dół)

Również podczas pracy w oddziałach zatwierdzenia muszą przejść do gałęzi, która jest bardziej trafna. Dwa zatwierdzenia nie powinny mieć tego samego komunikatu zatwierdzenia (implikującego podobne zmiany), ale w różnych gałęziach, ponieważ dezorientują współpracowników. Lepszym sposobem jest zatwierdzenie głównej gałęzi i połączenie z gałęzią funkcji.

Jeśli osoby zatwierdzające przestrzegają powyższej zasady, trywialne staje się:

• Cofnij określoną zmianę bez żadnych skutków ubocznych
• Zidentyfikuj zachowanie zmieniające kod na podstawie zmian formatowania kodu
• Łączenie różnych gałęzi, unikając większości konfliktów
• Współpracuj z innymi programistami, którzy mogą łatwo wprowadzić zmiany

Jeśli chodzi o pomiar postępów projektu w oparciu o zatwierdzenia, możliwe jest, że nie zostaną wzięte pod uwagę zmiany w refaktoryzacji i zmiany w usuwaniu błędów.

Zatwierdź tylko wtedy, gdy jednostka pomyślnie przetestowała daną funkcję / moduł / funkcjonalność i masz wystarczającą pewność, że jest ona gotowa do integracji lub testowania systemu.

I aby odpowiedzieć na dodatkowe pytania - NIE !! miarą tego, gdzie projekt jest, nigdy nie powinna określać liczba zatwierdzeń ... kto wie, co faktycznie zostało popełnione? Czy został pomyślnie przetestowany w systemie, a nawet w jednostce. Tylko dlatego, że jest zaangażowany - to nie znaczy, że jest gotowy do produkcji.

Jako dodatek: Czy poprawną praktyką jest mierzenie rozwoju projektu na podstawie jego zobowiązań?

Nie. Codziennie nadawano WTF, dlaczego jest to okropny pomysł.

Moją ogólną zasadą przy zatwierdzaniu kodu jest meldowanie się po ukończeniu fragmentu kodu i jego kompilacji. Chunk nie jest tak naprawdę zdefiniowany. Jeśli jest to małe zadanie, mogę się nie zameldować, dopóki nie skończę. Jeśli jest większy, mogę się zameldować po zakończeniu każdej części logicznej.

Ale nigdy nie sprawdzaj, czy się nie kompiluje. Wiem, że to głupie mówienie na głos, ale wcześniej musiałem to tłumaczyć ludziom.

Dokonaj zatwierdzenia, gdy kod jest gotowy do współdzielenia z innymi użytkownikami kodu - gdy jest on względnie stabilny, bezpieczny i odpowiednio przetestowany.

I nie, nie sądzę, by zatwierdzenia były świetną miarą rozwoju projektu, ponieważ znam niektórych programistów, którzy dokonają każdej małej i drobnej zmiany, a inni, którzy dokonają tylko ogromnych poważnych zmian w funkcjonalności. Jak mierzysz ilościowo wartość jednego zatwierdzenia nad drugim?

Jak tylko odpowiednie zadanie zostanie wykonane . Zadaniem jest częścią historii użytkownika .

Zadanie zostało wykonane , gdy:

• odpowiednie testy jednostkowe są zaliczone,
• kod jest odpowiednio udokumentowany i
• kod jest zatwierdzony.

Możesz mieć inną definicję zrobione .

Nie widzę wartości w pomiarze liczby zatwierdzeń. Jeśli jednak widzisz kogoś pracującego przez długi czas nad tą samą historią użytkownika (lub, co gorsza, historiami), jest to zapach.

Zatwierdź każdą znaczącą zmianę, która według ciebie nie psuje niczego. Jedyne, czego nie powinieneś robić, to zmiany stylu, ponieważ nie zawierają one zmiany w logice. Ale w przeciwnym razie im mniejsze zmiany, tym lepiej.

Im mniejsze zatwierdzenia, tym bardziej szczegółowe możesz udokumentować proces myślowy, który jest jednym z aspektów dobrego dziennika zatwierdzeń. Dobry przegląd kodu powinien dotyczyć nie tylko wyniku kodu, ale również procesu przemyślenia.

Ponadto posiadanie wielu małych zatwierdzeń ułatwia dzielenie na dwie części, o wiele za mało używaną funkcję kontroli wersji, która pozwoliła mi zaoszczędzić wiele godzin na szukaniu błędów igłowych w bazach kodu stogu siana.

Krótko mówiąc, przecinając; Odkryj problem w bieżącej bazie kodu. Następnie wybierz zatwierdzenie w dzienniku zmian, w którym masz pewność, że konkretny problem nie istniał. Zacznij od sprawdzenia zatwierdzenia w środku między wersją „dobrą” i „złą”. Sprawdź, czy problem nadal występuje. Jeśli tak, musisz spojrzeć wstecz, na środek „dobrego” i wcześniej przetestowanego zatwierdzenia. Jeśli problem zniknął, został wprowadzony po tej konkretnej zmianie, więc musisz sprawdzić środek między „złym” a wcześniej przetestowanym zatwierdzeniem. Powtarzać. Ostatecznie skończysz z zatwierdzeniem, które wprowadziło problem. Ale tylko jeśli masz małe zobowiązania, w przeciwnym razie będziesz po prostu wiedział, w którym dużym kupie zmian pojawił się problem.

Oto jak działa z Git, ale zasada ma zastosowanie do dowolnej kontroli wersji.

Kiedy:

• buduje (ZAWSZE)
• testy jednostkowe są zaliczone
• działa (chyba że jest wyraźnie oznaczone jako „praca w toku”)
• korzyści wynikające z zapisania stanu kodu przeważają problemy związane z uruchamianiem testów, myśleniem o dobrym komunikacie zatwierdzenia i rozwiązywaniem wszelkich konfliktów scalania podczas procesu zatwierdzania