it-swarm-eu.dev

Jaké jsou dobré postupy před kontrolou ve zdrojovém kódu?

Můj tým používá k řízení zdroje Team Foundation Server a dnes jsem opravil některé chyby a aplikaci na testování kouře, než jsem ji zkontroloval, ale zapomněl jsem přidat nějaký kód. (Tento kód udělal UI trochu podivné.)

Chci vědět, jaké osvědčené postupy existují, než zkontroluji kód - nechci znovu dělat takovou chybu.

47
Anonymous

Jedna věc, kterou jsem si zvykl dělat, je vždy se dívat na rozdíly všech souborů, které se chystám zkontrolovat, těsně předtím, než je zkontroluji.

149
crudcore

Nikdy byste se neměli přihlásit k odhlášenému kódu. Pokud máte kód, který musí před nahlášením komentovat, děláte to špatně.

Pokud jde o pravidla:

  1. Získejte nejnovější informace
  2. Opravte konflikty sloučení
  3. Stavět

    3.1 Opravit chyby sestavení

  4. Spusťte testy

    4.1 Opravte přerušené testy

  5. Přejít na 1 (dokud není nic nového)

Zkontrolujte, až jsou všechny kroky dokončeny.

Viz taneční check-in .


Další dobré postupy:

  • Zkontrolujte seznam souborů a zkontrolujte, zda se jedná o očekávané soubory.
  • Zkontrolujte změny pro každý soubor (odstraní/doplní/rozšíří)
63
Oded

Nesnažím se zde být příliš mnoho kalhotek, ale předpoklad v této otázce (a všechny kromě jedné z odpovědí) se většinou týká Centralizovaných VCS, jako jsou TFS, SVN, Perforce atd.
Dost fér, to je to, co OP používá.

Na druhou stranu však při používání DVCS (jako Mercurial a Git) byste obvykle neměli čekat na kontrolu a většina věcí uvedených v odpovědích - jako jsou rozdíly, aktualizace, sloučení atd. - není nutná. . Dokonce i věci jako recenze kódu a testy jsou lepší dělat po checkin (i když možná před tlačením, záleží ...)
Jedinou výjimkou, kterou jsem zde viděl (zatím), je přidružení k pracovní položce. Samozřejmě, že komentář k checkin je také dobrý ...

20
AviD

Tři věci, které jsem neviděl v jiných odpovědích:

Zahrnout nové soubory

  • Hledejte nové soubory, které nejsou součástí vašeho seznamu změn
  • Může být specifický pro SCM, jako je Perforce - musíte mu říct všechno, co je ve vaší změně.

Vrátit nezměněné soubory

  • Nesnáším, když se dívám na změny ostatních lidí a existuje seznam změn s devíti soubory, ale pouze tři z nich byly upraveny.
  • Také vracím soubory s mezerami nebo jinak bezvýznamnými změnami.

Zkontrolujte odeslané potvrzení

  • Ujistěte se, že sestavení zůstane zelené i po potvrzení.
  • Měl jsem druhý stroj, který bych synchronizoval, stavěl a běžel po splnění svých závazků, takže kdyby se něco pokazilo, mohl bych snadno skočit a opravit to.

Když používám Git, dvě věci:

Atomové závazky:

  • Pouze proveďte jednotlivé funkční změny pro potvrzení.
  • Dělejte co nejmenší závazky. Usnadněte jim opravu, vrácení a pochopení.
  • Používám git add --patch v případě potřeby rozdělte moji změnu na více částí.

Pohled se při sumarizaci liší

  • Vždy se přihlašuji pomocí git commit --verbose, abych viděl rozdíl své změny, když píšu do své potvrzovací zprávy. (Nebo použiju svůj záplatovaný git-vim , abych ukázal rozdíl.)
  • Díky tomu je mnohem snazší projít vaše změny a popsat celou revizi. V této fázi občas zachytím nechtěné změny. (Popis vaší změny vám pomůže přemýšlet o tom.)
8
idbrii

Vyhledávejte a nahrazujte prokletí slova ;-)

7
Throwback1986

Několik položek „osvědčených postupů“, které uplatňuji na serverech svého týmu, je docela vpřed. Nejprve byste se měli před příjezdem vždy aktualizovat a spustit místní sestavení, abyste se ujistili, že nikdo jiný nekontroloval nic, s čím by se váš kód střetl. Dále se postarejte o všechny konflikty kódu na místním počítači, nikoli na serveru. Jakmile bude váš kód s nejnovějším staženým kódem potvrzen, že bude správně budovat a pracovat, jste připraveni na další krok. Spusťte automatizované testy a poté začněte s registrací, abyste se ujistili, že stále fungují správně. Pak se jen ujistěte, že se znovu aktualizujete.

