Czy zatwierdzanie niedziałającego kodu jest kiedykolwiek w porządku?

Czy dobrym pomysłem jest wymaganie zatwierdzenia tylko działającego kodu?

To zatwierdzenie nie musi pozostawiać repozytorium w stanie roboczym, ponieważ:

• ... jesteśmy na wczesnym etapie projektowania, kod nie jest jeszcze stabilny.
• ... jesteś jedynym deweloperem projektu. Wiesz, dlaczego nic nie działa. Co więcej, nie przerywasz niczyjej pracy, popełniając uszkodzony kod.
• ... kod obecnie nie działa. Wprowadzimy w tym dużą zmianę. Zatwierdźmy, aby mieć punkt, do którego można wrócić, jeśli sytuacja stanie się brzydka.

• ... łańcuch jest długi, nie ma problemu, jeśli w lokalnym oddziale istnieje uszkodzony kod. To znaczy

  1. pliki lokalne
  2. miejsce postoju
  3. zatwierdza się w lokalnym oddziale
  4. zatwierdza w zdalnym oddziale funkcji osobistych
  5. połączyć ze zdalnym developoddziałem
  6. połączyć ze zdalnym masteroddziałem
  7. połączyć ze zdalnym releaseoddziałem

• ... popełnić wcześnie, popełnić często.

Tak więc w powyższym pytaniu większość odpowiedzi mówi, że zatwierdzenie niekompilowalnego kodu nie stanowi problemu w gałęziach lokalnych i funkcyjnych. Czemu? Jaka jest wartość złamanego zatwierdzenia?

Dodano: Istnieje kilka wysoko głosowanych komentarzy, które mówią, że na lokalnym brachu można robić, co tylko zechce. Nie interesuje mnie jednak techniczna strona pytania. Chciałbym raczej nauczyć się najlepszych praktyk - nawyków, które ludzie, którzy pracowali wiele lat w branży, mają najbardziej produktywne ogary.

Jestem zdumiony ogromną ilością świetnych odpowiedzi! Doprowadziły mnie do wniosku, że nie jestem wystarczająco biegły w używaniu gałęzi do organizowania mojego kodu.

Jedną z filozofii rozgałęziania (sekcja Opracowywanie strategii rozgałęziania i zasad kodowania w zaawansowanych strategiach rozgałęziania SCM - przeczytaj także Perforce Best Practices , jest to pdf, ale zawiera kilka innych szczegółów) jest to, że rozgałęziasz się na niezgodnych zasadach.

Zasady linii kodowania określają dozwolony użytek i dozwolone zameldowania dla linii kodowej i są niezbędną instrukcją obsługi SCM dla linii kodowej. Na przykład polityka kodeksu programowania powinna określać, że nie jest on przeznaczony do wydania; podobnie, zasady linii kodowej wydania powinny ograniczać zmiany do zatwierdzonych poprawek błędów. Zasady mogą również opisywać, w jaki sposób dokumentować wprowadzane zmiany, jaki przegląd jest wymagany, jakie testy są wymagane, a także oczekiwania dotyczące stabilności kodu po zameldowaniu. Polityka jest kluczowym składnikiem udokumentowanego, możliwego do wyegzekwowania procesu tworzenia oprogramowania, a linia kodowa bez polityki, z punktu widzenia SCM, wymyka się spod kontroli.

(z najlepszych praktyk Perforce)

Załóżmy, że masz gałęzie „release” (lub „master”), z których zbudowane jest wydanie oraz „trunk” (lub „dev”), w którym programiści sprawdzają działający kod. Takie są zasady oddziałów. Biorąc pod uwagę, że „działający kod” jest częścią polityki rozgałęzienia „deweloperów”, nigdy nie należy przekazywać uszkodzonego kodu do gałęzi programistów. Często zdarzają się takie sytuacje, jak serwery CI podłączone do tych gałęzi, a wpisanie zepsutego kodu do dewelopera może zepsuć gałąź każdego i zepsuć kompilację.

Są jednak chwile, w których właściwe jest wpisanie częściowego kodu, który nie działa. W takich przypadkach należy rozgałęzić się - niezgodna polityka z bagażnikiem. W tej nowej gałęzi można zdecydować o zasadach („uszkodzony kod jest w porządku”), a następnie zatwierdzić kod.

