Jakie są dobre praktyki przed wpisaniem kodu źródłowego? [Zamknięte]

Mój zespół używa Team Foundation Server do kontroli źródła, a dziś naprawiłem kilka błędów i aplikacji do testowania dymu, zanim go zameldowałem, ale zapomniałem skomentować jakiś kod. (Ten kod spowodował, że interfejs użytkownika był nieco dziwny.)

Chcę sprawdzić, jakie są dobre praktyki przed wpisaniem kodu - nie chcę ponownie popełniać tego rodzaju błędu.

Jedną z rzeczy, które mam w zwyczaju robić, to zawsze patrzeć na różnice w każdym pliku, który zamierzam sprawdzić, tuż przed ich zarejestrowaniem.

Nigdy nie należy zameldować skomentowanego kodu. Jeśli masz kod, który wymaga komentarza przed zameldowaniem, robisz to źle.

Co do zasad:

1. Uzyskać najnowsze
2. Napraw konflikty scalania

3. Budować

   3.1 Napraw błędy kompilacji

4. Uruchom testy

   4.1 Napraw zepsute testy

5. Idź do 1 (dopóki nie będzie nic nowego do zdobycia)

Zameldowanie tylko po zakończeniu wszystkich kroków.

Zobacz odprawę taneczną .

Inne dobre praktyki:

• Przejrzyj listę plików do odprawy, aby upewnić się, że są to oczekiwane pliki.
• Przejrzyj zmiany dla każdego pliku (usuwa / uzupełnienia / różnice)

Nie staram się być tutaj zbyt dużym spodniowcem, ale założenie w tym pytaniu (i wszystkie oprócz jednej odpowiedzi) dotyczy głównie Scentralizowanego VCS, takiego jak TFS, SVN, Perforce itp.
Właściwie to jest to, co OP używa.

Z drugiej jednak strony, gdy używasz DVCS (takich jak Mercurial i Git), zwykle nie powinieneś czekać na checkin, a większość rzeczy wymienionych w odpowiedziach - takich jak diffs, get latest, merge itp. - nie są konieczne . Nawet sprawdzanie kodu i testy są lepsze po zameldowaniu (choć być może przed wypchnięciem, w zależności od ...)
Jedynym wyjątkiem, który widziałem tutaj (jak dotąd), jest skojarzenie z elementem pracy. Oczywiście komentowanie meldowania jest również dobre ...

Trzy rzeczy, których nie widziałem w innych odpowiedziach:

Dołącz nowe pliki

• Poszukaj nowych plików, które nie są częścią Twojej listy zmian
• Może być specyficzny dla SCM, takich jak Perforce - musisz powiedzieć to wszystko, co jest w twojej zmianie.

Cofnij niezmienione pliki

• Nienawidzę, gdy patrzę na zmiany innych ludzi i istnieje lista zmian z dziewięcioma plikami, ale tylko trzy z nich zostały zmodyfikowane.
• Przywracam również pliki ze spacjami lub innymi nieistotnymi zmianami.

Sprawdź przesłane zatwierdzenie

• Upewnij się, że kompilacja pozostanie zielona po zatwierdzeniu.
• Kiedyś miałem drugą maszynę, którą synchronizowałem, budowałem i działałem zgodnie z moimi zatwierdzeniami, więc jeśli coś pójdzie nie tak, mogę łatwo wskoczyć i naprawić.

Dwie rzeczy, kiedy korzystam z Git:

Zatwierdzenia atomowe:

• Wprowadzaj tylko indywidualne zmiany funkcjonalne dla zatwierdzenia.
• Dokonaj zatwierdzeń tak małych, jak to możliwe. Ułatw im łatanie, przywracanie i zrozumienie.
• Jeśli to git add --patchkonieczne, dzielę swoją zmianę na wiele części.

Zobacz różnice podczas podsumowania