Jako správce TFS je možné vynutit komentář ke všem nahlášením. Doporučuji pro vaši práci vždy uvádět komentáře k nahlášení, bez ohledu na to, zda jsou vynuceny nebo ne. Pokud máte možnost tak učinit, vynutit si to. Ujistěte se, že komentáře jsou alespoň obecným shrnutím toho, co jste změnili od poslední kontroly vašeho kódu. Pokud se tedy něco pokazí, můžete se podívat na odhlášení a zhruba vidět, co bylo se změnil v této check-in. To usnadňuje ladění rozbitého sestavení.

Máte-li navíc oprávnění správce TFS, vynucujte postupné sestavování přihlašovacích údajů (abyste se ujistili, že všichni ostatní okamžitě vědí, pokud jejich check-in něco poruší), a můžete server nastavit tak, aby provedl gated check-in ( pokud zaškrtnutý kód zlomí sestavení, server ji odmítne), nebo můžete jednoduše nechat vytvořit chybu a přiřadit ji komukoli, kdo sestavení zlomil.

Existuje několik dalších možností, které můžete zapnout nebo vypnout, aby se vše udržovalo v pořádku, nebo navrhnout svému TFS-Adminovi, aby se zapnul a udržoval věci hezké a čisté ... ale jsou do velké míry preferovány

7
guildsbounty

Pokud se přihlašujete z Windows, zkontrolujte, zda váš kód nemá tyto neviditelné ^ M znaky - editory v UNIXu často uvádějí příčiny chyb/varování.

Zkuste také nahradit karty - různí uživatelé nakonec uvidí tabstops odlišně, některé se 4 mezerami, jiné 8 a ne dobré pro čitelnost kódu.

Nejlepší přístup IMHO je nechat předdefinovaný skript zkontrolovat svůj kód podle pokynů pro kódování vaší organizace. Spousta systémů řízení zdrojů má tuto funkci.

4
Fanatic23

V naší společnosti používáme recenze na check-in. Ty nemusí být podrobně popsány, ale pouhým ukázáním rozdílů ve vašem seznamu změn a jejich promluvením se někdy zvýrazní liché překlepy, které jste při testování zmeškali.

Náš server pro řízení zdroje vám nedovolí přihlášení, pokud si v komentářích neuvedete jméno recenzenta (ve formě! Iniciály, např.! BW, pokud si to Bruce Wayne prohlédl). Recenzent dostane e-mail s poznámkou, že jim pomohl zkontrolovat. To je otevřené zjevnému vykořisťování, ale zdá se, že funguje docela dobře.

4
tenpn

Kdykoli je to možné, ráda jsem přiřadila check-in k pracovní položce. To vám poskytuje některé kontextové informace o tom, proč se to změnilo, nejen co se změnilo. TFS má docela slušný systém sledování pracovních položek, takže je to docela triviální dělat v době check-in.

(to je kromě kontroly rozdílů mých změn)

4
mpeterson

Jedna malá věc, kterou dělám, je nekontrolovat soubory, které se opravdu nezměnily. Tyto soubory mohly být neúmyslně upraveny nebo se mohly podílet na refaktorováních, které byly buď vráceny zpět, nebo byly jinak nataženy.

Tímto způsobem vaše changeset (spojený s pracovní položkou) obsahuje přesně soubory potřebné k uspokojení pracovní položky.

3
John Saunders