Istnieje jedna prosta zasada określająca, czy linia podziału powinna być rozgałęziona: powinna być rozgałęziona, gdy jej użytkownicy potrzebują różnych zasad odprawy. Na przykład grupa wydająca produkt może potrzebować zasady meldowania, która wymusza rygorystyczne testowanie, podczas gdy zespół programistów może potrzebować zasady, która umożliwia częste meldowania się częściowo przetestowanych zmian. Ta rozbieżność zasad wymaga odgałęzienia linii kodowej. Gdy jedna grupa programistów nie chce widzieć innej

(z najlepszych praktyk Perforce)

Uświadom sobie, że pochodzi to od SCM opartego na centralnym serwerze z silnym nastawieniem korporacyjnym. Podstawowy pomysł jest nadal dobry. Często uważa się to za niejawne - nie wpisujesz nieprzetestowanego kodu programisty do gałęzi wydania. To jest polityka.

Więc gałąź, powiedz, że gałąź ta mogła złamać kod i zatwierdzić.

Jedną z filozofii sugerowanych przez Linusa Torvaldsa jest to, że twórcze programowanie powinno być jak seria eksperymentów. Masz pomysł i podążaj za nim. Nie zawsze się to udaje, ale przynajmniej spróbowałeś. Chcesz zachęcić programistów do wypróbowania kreatywnych pomysłów. Aby to zrobić, wypróbowanie tego eksperymentu musi być tanie, a odzyskanie tanie. To jest prawdziwa siła git commits, która jest tak tania (szybka i łatwa). Otwiera ten twórczy paradygmat, który umożliwia programistom wypróbowanie rzeczy, których inaczej by nie mieli. To jest wyzwolenie git.

Tak, o ile nie jest to gałąź wydania.

W oddziałach osobistych wszystko idzie i może zostać odrzucone, jeśli eksperyment się nie powiedzie. To jedna z głównych korzyści DVCS: wolność

Wartość popełnienia złamanego kodu?: Współpraca i eksperymenty

Tak, jest OK i robię to dużo.

Chodzi o to, aby popełnić niekompilowalny kod (przynajmniej w gałęziach), że czasami twój kod jest w toku, ale praca wykonana do tej pory jest warta zapisania i / lub udostępniania innym

Moje praktyki to:

• najpierw napisz testy
• zatwierdzenia wip (praca w toku) są dobre
• popełniać często (wiele w ciągu jednego dnia) i wcześnie (zapisać kroki „robocze”)
• push po każdym zatwierdzeniu (na wypadek awarii dysków twardych / uderzenia autobusu).
• zawsze najpierw pracuj w oddziałach
• jeśli to możliwe, scalaj tylko działający kod do opanowania
• interaktywny rebase w git, aby zgnieść wycieraczki przed połączeniem głównym

Główny problem i być może ten, którego dotyczysz, dotyczy tego, kiedy masz funkcję, która zasadniczo działa i jest bardzo potrzebna firmie (i dlatego musi być w trybie „głównym”), ale ma kilka nieudanych testów. Jedną z opcji może być wykonanie testu w toku, który pozwala na razie przejść do przodu. Jest to jednak obarczone niebezpieczeństwem, ponieważ test może nigdy nie zostać naprawiony i może ustanowić wzór w innych obszarach po prostu „oczekujących” zepsutych testów zamiast ich naprawiania.

Inną opcją byłoby tymczasowe użycie i wdrożenie oddziału. Może to pomóc w niektórych sytuacjach, ale generalnie nie jest zalecane i nie jest zrównoważone.

Być może najlepszą opcją jest przyjęcie bardziej profesjonalnego podejścia do tworzenia oprogramowania i naprawdę wymaga testów roboczych dla każdego zatwierdzonego kodu. Jest to często „trudna” część tworzenia oprogramowania, a nie kodowanie, które wielu ludzi sobie wyobraża. Lepsze podejście najprawdopodobniej będzie wymagało lepszych wstępnych szacunków, alokacji zasobów, ustalania priorytetów itp. Plus, podczas zwinnego opracowywania, dając wystarczająco dużo czasu i dyscypliny, aby naprawić wszelkie problemy zarówno w momencie ich wystąpienia, jak i podczas sesji pielęgnacyjnych.

Skoncentruj się na tym, co oznacza „zrobione” - oznacza to, że kod ORAZ testy zostały napisane, zostały refaktoryzowane i działają. Jeśli usłyszysz komentarze takie jak „najczęściej gotowe, po prostu musisz napisać / naprawić / refaktoryzować testy, to NIE jest to zrobione. Powiedzenie, że funkcja jest wykonywana bez jej kompletności technicznej, jest jednym z najczęstszych błędów młodszych programistów.

