Czy codzienne wprowadzanie / sprawdzanie kodu jest dobrą praktyką?

Czytałem notatkę Martina Fowlera na temat ciągłej integracji, a on wymienia jako „Wszyscy zobowiązują się do głównej linii każdego dnia”.

Nie lubię zatwierdzać kodu, chyba że sekcja, nad którą pracuję, jest kompletna i że w praktyce zatwierdzam swój kod co trzy dni: jeden dzień w celu zbadania / odtworzenia zadania i wprowadzenia wstępnych zmian, drugi dzień w celu uzupełnienia zmian , i trzeci dzień, aby napisać testy i posprzątać ^ do przesłania. Nie czułbym się komfortowo, przesyłając kod wcześniej.

Teraz pobieram zmiany z repozytorium i integruję je lokalnie zwykle dwa razy dziennie, ale nie robię tego często, chyba że mogę wykonać mniejszą pracę.

Pytanie: czy codzienne zobowiązanie jest tak dobrą praktyką, że powinienem zmienić przepływ pracy, aby go dostosować, czy nie jest to wskazane?

Edycja: Wydaje mi się, że powinienem był wyjaśnić, że miałem na myśli „zatwierdzenie” w jego CVS (inaczej „push”), ponieważ jest to prawdopodobnie to, co Fowler miałby na myśli w 2006 roku, kiedy to napisał.

^ Kolejność jest bardziej dowolna i zależy od zadania, moim celem było zilustrowanie okresu czasu i działań, a nie dokładnej sekwencji.

Nie zgadzam się z tą zasadą i zgadzam się z tym, co powiedział Mason Wheeler . Chciałbym dodać kilka pomysłów.

Próbuję zatwierdzić za każdym razem, gdy mam znaczącą zmianę do zatwierdzenia: może to być kilka razy dziennie, jeśli naprawię kilka drobnych błędów, lub raz w tygodniu, jeśli pracuję na większym oprogramowaniu, z którego nie mogą korzystać pozostałe kod w jakikolwiek znaczący sposób, dopóki nie osiągnie spójnego stanu.

Ponadto interpretuję zatwierdzanie jako publikację znaczącej wersji, która dodaje nową funkcjonalność do podstawy kodu. Myślę, że należy spróbować wyczyścić kod przed zatwierdzeniem, aby inni programiści mogli zrozumieć znaczenie i cel zmiany, gdy patrzą na historię zmian. Im mniej zmian widzą inni programiści w historii, tym lepiej: kiedy patrzę na historię zmian, chcę zobaczyć przyrosty, które dodają znaczącą funkcjonalność; Nie interesuje mnie każdy mały pomysł, który każdy programista miał i chciał wypróbować, zanim dotrą do rozwiązania.

Co więcej, nie sądzę, że dobrym pomysłem jest używanie serwera SVN (lub innego systemu kontroli wersji) jako narzędzia do tworzenia kopii zapasowych, do których zobowiązana jest bieżąca migawka kodu (pod warunkiem, że się kompiluje): można użyć pamięci USB lub zewnętrzny dysk USB lub dysk sieciowy do dublowania bieżącego kodu, aby nie zgubił się w przypadku awarii komputera. Kontrola wersji i tworzenie kopii zapasowych danych to dwie różne rzeczy. Publikowanie wersji to nie to samo, co zapisanie migawki kodu.

Wreszcie, myślę, że nie powinno być problemu z dokonywaniem od czasu do czasu (tj. Tylko wtedy, gdy ktoś jest naprawdę zadowolony z obecnego stanu kodu) i unikanie konfliktów scalania nie jest dobrym uzasadnieniem częstego (zbyt) popełniania. Wiele konfliktów scalania ma miejsce, gdy różne osoby pracują jednocześnie nad tymi samymi plikami, co jest złą praktyką (patrz np. Ten artykuł , punkt 7). Konflikty scalania należy ograniczyć, dzieląc projekt na moduły z przejrzystymi interfejsami i możliwie najmniejszą liczbą zależności, oraz koordynując pracę programistów, tak aby kod, na którym pracują, nakładał się w jak najmniejszym stopniu.

Tylko moje 2 centy.

EDYTOWAĆ

Innym powodem, dla którego przyszło mi na myśl przedwczesne zatwierdzanie, jest to, że (bardzo) błędna wersja nie może zostać przetestowana. Jeśli zobowiązujesz się do połączenia, a zespół testowy testuje codziennie, mogą nie mieć wersji testowej przez kilka godzin (lub przez jeden dzień). Nawet jeśli nie spróbujesz naprawić błędu i po prostu cofniesz zmiany, przebudowa może potrwać kilka godzin. Przy, powiedzmy, pięciu testerach pracujących w twoim zespole, zmarnowałeś 5 x 2 = 10 godzin czasu zespołu z powodu braku aktywności. Zdarzyło mi się to raz, więc naprawdę staram się jak najszybciej unikać przedwczesnych zmian w nazwie commit .