• Zawsze się melduję, git commit --verboseaby zobaczyć różnicę mojej zmiany podczas pisania wiadomości zatwierdzenia. (Lub używam mojego załatanego git-vima, aby pokazać różnicę.)
• To znacznie ułatwia przejście przez zmiany i opisanie całego zatwierdzenia. Czasami łapię niezamierzone zmiany na tym etapie. (Opisanie zmiany pomaga ci się nad tym zastanowić).

Kilka „dobrych praktyk”, które egzekwuję na serwerach mojego zespołu, jest całkiem prostych. Po pierwsze, zanim się zalogujesz, zawsze powinieneś pobrać najnowszą wersję i uruchomić lokalną kompilację, aby upewnić się, że nikt inny nie zaznaczył niczego, z czym kod się koliduje. Ponadto rozwiąż wszelkie konflikty kodów na komputerze lokalnym, a nie na serwerze. Po potwierdzeniu, że Twój kod, z najnowszym pobranym kodem, został zbudowany i działa poprawnie, możesz przejść do następnego kroku. Uruchom wszelkie automatyczne testy, a następnie rozpocznij odprawę, aby upewnić się, że nadal działają poprawnie. Następnie, dla pewności, uzyskaj najnowsze informacje.

Administrator TFS może wymuszać komentowanie wszystkich meldowań. Polecam zawsze umieszczać komentarze do odprawy dotyczące Twojej pracy, niezależnie od tego, czy jest ona egzekwowana czy nie. Jeśli masz taką możliwość, wymusz ją. Upewnij się, że komentarze są co najmniej ogólnym podsumowaniem tego, co zmieniłeś od czasu ostatniego wpisania kodu. W ten sposób, jeśli coś pójdzie nie tak, możesz przejrzeć zameldowania i z grubsza sprawdzić, co było zmieniony w trakcie odprawy. Ułatwia to debugowanie uszkodzonej wersji.

Ponadto, jeśli masz uprawnienia administratora TFS, wymuszaj stopniowe kompilowanie podczas meldowań (aby upewnić się, że wszyscy inni od razu wiedzą, czy ich zameldowanie coś zepsuje), a serwer można skonfigurować tak, aby przeprowadzał odprawę bramkową ( jeśli zaznaczony kod psuje kompilację, serwer ją odrzuca), lub możesz po prostu stworzyć błąd i przypisać go każdemu, kto złamał kompilację.

Istnieje kilka innych opcji, które możesz włączyć lub wyłączyć, aby utrzymać wszystko w porządku, lub zasugerować swojemu administratorowi TFS, aby włączał, aby utrzymać porządek i porządek ... ale są one w dużej mierze preferowane

Wyszukaj i zamień przekleństwa ;-)

Jeśli logujesz się z systemu Windows, sprawdź, czy kod nie ma tych niewidocznych znaków ^ M - edytory w systemie UNIX często podają przyczyny błędów / ostrzeżeń.

Spróbuj także zastąpić tabulatory - różni użytkownicy zobaczą tabstopsy inaczej, niektóre z 4 spacjami, niektóre 8 i nie są dobre dla czytelności kodu.

Najlepsze podejście IMHO polega na tym, aby wstępnie zdefiniowany skrypt sprawdzał kod pod kątem wytycznych kodowania organizacji. Mnóstwo systemów kontroli źródła ma tę funkcjonalność.

W mojej firmie korzystamy z recenzji odpraw. Nie muszą one być szczegółowe, ale po prostu pokazanie komuś różnic w liście zmian i rozmawianie przez nich czasami podkreśla dziwną literówkę, którą przegapiłeś podczas testowania.

Nasz serwer kontroli źródła nie pozwoli ci się zameldować, chyba że w komentarzach podasz nazwisko recenzenta (w formie! Inicjałów, np.! BW, jeśli Bruce Wayne zrobił twoją recenzję). Recenzent otrzymuje wiadomość e-mail z informacją, że pomógł sprawdzić. Jest to otwarte na oczywiste wykorzystanie, ale wydaje się działać całkiem dobrze.