Chcete-li zde spojit všechny odpovědi a poskytnout úplný kontrolní seznam

  1. [check in/check out] neměli byste se přímo přihlásit ke streamu, na kterém pracují ostatní. Měli byste mít strategii streamu: např. na vývojáře proud, ve kterém se můžete nezávisle nahlásit a odhlásit, aniž byste obtěžovali ostatní: vaše práce bude v bezpečí, ale ve vašem vlastním vývojovém toku tak [pouze ve vašem vlastním vývojovém proudu]. S každou změnou se přiřadíte ke záznamu změn, takže vaše změny jsou atomové oproti té změně, která se nazývá sada změn (takže můžete distribuovat jednotlivé rfc/chyby atd. ... aniž byste museli dodávat „všechno“).

  2. [pak rebase pomocí vašeho týmového streamu] to znamená, že dostanete změny od ostatních ve svém vlastním streamu. Během této operace můžete vidět v dialogu sloučení všechny „diffy“ a procházet jimi nebo ... pokud existují tisíce a/nebo nepoužíváte kód, ale také např. datové modely/projekty siebel atd. ... spoléhají na netriviální fúze, triviální automaty a triviální manuální fúze, poslední kategorie obsahuje ty obtížné. Nezapomeňte, že stále pracujete ve svém vlastním streamu.

  3. [kompletní rebase] Pokud je vše v pořádku, zkontrolujte všechny změny, které jste právě získali z týmového proudu: váš vlastní stream je nyní aktuální

  4. [doručit] nyní doručte svou práci do týmového proudu. POKUD nechcete doručit vše, co si můžete vybrat např. 1 konkrétní RFC s vyřešenými specifickými verzemi souborů nebo sadou RFC/defektů.

  5. [test delivery] mělo by to být v pořádku, ale protože existuje šance, že někdo mezitím dodal změny také: můžete vyzkoušet, zda vaše práce pracuje s nejnovějšími změnami v týmovém proudu. Se stejnými slučovacími dialogy zobrazujícími rozdíly.

  6. [kompletní dodávka] dokončete dodávku a vaše práce je nyní v týmovém proudu.

Aby to bylo složitější: Protože stále existuje šance, že dílo, které jste dodali = ok, ale již pracujete na další verzi, měli byste základní čáru vždy po doručení a uveďte, kterou základní linii je ta, která je preferována pro ostatní uživatele, aby se odrazili od . Tím je zajištěno, že ostatní vývojáři dostanou doporučenou verzi a ne nejnovější verzi ve streamu (pokud pracujete v tomto scénáři). To je také trojitá kontrola, takže i když nejnovější verze v týmovém proudu jsou „špatné“, stále to nejsou ty, na které se ostatní odkazují nebo se na ně dívají, a správce konfigurace může než sloučit předchozí verzi s další verzí, aby se vrátil zpět vaše doručení.

  • odpověď z histumness se stane dvakrát: v kroku 2 a 6
  • odpověď Oded na check-in dance: idem, ale další vrstva doručení a rebase při check in/check out, abyste se ujistili, že pracujete izolovaně a chyby lze snadno snadno odstranit i v pozdějších fázích
  • odpověď z odpovědi guildsbounty: získat nejnovější je krok 2. Pro sestavení: opravdu záleží, jestli máte sestavení ... v mém světě máte vstupy z datových modelů, dokumentů Wordu, listů požadavků, konfiguračních dat z informatiky, siebel, atd .., a ano, také Java kód, .net kód atd. ..., že by se všichni měli prolínat dohromady. Takže zde není žádné „sestavení“, ale více integrace vyšší v závislosti na tom, zda že jeden např. sestavený z vašeho „kódu“ se integruje do všech ostatních věcí, protože si nemůžete být jisti, zda se jedná o integrační věci a v závislosti na jejich testovacím prostředí je možné kompilovat věci, nebo při vyšších dodávkách další sestavení, protože potřebuje něco od jiného týmu.
  • odpověď guildsbounty na komentování a požadovaná: Myslím, že každé prostředí, ve kterém nemáte integraci VERSIONS a změn v sadách změn (a typu: defekty, RFC, hotfi) není zralé. Myslím, že jeho chaos, pokud nemůžete např. automatizujte poznámky k vydání s množstvím odeslaných chyb a rfcs, na které lze kliknout přesnými verzemi, kterých se dotýká (protože např. verze 1 a verze 3 hello.c by mohla být velmi dobře doručena, ale verze 2 by neměla být doručena, protože tyto věci tam by byla část pozdějšího vydání, ale někteří noob ji již uvedli) (takže to znamená ruční rozhodnutí, pokud chcete také vyjmout verzi 3 z hello.c ALE VYTVOŘENÍ z verze 3 znamená, že musíte také vyjmout všechny jiná verze, která se dotkla toho RFC/defektu, takže musíte být schopni snadno a rychle pomocí nástroje, abyste odstranili celou věc) (i když více vývojářů pracovalo na částech stejného RFC), ale alespoň se musíte rozhodnout na to atd ...). Extra dokumentace je vždy po ruce, ale přidružením sad změn získáte celý kruh: verze <- sada změn <- pracovní položky <- lístek/rfc/defekt <- požadavek. Význam: víte, jaké požadavky jsou plně nebo úplně splněny: jeden požadavek obsahuje více RFC nebo chyb nebo cokoli jiného. RFC má více pracovních položek pro více osob. tato pracovní položka odpovídá sadě změn, která existuje ze sady verzí (např. verze 1 a 3 hello.c v integračním proudu, které NENÍ samozřejmě verze 1,2,3,4,5 ve vývojovém toku této verze) 3 v integračním proudu odpovídá) (tedy strom verzí a nástroje, které s ním pracují)
  • komentář od luis.espinal: dont break build je dvakrát zkontrolován v rebase a dodá stále ... existují vyšší dodávky pro 'manažery release a build meisters', kteří by měli vidět změny a základní linie jako jejich informace. „Nikdy nepracujte přímo na hlavní větvi“ ano, struktura toku může být velká nebo jednoduchá, ale v podstatě: vývojáři mají svůj vlastní proud, dodávají týmovému proudu, který doručuje uvolňovací proud. -> tak, aby dodávky ze všech týmů (např. dokumentační tým, tým požadavků, vývojové týmy, testovací tým) byly ve svých týmových proudech a správce verzí nebo správce konfigurace popadl základní linie, které by měly jít ve verzi, a tak zajišťuje, že správná dokumentace se správnými zkušebními verzemi dokumenty/výstupy se správným požadavkem se správnými verzemi kódu jsou všechny v řadě pro vydání.