Zatwierdzam kod kilka razy dziennie . Ilekroć dochodzę do punktu, w którym kod jest wystarczająco kompletny, aby skompilować i nie psuje innych rzeczy, wchodzi.

Powinieneś pomyśleć o zerwaniu z pracą, aby móc bezpiecznie odprawić się kilka razy dziennie.

Powody tego są dwa:

1. Każda praca, która nie jest zalogowana, może zostać utracona - komputer może mieć katastrofalną awarię. W takim przypadku im dłużej czekasz, tym więcej tracisz pracy.
2. Im więcej pracy wykonasz bez odprawy, tym więcej kodu będzie musiał zintegrować inni, kiedy w końcu zdecydujesz, że to zrobi. To zwiększa szanse na konflikty i problemy z łączeniem.

Niewolnicze stosowanie się do jakiejkolwiek metodologii lub praktyki bez zrozumienia przyczyn leżących u jej podstaw nigdy nie jest dobrym pomysłem. Stąd pochodzi program kultowego ładunku.

Dlatego „powinienem popełniać każdy dzień, bo tak powiedział Martin Fowler”, jest po prostu głupi. A czasem jest to również niepraktyczne. Jeśli pracujesz nad skomplikowaną nową funkcją, możesz nie dotrzeć do punktu, w którym warto się zalogować, dopóki nie pracujesz nad nią przez kilka dni.

Nie oznacza to, że powinieneś upewnić się, że wszystko jest idealne przed sprawdzeniem. To dobry sposób na utratę pracy, jeśli coś pójdzie nie tak. Właściwe jest, aby rozwinąć i odpowiednio ocenić sytuację. Praktyczne zasady mogą ci bardzo pomóc.

Oded podał dwa ważne powody, dla których kod należy zatwierdzać tak często, jak to możliwe. Dodam jeszcze kilka:

1. Podczas pracy nad fragmentem kodu inne mogą potrzebować niektórych funkcji tego kodu. Nie powinni czekać 6 dni, aby je zdobyć. W takim przypadku moi koledzy zwykle tworzą prototyp w moim fragmencie kodu, zatwierdzają go, dodajemy treść i zatwierdzam ponownie. I zwykle odbywa się to w ciągu kilku godzin.

2. „Wspólny” kod umożliwia każdemu jak najszybsze zobaczenie każdej zmiany. Jeśli fragment kodu, nad którym pracujesz, jest całkowicie oddzielony od pracy innych i nie będziesz musiał czekać, to zaleca się utworzenie gałęzi, nad którą będziesz pracować, a następnie, jeśli wszystko się powiedzie, scal ją z główna linia.

Mocno wierzę w każdą logiczną zmianę, którą warto zachować. Zatwierdź często, a jeśli kod nie jest wart zachowania, przywróć go z powrotem do stanu czystego. Im dłużej czekasz na wypychanie / publikowanie kodu, tym trudniej jest go wdrożyć i tym więcej problemów napotkasz. Otrzymasz również informacje zwrotne na temat swoich wkładów znacznie szybciej:

• czy oni psują kompilację?
• czy powielasz wysiłki innego członka zespołu?
• robisz coś nieprawidłowego?
• czy ludzie czekają na rzeczy od ciebie?

Małe zmiany są o wiele łatwiejsze do zarządzania.

Warto również zauważyć różnicę między różnymi systemami kontroli wersji. Niektóre, takie jak Git (dystrybuowane), pozwalają lokalnie zatwierdzać i kontrolować całą historię, pchając tylko wtedy, gdy jesteś gotowy do opublikowania. Inne, takie jak SVN (scentralizowane), połączą dwa kroki, przez co małe zatwierdzenia będą bardzo nieefektywne.

Nie zapominaj, że twoje zobowiązania zasadniczo zmieniają dokumentację. Kiedy coś pójdzie nie tak, z przyjemnością będziesz mieć więcej historii niż jej za mało. Jedno zatwierdzenie tygodniowej pracy wydaje mi się bezużyteczne. Skończyło się na tym, że czytałem każdą zmienioną linię kodu zamiast podsumowania każdego logicznego fragmentu.

Myślę, że większość odpowiedzi tutaj pomija jeden z głównych punktów oświadczenia Martina Fowlersa. Jest to związane z ciągłą integracją . Kod, który nie jest zalogowany (wypchnięty / opublikowany / scalony) do głównej linii nie jest testowany.

Nie należy tego odczytywać jako zachęty do zatwierdzenia dowolnego kodu, który masz na komputerze lokalnym, ilekroć nadejdzie czas opuszczenia biura. Jak wskazało kilka innych tutaj, które byłyby złe, zepsułyby kompilację i spowodowałyby niestabilną linię główną.