Gdy tylko jest to możliwe, lubię kojarzyć zameldowanie z przedmiotem pracy. Daje to pewne kontekstowe informacje o tym, DLACZEGO to zostało zmienione, a nie tylko CO zostało zmienione. TFS ma dość przyzwoity system śledzenia elementów pracy, więc jest to dość trywialne w momencie odprawy.

(jest to oprócz przeglądu różnic moich zmian)

Jedną małą rzeczą, którą robię, jest nie rejestrowanie plików, które tak naprawdę się nie zmieniły. Pliki te mogły zostać nieumyślnie zmodyfikowane lub mogły być zaangażowane w refaktoryzacje, które zostały wycofane lub w inny sposób zostały wprowadzone w wątpliwość.

W ten sposób Twój zestaw zmian (powiązany z elementem pracy) zawiera dokładnie pliki niezbędne do spełnienia elementu pracy.

Aby połączyć wszystkie odpowiedzi tutaj i podać pełną listę kontrolną

1. [meldowanie / wymeldowywanie] nie powinieneś meldować się bezpośrednio w strumieniu, w którym pracują inni. Powinieneś mieć strategię strumieniową: np. dla programistów strumień, w którym możesz się meldować i wymeldować niezależnie bez przeszkadzania innym: Twoja praca będzie bądź bezpieczny, ale we własnym strumieniu programistycznym, więc [tylko we własnym strumieniu programistycznym]. Z każdą odprawą kojarzysz ją z zapisem zmian, aby zmiany były atomowe względem tej zmiany zwanej zestawem zmian (abyś mógł dystrybuować poszczególne błędy / błędy itp. Bez konieczności dostarczania „wszystkiego”).

2. [następnie bazuj na strumieniu zespołu] oznacza to, że otrzymujesz zmiany od innych we własnym strumieniu. Podczas tej operacji można zobaczyć w oknie dialogowym scalania wszystkie „różnice” i przejść przez nie lub ... jeśli są tysiące i / lub nie używasz kodu, ale także np. Modele danych / projekty siebel itp. Polegają na połączenia nietrywialne, trywialno-automatyczne i trywialne łączenia ręczne, ostatnia kategoria zawiera te trudne. Pamiętaj, że nadal pracujesz we własnym strumieniu.

3. [pełna rebase] Jeśli wszystko jest w porządku, sprawdź wszystkie zmiany, które właśnie dostałeś ze strumienia zespołu: Twój własny strumień jest teraz aktualny

4. [dostarcz] dostarcz teraz swoją pracę do strumienia zespołu. JEŻELI nie chcesz dostarczyć wszystkiego, możesz również wybrać np. 1 konkretny RFC z konkretnymi wersjami plików lub zestawem RFC / usuniętych wad.

5. [test dostarczony] powinno pójść dobrze, ale ponieważ istnieje szansa, że ​​ktoś w międzyczasie dostarczył również zmiany: możesz sprawdzić, czy Twoja praca działa z najnowszymi zmianami w strumieniu zespołu. Z tymi samymi oknami dialogowymi scalania pokazującymi różnice.

6. [zupełne dostarczenie] ukończ swoje dostarczenie, a Twoja praca jest teraz w strumieniu zespołu.

Aby uczynić go bardziej złożonym: ponieważ nadal istnieje szansa, że ​​praca, którą wykonałeś = ok ALE pracujesz już nad kolejną wersją, powinieneś zawsze bazować po dostarczeniu i wskazać, która linia jest preferowana dla innych użytkowników . Dzięki temu inni programiści otrzymają zalecaną, a nie najnowszą wersję w strumieniu (jeśli pracujesz w tym scenariuszu). Jest to również Potrójna kontrola, więc nawet jeśli najnowsze wersje w strumieniu zespołu są „złe”, nadal nie są to te, na których inni się bazują lub na które patrzą, a Twój menedżer konfiguracji może następnie połączyć poprzednią wersję z kolejną wersją, aby cofnąć twoja dostawa.