Ve svém příkladu uvedete, že jste zapomněli kód okomentovat. Stávají se chyby. Systém správy konfigurace kolem něj by se o to měl postarat. Může to být opravdu to, že přicházejí tisíce změn a „staví se“ a „integrace“ se odehrávají v hierarchii proudů na různých serverech zřetězených a zpracovaných v čase. Takže i když po 5 měsících bude váš komentářový kód testován na integračním serveru, protože váš kód vyžaduje integraci s jiným kódem a systémy, mělo by být stále možné atomicky vzít vaši sadu změn a stále pokračovat. Nejlepší postup je tedy více či méně na vyšší úrovni. O celkový návrh toků správy konfigurace by se to mělo postarat. Pro jednotlivé vývojáře je nejlepší praxí ověření/jednotkový test. Ale z celkového pohledu na to, aby to fungovalo, nejlepší praxí je sledovat systém a vždy poskytovat, že meta informace o souvisejících sadách změn pro kluky později v řetězci.

3
edelwater

Některé z následujících platí více než jiné (nebo v různých formách) v závislosti na vašem SCM, takže zde platí:

  1. Neporušujte sestavení - zkontrolujte pouze kompilovaný kód.
  2. Komentujte svá přihlášení (a možná i vaše odhlašování, pokud vám SCM tuto možnost dá.)
  3. Nenechávejte věci dlouho nezaškrtnuté.
  4. Check in často (několikrát denně, pokud je to možné).
  5. Označte smysluplně.
  6. Označujte pravidelně.
  7. Nikdy nepracujte přímo na hlavní větvi.
  8. Každé uvolnění do výroby musí mít svůj vlastní štítek (a pokud je to možné, odbočte od hlavní větve pouze pro čtení). Pokud je to možné, udělejte to samé pro zkušební verze UAT/Integration/Pre-production.
  9. Měli byste být schopni stavět přesně to, co je na produkci, z toho, co je ve vašem SCM a ze štítku.

POZNÁMKA : některé z výše uvedených položek se zdají docela zřejmé, ale nevěřili byste tomu, kolik lidí ve skutečnosti pracuje v hlavní větvi nebo nejprve změní produkci - a pak ručně vytvořte delty, které se budou řídit verzí ... přímo na hlavní větvi ... a se štítky. Sladká jako kvašená žluč ve směsi s nemytou šťávou z podpaží ... jo, takhle.

2
luis.espinal

Mějte osobní kontrolní seznam. Začněte s prázdným, když se pokazíte, u záznamu. Když se stane druhou přirozeností, odeberte ji ze seznamu.

Spusťte testy. Pokud se jim podaří, zkontrolujte to. Pokud se pokazíte a některá věc projde testy, napište test.

2
ctrl-alt-delor

Vždy, vždy --- vždy, zkontrolujte, zda jakékoli změny, které jste provedli, nepřestanou stavět. Zvláště drobné změny, které se mohou zdát triviální.

Jednou jsem udělal velmi malou změnu, o které jsem si nemyslel, že by způsobil problémy těsně předtím, než jsem odešel pracovat na víkend. Jistě, tato malá změna stavbu narušila a pro náš projekt nebyly provedeny žádné noční zkušební jízdy. Šéf Q&A z toho nebyl příliš šťastný, a správně.