Zachęcamy jednak do dokonywania zmian małymi krokami, które można wprowadzić do głównej linii bez powodowania problemów. To zachęca do ewolucji kodu zamiast rozrywania go na części i przepisywania.

Co jest dobrego w tym sposobie pracy?

1. Brak popełnienia dużych fragmentów kodu lub rewolucyjnych zmian zmniejsza ryzyko przerwania kompilacji.
2. Jeśli twoje zatwierdzenie psuje kompilację, dość proste jest zidentyfikowanie problemów, przywrócenie go, a następnie szybkie zatwierdzenie poprawionej wersji.
3. Upewniając się, że wszystkie testy działają przy każdej drobnej zmianie w kodzie, gwarantujesz, że nie wprowadzisz subtelnych błędów lub regresji, które mogą wynikać z rozrastania się kodu poza schematem ciągłej integracji.

Oczywiście nie wszystkie zmiany nadają się do tego podejścia. Jak zauważyli inni, żadna reguła nie jest absolutna. Jednak w przypadku zmian, które powinny pozostać poza linią główną przez długi czas, należy ustawić alternatywną linię główną z własnym schematem ciągłej integracji i stosować takie samo podejście do tego. Dzięki dzisiejszym rozproszonym VCS jest to dość łatwa rzecz.

Argumenty za odprawą każdego dnia:

• Kod jest przechowywany i zabezpieczony przed awarią dysku twardego
• Aktywność można zapisać w notatkach zatwierdzeń ( co zrobiłem w czwartek ...? )
• Integracja z istniejącą bazą kodu odbywa się wcześniej i w mniejszych porcjach, miejmy nadzieję, że wcześniej zidentyfikujemy konflikty lub scalimy problemy
• Twój zespół ma widoczność tego, nad czym pracowałeś
• Twoi koledzy mogą szybciej pracować z Twoimi interfejsami, dając im więcej czasu na integrację z twoim „dużym złożonym bitem kodu”
• Twój kod zostanie przetestowany w świecie rzeczywistym wcześniej, lub przynajmniej będzie wykorzystywany w większym stopniu, niż go dasz, co doprowadzi do wcześniejszej identyfikacji błędów lub pominięć.

Argumenty przeciwko odprawianiu każdego dnia:

• Nie muszę lub nie chcę
• Nie wyczyściłem jeszcze mojego kodu, to bałagan
• Nie mam czasu

Nie sądzę, aby istniał jakiś dobry powód do odprawy mniej niż codziennie oprócz lenistwa lub dezorganizacji. Nie ma nic gorszego niż to, że kod działający w środowisku programistycznym nie pasuje do kodu w gałęzi programistycznej, ponieważ ktoś „jeszcze nie skończył”, a zatem nie zalogował się.

Chciałbym się mylić w tej sprawie, więc proszę o podanie uzasadnionego argumentu przeciwko codziennej odprawie.

Jeśli masz na myśli „zatwierdzenie” jako „scalenie w linię główną”, zdecydowanie nie powinieneś robić tego codziennie w projekcie oprogramowania, który jest udostępniany klientom. Powinieneś scalać zmiany, które zostały wykonane i przetestowane, aby główna linia zawsze działała i była dostępna, a nie w stanie zepsutym z częściowo ukończonymi funkcjami.

Jednak luksus pracy z dzisiejszą rozproszoną kontrolą wersji polega na tym, że możesz zarówno utrzymać stabilność linii głównej, jak i jednocześnie to robić git/hg/whatever commit każdym razem, gdy czujesz, że chcesz zachować stan rzeczy. Robię to raz na kilka godzin i zdecydowanie pod koniec każdego dnia.

Dzięki DVCS możesz publikować swoje prace, współpracować z innymi w swoim zespole i aktualizować je o zmiany w głównej gałęzi. Możesz to wszystko zrobić bez narażania stabilności kodu, na którym polegają Twoi klienci i / lub inne zespoły.

W czasach, gdy Subversion było najnowszą technologią i nie było sposobu, aby rozwidlać i łączyć gałęzie cech bez ekstremalnego bólu, posiadanie linii głównej, w której kilka różnych funkcji było budowanych jednocześnie, mogłoby być najlepszym podejściem. Ale ta przewaga nie wykracza poza 2010 rok.

W Team Foundation Server możesz „odłożyć”, co nie jest tym samym, co odprawa, ale po prostu tworzy kopię zapasową kodu, aby w przypadku śmierci komputera nie utracić zmian.

Widziałem także domy oprogramowania, które mają „linię programistyczną” i „linię główną”. Deweloperzy mogą swobodnie zameldować się w linii programisty, kiedy tylko uznają to za stosowne, i tylko lider zespołu ma dostęp do linii głównej, więc są oni odpowiedzialni za kopiowanie kodu z dewelopera na główny, gdy jest on gotowy do produkcji.