• odpowiedź z historii pojawia się 2 razy: w krokach 2 i 6
• odpowiedź Odeda na temat tańca przy zameldowaniu: idem, ale dodatkowa warstwa dostarczania i bazowania przy zameldowaniu / wymeldowaniu, aby upewnić się, że pracujesz samodzielnie, a błędy można zawsze łatwo usunąć, nawet na późniejszych etapach
• odpowiedź z odpowiedzi na gildię: pobierz najnowszy to krok 2. W przypadku kompilacji: tak naprawdę zależy, czy masz kompilację ... w moim świecie masz dane wejściowe z modeli danych, dokumentów tekstowych, arkuszy wymagań, danych konfiguracyjnych z informatica, siebel, itd., i tak również kod java, .net itp. itd., które powinny się ze sobą łączyć. Tak więc nie ma tutaj tak naprawdę „kompilacji”, ale bardziej integracja wyżej w zależności od tego, czy ta pojedyncza np. Kompilacja z twojego „kodu” integruje się z resztą rzeczy, ponieważ nie możesz być pewien, czy to jest integracja i zależy od w ich środowiskach testowych może być potrzebna kompilacja, a przy wyższych dostawach kolejna kompilacja, ponieważ potrzebuje czegoś od innego zespołu.
• odpowiedź od gildii na komentarz i wymagana: myślę, że każde środowisko, w którym nie masz integracji VERSION i zmian w zestawach zmian (i typ: defekty, RFC, hotfi) nie jest dojrzałe. Myślę, że to chaos, jeśli nie można np. Zautomatyzować informacji o wydaniu z liczbą przesłanych błędów i rfcs, które można kliknąć, aby przejść do dokładnie tych wersji, które zostaną dotknięte (ponieważ np. Wersja 1 i wersja 3 hello.c mogłyby zostać dostarczone, ale wersja 2 nie powinien był zostać dostarczony, ponieważ te rzeczy byłyby częścią późniejszej wersji, ale niektóre noob już to umieściły) (więc oznacza to ręczną decyzję JEŻELI chcesz również wyjąć wersję 3 hello. c ALE usunięcie wersji 3 oznacza, że ​​musisz również usunąć wszystkie inne wersje dotknięte tym RFC / defektem, więc musisz być w stanie łatwo i szybko za pomocą narzędzia do usunięcia całej rzeczy) (nawet jeśli wielu programistów pracowało nad częściami ten sam RFC), ale przynajmniej potrzebujesz różnych rzeczy, aby podjąć decyzję itp.). Dodatkowa dokumentacja jest zawsze przydatna, ale przez powiązanie zestawów zmian otrzymujesz pełne koło: wersja <- zestaw zmian <- elementy pracy <- bilet / rfc / defekt <- wymaganie. Znaczenie: wiesz, które wymagania są w pełni lub całkowicie dostarczone: jedno wymaganie ma wiele RFC lub błędów lub cokolwiek innego. RFC ma wiele elementów pracy dla wielu osób. ten element pracy odpowiada zestawowi zmian, który istnieje w zestawie wersji (np. wersja 1 i 3 hello.c w strumieniu integracji, które są oczywiście NIE w wersji 1,
• komentarz od luis.espinal: nie przełamuj kompilacji jest podwójnie sprawdzany w bazie i dostarcza nadal ... istnieją wyższe dostawy dla „menedżerów wydań i budujących meisterów”, którzy powinni widzieć zestawy zmian i linie bazowe jako informacje. „Nigdy nie pracuj bezpośrednio w głównej gałęzi” tak, struktura strumienia może być duża lub prosta, ale w gruncie rzeczy: programiści mają swój własny strumień, dostarczają go do strumienia zespołu, który dostarcza do strumienia wydania. -> aby dostawy ze wszystkich zespołów (np. zespół dokumentacji, zespół wymagań, zespoły programistyczne,

W swoim przykładzie podajesz, że zapomniałeś skomentować kod. Zdarzają się błędy. System zarządzania konfiguracją wokół niego powinien się tym zająć. Może być tak, że np. Przychodzą tysiące zmian, a „kompilacje” i „integracje” odbywają się w hierarchii strumieni na różnych serwerach połączonych i przetworzonych w czasie. Więc nawet jeśli po 5 miesiącach skomentowany kod zostanie przetestowany na serwerze integracyjnym, ponieważ kod wymaga integracji z innym kodem i systemami, nadal powinno być możliwe atomowe usunięcie zestawu zmian i kontynuowanie. Zatem najlepsza praktyka jest mniej więcej na wyższym poziomie. Powinien się tym zająć ogólny projekt strumieni zarządzania konfiguracją. Dla indywidualnych programistów najlepszą praktyką jest sprawdzanie poprawności / test jednostkowy. Ale od dużego obrazu do „

Niektóre z poniższych mają zastosowanie bardziej niż inne (lub w różnych formach) w zależności od SCM, więc proszę:

1. Nie przerywaj kompilacji - zaznacz tylko kod, który się kompiluje.
2. Skomentuj swoje dane wejściowe (i ewentualnie swoje kasy, jeśli SCM daje ci taką możliwość).
3. Nie trzymaj rzeczy niezaznaczonych przez długi czas.
4. Zamelduj się często (jeśli to możliwe kilka razy dziennie).
5. Znacząco oznacz.
6. Etykietuj regularnie.
7. Nigdy nie pracuj bezpośrednio w głównej gałęzi.
8. Każde wydanie do produkcji musi mieć własną etykietę (i gałąź tylko do odczytu poza główną gałęzią, jeśli to możliwe). Jeśli to możliwe, zrób to samo dla wydań testowych UAT / Integration / Pre-Production.
9. Powinieneś być w stanie zbudować dokładnie to, co jest na produkcji, z tego, co jest w twoim SCM i z etykiety.

UWAGA : niektóre z powyższych elementów wydają się dość oczywiste, ale nie uwierzyłbyś, ile osób faktycznie pracuje w głównej gałęzi lub wprowadza najpierw zmiany w produkcji, a następnie ręcznie tworzy delty, aby przejść do kontroli wersji ... bezpośrednio w głównej gałęzi. .. i z etykietami. Słodka jak sfermentowana żółć zmieszana z niemytym sokiem pod pachą ... tak, tak.

Miej osobistą listę kontrolną. Zacznij od pustego, gdy się zepsujesz, przy wejściu. Kiedy stanie się drugą naturą, usuń go z listy.

Uruchom testy. Jeśli zdadzą, sprawdź. Jeśli coś popsuniesz i coś przejdzie test, napisz test.

Wykonujemy następujące ...

1. Test - chcemy się upewnić, że działa. Przynajmniej chcemy wiedzieć, że to niczego nie psuje.

2. Przegląd kodu lub przynajmniej znajomy sprawdzian - to świetny sposób, aby zapewnić, że wiedza się rozpowszechnia i że ludzie są na bieżąco. Pomaga także wykrywać błędy przed sprawdzeniem.

3. Wyślij powiadomienie z wyprzedzeniem - Powiadomienie z wyprzedzeniem jest wysyłane do grupy przed zameldowaniem. Ma to na celu nie tylko poinformowanie innych, które pliki lub obszary się zmieniają, ale daje im możliwość poinformowania (jeśli zdecydują się to zauważyć) na wypadek, gdyby zmiany te miały na nich wpływ.

4. Kilka godzin po wysłaniu powiadomienia z wyprzedzeniem odbywa się odprawa, a grupa jest informowana za pośrednictwem poczty elektronicznej. Wszyscy w grupie mogą wiedzieć, kiedy zakończy się konkretna praca nad błędem lub funkcją.

5. Kopia powiadomienia o zameldowaniu jest wklejana do rekordu poprawki związanego z błędem lub funkcją. Podczas przeszukiwania rekordów okazuje się, że bardzo przydatne jest wyobrażenie sobie, co pociąga za sobą poprawka / funkcja.

Przeprowadź testy jednostkowe, nad którymi tak pilnie pracujesz. Zieleń jest dobra.

Upewnij się, że kod jest poprawnie sformatowany (np. W Javie: wybierz kod i naciśnij Ctrl-Shift-F w Eclipse). Ale zachowaj ostrożność, robiąc to samo dla całego dokumentu.

Zawsze, zawsze, zawsze sprawdzaj, czy wszelkie wprowadzone zmiany nie psują kompilacji. Szczególnie niewielkie zmiany, które mogą wydawać się trywialne.

Kiedyś dokonałem bardzo drobnej zmiany, która, jak sądzę, nie spowodowałaby żadnych problemów tuż przed odejściem z pracy na weekend. Rzeczywiście, ta niewielka zmiana zepsuła kompilację i nie wykonano nocnych testów dla naszego projektu. Szef Q&A nie był z tego zbyt zadowolony i słusznie.

Poszukaj części zmian, które można wprowadzić jako samodzielne jednostki.

Często, zanim mam działającą poprawkę lub rozszerzenie kodu, jest sporo zmian. Niektóre z nich są specyficzne dla zmiany zachowania, o którą zamierzam; inne to refaktoryzacje, które zrobiłem, aby ta zmiana była czystsza.

Wolę sprawdzać każde refaktoryzowanie osobno, z własnym opisem zmiany, takim jak ten:

REFACTORING: Zmień nazwę X na Y

X miał wcześniej sens, ponieważ ... ale teraz powinien być Y. Jest to związane z pracą nad problemem nr 9.

Następnie, po sprawdzeniu każdego dobrego refaktoryzacji, ostateczna zmiana zachowania jest często banalna.

Ponadto niektóre zmiany wpływają na wiele wierszy kodu, ale nie są bardzo interesujące, podczas gdy inne zmiany są bardzo zlokalizowane, ale mają istotny wpływ. Jeśli te zmiany są rejestrowane razem, odczytanie różnic może być trudne. Więc trzymam je oddzielnie.

Później, gdy ktoś czyta historię zmian, oczywiste jest, jak sprawy potoczyły się do obecnego stanu rzeczy i dlaczego tak jest. Cofnięcie zmiany moich zachowań jest również trywialne, ponieważ nie jest powiązane z mnóstwem innych zmian.

Rób to, co zrobiłbyś, zwracając coś, co pożyczyłeś od kogoś. Upewnij się, że jest czysty i w dobrym stanie. Jeśli zrobiłeś bałagan, pamiętaj o wyczyszczeniu przed zwróceniem kodu jego właścicielowi (w większości przypadków pracodawcy).

Prowadzę lokalne repozytorium hg dla mojej pracy.

• Ilekroć coś sprawdzam, sprawdzam różnicę i upewniam się, że wszystkie zmiany są dopuszczalne.
• Staram się zwrócić uwagę na kluczową cechę zameldowania.
• Staram się, aby każdy rozmiar zatwierdzenia był zgodny z jedną kluczową funkcją.

Nie twierdzę, że są najlepsze, ale działają dla mnie.

Kiedy piszę kod, o którym wiem, że nie powinien być rejestrowany, dodaję wiersz przed nim zawierający „// TEMP:”, a po nim „// END TEMP.”. To, wraz z robieniem różnic przed zalogowaniem się, obiecuje, że przez pomyłkę nie sprawdzę tego kodu.

Dokładnie przetestuj wszystko, co dodałeś lub zmieniłeś. Wypróbuj wszystkie możliwe przypadki, które możesz wymyślić. Nie zostawiaj testów kontroli jakości. Gdybym miał kanapkę za każdym razem, gdy dokonywałem drobnych zmian, a następnie wypróbowałem kilka przypadków testowych, aby być po bezpiecznej stronie i od razu zobaczyłem problemy, zjadłbym dużo kanapek. Zwykle mówię sobie głośno: „Naprawdę się cieszę, że spróbowałem ...”

Mówisz, że interfejs użytkownika stał się dziwny po zmianie. Gdybyś tylko uruchomił program i spojrzał na interfejs użytkownika przed zalogowaniem, czy zauważyłbyś problem?