Wartość każdego zatwierdzenia, zepsutego lub nie, polega na tym, że kod zostaje zatwierdzony na serwerze. W środowiskach profesjonalnych serwer ten jest bezpieczny, nadmiarowy i wykonuje kopie zapasowe. Jeśli pracuję cały dzień, zatwierdzanie jest formą upewnienia się, że mój kod przetrwa wszystko, co stanie się z moją maszyną lokalną. Dyski twarde giną. Laptopy się gubią lub kradzią. Kopie zapasowe serwera repozytorium będą dostępne, nawet jeśli budynek spłonie.

Pomyśl o tym w ten sposób. Jako programista jedną z najbardziej destrukcyjnych rzeczy, które robisz, jest powstrzymanie innych programistów w zespole przed pracą nad ich zadaniami.

Filozofia zatwierdzania tylko działającego kodu pochodzi od zespołów programistów pracujących na tym samym pojedynczym pniu w repozytorium. Teraz może wydawać się szaleństwem, ale 10 lat temu był to normalny sposób pracy. Gałąź pojawi się, gdy będziesz chciał stworzyć stabilną wersję, ale myśl o deweloperze pracującym w gałęzi w celu wdrożenia nowej funkcji była prawie niesłychana.

Jeśli twoje środowisko oznacza, że ​​twoje zatwierdzenia nie wpływają natychmiast na innych programistów, wtedy często zatwierdzaj. zapewnia większe bezpieczeństwo w kodzie, ułatwiając przywrócenie błędu w kodzie, a wiele systemów kontroli źródła zapewnia pewną ochronę kodu dla zatwierdzonego kodu (choć nie wszystkie).

Teraz, upewniając się, że twoje połączenia z gałęziami współdzielonymi z innymi programistami działają, i że każdy kod, który promujesz na tym poziomie, kompiluje się, przeszedł wszystkie testy jednostkowe i inne kontrole poczytalności oparte na zespole ... jest to niezbędne, jeśli nie chcesz kupuj piwo w pubie ...

Zanim zaczniesz dogmatyzować pracę z kontrolą wersji, warto zastanowić się, dlaczego pracujesz z kontrolą wersji.

Zobowiązanie do kontroli wersji zawiesza stan twojego kodu do wykorzystania w przyszłości - wszystko inne wypada z tego. Patrzenie na różnice i tworzenie łatek to po prostu zobaczenie, jak zmieniał się kod między migawkami. Gałęzie i tagi to tylko sposoby organizowania migawek. Udostępnianie kodu innym programistom pozwala im tylko spojrzeć na konkretną migawkę.

Kiedy powinieneś popełnić? Gdy pojawi się uzasadniona szansa, przyjrzysz się w przyszłości kodowi (lub komunikatowi zatwierdzającemu zmianę).

Git zapewnia dużą elastyczność w organizowaniu migawek. Nie ma centralnego repozytorium, więc możesz współdzielić kod z innymi programistami bez wypychania swojego stanu do repozytorium „głównego”. Możesz łatwo tworzyć, scalać i usuwać gałęzie, aby odizolować szczegóły zestawu stanów od narracji głównego kodu. Możesz zatwierdzić lokalnie, aby cofnąć śledzenie obecnego rozwoju, a następnie spakować wszystko do jednego zatwierdzenia przed wypchnięciem go, aby inni mogli je zobaczyć. Możesz otagować określone wersje, aby można je było później łatwo znaleźć.

KISS . To, co działa najlepiej dla pojedynczego programisty na wczesnych etapach rozwoju małego projektu, będzie zupełnie inne niż to, co musisz zrobić, gdy setka programistów pracuje nad dziesięcioletnim, krytycznym systemem. W każdym procesie tworzenia oprogramowania należy unikać tworzenia niepotrzebnych artefaktów tylko dlatego, że ktoś inny kazał ci to zrobić.

Budowanie / wydawanie oddziałów

Nigdy nie powinieneś celowo przypisywać uszkodzonego kodu do gałęzi kompilacji. Każda gałąź, która jest w trakcie ciągłej integracji lub z której wykonywane są wydania lub codzienne kompilacje, powinna zawsze znajdować się w stanie możliwym do zwolnienia.

Inne oddziały: często zapisuj stan