1
gablin

Proveďte testy jednotek, na kterých jste pilně pracovali. Zelená je dobrá.

1
Naftuli Kay

Ujistěte se, že je váš kód správně naformátován (např. Pro Javu: vyberte kód a stiskněte Ctrl-Shift-F v Eclipse). Ale pozor na celý dokument.

1
Rune Aamodt

Děláme následující ...

  1. Test - Chceme se ujistit, že to funguje. Přinejmenším chceme vědět, že to nic neporuší.

  2. Kontrola kódu, nebo alespoň kontrola s kamarádem - Je to skvělý způsob, jak zajistit, aby se znalosti šířily a aby lidé byli neustále aktuální. Pomáhá také chystat chyby před kontrolou věcí.

  3. Odeslat předběžné oznámení - Skupině před odesláním bude zasláno předběžné oznámení. Účelem není pouze informovat ostatní o tom, které soubory nebo oblasti se mění, ale dává jim také heads up (pokud se rozhodnou upozornit) v případě, že se očekává, že tyto změny ovlivní.

  4. Několik hodin po odeslání předběžného oznámení se provede přihlášení a skupina je informována e-mailem. Každý ve skupině může vědět, kdy se provádí konkrétní práce na chybě nebo funkci.

  5. Kopie oznámení o checkin je vložena do záznamu opravy spojené s chybou nebo funkcí. Při prohledávání záznamů zjistíme, že je velmi užitečné mít představu o tom, co tato oprava/funkce znamenala.

1
Sparky

Hledejte části vašich změn, které mohou jít jako samostatné jednotky.

V době, kdy mám funkční opravu nebo vylepšení kódu, často dochází k několika změnám. Některé z nich jsou specifické pro změnu chování, kterou jdu; jiní jsou refactorings jsem udělal, aby tato změna čistší.

Dávám přednost kontrole každého refaktoringu samostatně s vlastním popisem změny, jako je tento:

REFACTORING: Přejmenujte X na Y

X dávalo smysl dříve, protože ... ale teď by to mělo být Y. Souvisí to s prací pro vydání # 9.

Poté, co je zkontrolováno každé dobré refaktorování, je konečná změna chování často triviální.

Také některé změny ovlivňují mnoho řádků kódu, ale nejsou příliš zajímavé, zatímco jiné změny jsou velmi lokalizované, ale mají důležitý dopad. Pokud jsou tyto změny zkontrolovány společně, může být obtížné přečíst rozdíly. Takže je držím odděleně.

Později, když si někdo přečte historii změn, je zřejmé, jak se věci dostaly do současného stavu a proč tomu tak je. Je také triviální zrušit změnu mého chování, protože není spletena s tunami dalších úprav.

1
Jay Bazuzi

Pro svou práci si nechávám místní repo hg.

  • Kdykoli něco zkontroluji, podívám se na rozdíl a ujistím se, že všechny změny jsou přijatelné.
  • Snažím se poznamenat klíčovou vlastnost checkin.
  • Snažím se udržet každou velikost odevzdání na jednu klíčovou funkci.

Netvrdím, že jsou to nejlepší, ale pracují pro mě.

0
Paul Nathan

Udělejte, co byste udělali, když vrátíte něco, co jste si od někoho půjčili. Ujistěte se, že je čistý a v dobrém stavu. Pokud jste udělali nepořádek, nezapomeňte vyčistit před vrácením kódu jeho vlastníkovi (ve většině případů vašemu zaměstnavateli).

0
Jason

Když píšu kód, o kterém vím, že nemá být zkontrolován, přidám před něj řádek obsahující „// TEMP:“ a poté za něj „// END TEMP“. To spolu s provedením rozdílu před přihlášením slibuje, že tento kód omylem nekontroluji.

0
user17815

Důkladně otestujte vše, co jste přidali nebo změnili. Vyzkoušejte každý možný případ, který můžete napadnout. Nenechávejte testování na QA. Kdybych měl sendvič pokaždé, když jsem udělal nějakou drobnou změnu, a pak jsem vyzkoušel několik testovacích případů, abych byl na bezpečné straně, a okamžitě jsem viděl problémy, měl bych spoustu sendvičů. Obvykle si říkám nahlas: „Jsem opravdu rád, že jsem to zkusil ...“

Říkáte, že uživatelské rozhraní se stalo po vaší změně podivné. Pokud byste program pouze spustili a podívali se na uživatelské rozhraní před přihlášením, všimli byste si problému?

0
Ken