W przypadku gałęzi prywatnych lub fabularnych cele są często różne. Pożądane może być częste sprawdzanie kodu (działającego lub nie). Ogólnie rzecz biorąc, będziesz chciał zatwierdzić za każdym razem, gdy zajdzie potrzeba przewinięcia do bieżącego stanu.

Rozważ te przykłady, w których zapisany stan zapewnia znaczącą korzyść:

• Możesz wykonać zatwierdzenie tuż przed uruchomieniem globalnego wyszukiwania i zamiany, aby móc cofnąć drzewo w jednej operacji, jeśli coś pójdzie nie tak.
• Możesz wykonać serię tymczasowych zatwierdzeń podczas refaktoryzacji złożonego fragmentu kodu, abyś mógł podzielić lub przewinąć do tyłu, jeśli w końcu coś zepsujesz.
• Możesz wykonać zatwierdzenie, uruchomić nową gałąź lub utworzyć znacznik, jeśli chcesz spróbować czegoś eksperymentalnego, mając jednocześnie możliwość powrotu do stanu bieżącego działającego drzewa.

Zatwierdzenie części uszkodzonej bazy kodu jest w porządku, pod warunkiem, że jest lokalne.

Dlaczego?

• Konieczne jest stosowanie zatwierdzania jako punktu zapisu w rozwoju
• Pokazuje schemat myślenia zastosowany podczas opracowywania produktu.
• Nie przerywa współpracy .

Jednak gdy istnieje zespół programistów, filozofia domu programistycznego jest najważniejsza i zastępuje indywidualne zachowania popełnienia. Niektóre domy programowania decydują się na rejestrowanie całego postępu, podczas gdy inne decydują się na zatwierdzenie tylko kodu rozwiązującego daną funkcję. W takim przypadku wartość ( koszt , z punktu widzenia zarządzania oprogramowaniem) uszkodzonego zatwierdzenia jest tragiczna:

1. czas poświęcony na dalsze funkcje spędza teraz naprawianie błędów ...
2. ograniczenie rozwoju nie jest spełnione ...
3. produkt nie jest wysyłany na czas

Do tych trzech można dodać inne punkty, kaskadowo wywołujące efekty gwałtownie w załamaniu firmy ... oczywiście musi to być efekt przewlekłego nawykowego popełnienia złego kodu.

Nie sądzę, aby popełnianie uszkodzonego kodu było w porządku.

Co się stanie gdy

• Wymagana jest pilna poprawka. Baza kodu jest uszkodzona. Jesteś zmuszony wycofać, naprawić i wdrożyć.

• Ktoś inny zaczyna pracę w tym samym oddziale, nie wiedząc, że popełniłeś uszkodzony kod. Mogą ścigać „czerwonego śledzia”, myśląc, że ich zmiany coś zepsuły.

• Decydujesz się na opuszczenie firmy, wyjazd na wakacje lub nie możesz przyjechać do pracy z jakiegokolwiek powodu. Twoi koledzy będą musieli kopać głęboko, aby znaleźć to, co jest zepsute i dlaczego zostało popełnione w stanie złamania.

• Ktoś wdraża Twój „uszkodzony kod”? Może to być „koniec gry”, jeśli pracujesz z danymi osobowymi lub u dostawcy usług płatniczych.

Odpowiedz na @WarrenT

Zgadzam się z tobą, że w idealnym świecie, w którym wszyscy pracują w dziale funkcji, zatwierdzanie niedziałającego kodu może działać. Pracowałem nad dużymi projektami i nawet wtedy zdarzały się przypadki, w których wiele osób musiało pracować w jednym oddziale. Widziałem także, jak ludzie przypisywali „niedziałający” kod do głównej gałęzi, ponieważ wydanie było za kilka tygodni i planowali naprawić go następnego dnia. Wszystkie te rzeczy są kandydatami na katastrofę i głęboko wierzę, że należy ich unikać za wszelką cenę.

Kilka pytań, które pomogą Ci ustalić, czy zatwierdzenie niedziałającego kodu jest prawidłowe:

1. Czy jesteś przepracowany?
2. Czy twoi koledzy z drużyny ciągle psują kompilację?
3. Czy twoja baza kodu jest bałaganem i najwyraźniej nie może być już gorzej?

Jeśli powiesz którekolwiek z powyższych, to tak, możesz zatwierdzić niedziałający kod.

Pamiętaj tylko, aby jak najszybciej to naprawić, przykryj testami jednostkowymi i przeproś za złamanie kompilacji.