it-swarm-eu.dev

Jaký je nejúčinnější způsob provedení kontroly kódu?

Nikdy jsem nenašel ideální způsob, jak provádět kontroly kódu, a přesto je často zákazníci vyžadují. Zdá se, že je každý zákazník dělá jiným způsobem a v žádném z nich jsem se nikdy necítil spokojený.

Jaký byl pro vás nejefektivnější způsob kontroly kódu?

Například:

  • Je jedna osoba považována za strážce kvality a kontroluje kód, nebo vlastní tým standard?
  • Prohlížíte kód jako týmové cvičení pomocí projektoru?
  • Děje se to osobně, e-mailem nebo pomocí nástroje?
  • Vyhýbáte se recenzím a používáte věci jako párové programování a vlastnictví kolektivního kódu pro zajištění kvality kódu?
71
Paddyslacker

Při mé práci máme velmi jednoduché pravidlo: změny musí být zkontrolovány alespoň jedním dalším vývojářem před sloučením nebo odevzdáním kufr. V našem případě to znamená, že druhá osoba s vámi fyzicky sedí u vašeho počítače a prochází seznamem změn. Nejedná se o dokonalý systém, ale přesto se výrazně zlepšila kvalita kódu.

Pokud víte, že váš kód bude přezkoumáván, nutí vás to nejprve prohlédnout. Pak se objevilo mnoho problémů. V našem systému musíte recenzentovi vysvětlit, co jste udělali, což opět způsobí, že si všimnete problémů, které jste možná předtím zmeškali. Také pokud něco ve vašem kódu není recenzentovi okamžitě jasné, je to dobrý náznak, že je třeba lepší jméno, komentář nebo refaktoring. A samozřejmě může recenzent také najít problémy. Kromě prohlížení změny si může recenzent také všimnout problémů v blízkém kódu.

Tento systém má dvě hlavní nevýhody. Pokud je změna triviální, nemá smysl ji nechat přezkoumat. Musíme se však bezpodmínečně držet pravidel, abychom zabránili tomu, aby kluzký sklon prohlásil změny za „triviální“, pokud tomu tak není. Na druhou stranu to není velmi dobrý způsob, jak zkontrolovat významné změny v systému nebo přidání velkých nových komponent.

Vyzkoušeli jsme více formálních recenzí dříve, než jeden vývojář pošle e-mailem kód, který má být zkontrolován zbytku týmu, a poté se celý tým spojí a projedná to. Trvalo to hodně času každého, a v důsledku toho byly tyto recenze málo a daleko od sebe a pouze malé procento základny kódu bylo přezkoumáno. „Jedna další osoba kontroluje změny před odevzdáním“ pro nás fungovala mnohem lépe.

32
Dima

Líbí se mi recenze kódu, i když to může být bolest. Důvod, proč se mi líbí, je, že dostávají více očí na kód a jinou perspektivu. Věřím, že i při párovém programování by měl být kód přezkoumán. Je dost snadné pro dva lidi, kteří pracují na stejném kódu, aby společně udělali stejnou chybu, že jiná sada očí nemusí chybět.

Pokud se jedná o skupinu s projektorem, měla by být skutečně přezkoumána jednotlivě před schůzka. Jinak je to jen nepříjemná ztráta času.

Posoudil jsem kód pouze e-mailem a ve skupině. Obecně si nemyslím, že by se měli dělat osobně. Cítíte trochu větší tlak na Rush skrz kód, když se někdo dívá přes rameno. Věřím, že nástroj určený k revizi kódu by byl dobrým přínosem, protože může pomoci s některými běžnými aspekty a měl by usnadnit označování problémových bitů kódu, a to prostřednictvím e-mailu.

Problém s tím, že jedna osoba provádí všechny recenze kódu, je to, že to může být překážkou. S dobře zdokumentovanými a navrženými standardy kódování by nemělo být nutné. V závislosti na prostředí/harmonogramu vydání může být dobré mít někoho jako recenzenta pohotovostního kódu.

Věřím, že vlastnictví kódu je dobrý nápad, protože tato osoba může učinit svou prioritu porozumět tomuto kódu a potenciálně hrát roli správce.

13
George Marian

V SmartBear nevyrábíme pouze nástroj pro kontrolu kód , ale také jej používáme každý den. Je to nezbytná součást našeho vývojového procesu. Prověřujeme každou změnu, která je nahlášena.

Myslím, že je špatný nápad mít jediného kontrolora kódů vrátných z mnoha důvodů. Tato osoba se stává problémovým místem a musí udělat příliš mnoho revizí kódu (jen proto, aby byl projekt v pohybu), aby na to byla skutečně efektivní (60-90 minut najednou je limit účinnosti). Recenze kódů jsou skvělý způsob, jak sdílet nápady a znalosti. Bez ohledu na to, kolik superhvězd je váš vrátný, mohou se učit od ostatních v týmu. Také tím, že každý provede kontrolu kódu, také vytváří prostředí „kolektivního vlastnictví kódu“ - kde lidé cítí, že vlastní kvalitu kódu (nejedná se pouze o QA nebo gatekeeper).

Máme zdarma whitepaper o " Doporučené postupy pro Peer Code Review ", který má 11 tipů pro efektivní kontrolu kódů. Hodně z toho je stejný obsah z knihy, kterou zmínil John ve více destilované podobě.

6
Brandon DuRette

Žádná omluva. Procvičujte si párové programování. Je to nejlepší kontrola kódu možná. Jakýkoli jiný mechanismus má za následek hru viny. Párové programování vyvolává týmového ducha a kolektivní vlastnictví. Kromě toho debatujete o svých nápadech se svým párem, rychle selháte, podniknete nápravná opatření a je to pouze párový kódovaný a zkontrolovaný kód, který se zavazuje do systému pro správu konfigurace (CMS). Šťastný pár programování!

3
karthiks

Jednou z věcí, které se snažím udělat v recenzích kódu, které se účastním, je po kontrole kódu sám, dělám statickou analýzu kódu, pomocí nástrojů jako Findbugs, PMD, JavaNCCP et al, a podívat se na všechny problémy, které tyto nástroje najdou kód, který má být zkontrolován. Obzvláště se chci podívat na všechno, co má neobvykle vysokou úroveň složitosti, a požádat je, aby vysvětlili, proč je tato úroveň složitosti nezbytná nebo proč navrhovaná zranitelnost není důležitá.

YMMV

2
mezmo

Tam, kde v současné době pracuji, vyrábíme hardwarová zařízení a software, který je propojuje s těmi, která jdou do kritické infrastruktury. Proto se velmi soustředíme na kvalitu vydání. Používáme variantu Fagan Inspection a máme formální proces kontroly. Máme mimo jiné certifikaci ISO 9001.

Průmysl kritické infrastruktury má velký zájem o jeho spolehlivost a opakovatelnost. :-)

2
Paul Nathan

Pokud neděláte párové programování, doporučujeme použít recenze kódu.

Neporazovat výhody a nevýhody párování, ale je těžké zpochybnit pozitivní dopady toho, že váš kód bude neustále přezkoumáván (alespoň) jinou osobou. Kód je dokonce napsán a navržen (přinejmenším) dvěma programátory - sotva se může zlepšit. Říkám "alespoň", protože imo, měli byste se pokusit přepnout páry hodně, takže každý dostane šanci na práci s kódem.

2
Martin Wickman

V mé společnosti máme povinné kódové recenze pro juniorské programátory a dobrovolné recenze pro seniory. Neexistuje žádný určený recenzent kódu, žádosti o kontrolu jsou zasílány všem vývojářům.

Tento systém funguje dobře - recenze se provádějí podle časového povolení a změny mohou být kontrolovány několika sadami očí.

Vynikající a bezplatný nástroj Review Board pro nás funguje velmi dobře a ukázal se jako vynikající způsob komunikace s recenzemi.

2
GavinH

Pokud pracujete na projektu, ve kterém více lidí přispěje k kódové základně, je třeba stanovit standard.

V této chvíli je podle mého názoru nejlepší označit jednu osobu za „krále“ revize kódu, pokud chcete a co říká. V tomto ohledu, pokud jeden uživatel nedodrží normy, král se o to postará.

Jako já sám mnohokrát přezkoumávám svůj vlastní kód, aby byl čitelný, rozumný a všechno ostatní. Obvykle používáme javadoc nebo podobné v daných jazycích, které kódujeme, a pomocí @author tagu připojujeme vlastnictví k funkcím, třídám atd.

Pokud funkce není správná, promluvíme si s majitelem, stejně se třídou atd.

2
Chris

V mé společnosti je každému úkolu přiřazen tester, který testuje úkol, a také recenzent kódu, který tento kód zkontroluje.

Pokud je váš produkt již uveden na trh a chcete se ujistit, že neděláte nic špatného (například úniku popisovače nebo úniku paměti), jsou recenze kódu skvělá věc. Myslím, že během počátečního vývoje před uvolněním produktu může být kontrola kódu příliš práce.

Pokud má váš tým všechny vedoucí vývojáře, je vzájemné hodnocení stále užitečné. Každý občas dělá chyby. Pokud má váš tým několik seniorů a juniorů, nechte starší vývojáře nechat provést kontrolu kódu, ale přesto si nechte zkontrolovat kód pro seniorův kód.

Jednou důležitou věcí při kontrole kódu je to, že dokáže zachytit chyby, které uděláme, ale není to náhrada za testování.

2
Brian R. Bondy

Zjistili jsme, že nejúčinnějším způsobem, jak udělat recenze kódu, je 1-na-1 pomocí githubu, aby se ukázaly rozdíly ve větvi.


  • Je jedna osoba považována za strážce kvality a kontroluje kód, nebo vlastní tým standard?

    • Závisí na velikosti týmu - tým 3 bude mít 1 senior, který má nejlepší znalosti o osvědčených postupech, zatímco tým 12 může mít 3 nebo 4 osoby, které budou plnit tuto roli.
  • Prohlížíte kód jako týmové cvičení pomocí projektoru?

    • Osobně. 1 na 1 bude méně ohrožující. Někdy se děje v komunální oblasti, i když pro šíření znalostí. Závisí na přesné situaci, osobách, rozvrhu atd.
  • Děje se to osobně, e-mailem nebo pomocí nástroje?

    • Osobně. Používáme git a github a má skvělé nástroje pro kontrolu a porovnávání kódu, které usnadňují kontrolu kódu.
  • Vyhýbáte se recenzím a používáte věci jako párové programování a vlastnictví kolektivního kódu pro zajištění kvality kódu?

    • Snažíme se dělat obojí podle potřeby. To znamená, že při uvíznutí na obzvláště trnitém problému nebo při práci na základní infrastruktuře nebo při přípravě na dovolenou nebo odchod ze společnosti může být provedeno párování za účelem sdílení a přenosu znalostí. Na konci by měla být přezkoumána také většina kódu nebo kódu, který má něco jiného než kosmetické změny.

Stejně jako u všech kódovacích položek by měla správná odpověď zohlednit:

  • Typ společnosti (např. Založení vs. velká společnost)
  • Velikost společnosti
  • Počet vývojářů
  • Rozpočet
  • Časové okno
  • Pracovní zátěž
  • Složitost kódu
  • Schopnost recenzentů
  • Dostupnost recenzentů
1
Michael Durrant

V mé společnosti nikdy neprovádíme formální kontrolu kódu před kontrolou, pokud nemodifikujeme vysoce kritickou výrobu a nemáme čas na provedení našeho standardního procesu QA.

Co děláme, je to, že pokaždé, když se domníváme, že by bylo užitečné provést revizi kódu, přidáme do upraveného kódu komentář „// todo: review review by joe“ Obvykle vybereme Joe, protože vlastní modifikovaný kód, ale pokud se tato výběrová kritéria nepoužijí (obvykle ano), náhodně jsme vybrali někoho jiného. A samozřejmě, pokud bude Joe v té době k dispozici, použijeme dobrou starou metodu revize přes rameno.

Jako recenzent je jedinou věcí, kterou musíte pravidelně hledat celý kód pro „// todo: revize kódu mnou“ , zkontrolujte změny a zkontrolujte kód zpět bez komentáře "todo ..."

Pokud se vyskytne problém, přepneme se zpět na tradiční způsoby komunikace (mail/chat/atd.).

Tato metoda nám poskytuje dvě hlavní vlastnosti, které hledáme v kontrolním systému:

  • velmi lehká režie
  • sledovatelnost
1
Brann

Pracoval jsem v mnoha společnostech a viděl mnoho procesů. Můj současný tým to zvládne to nejlepší, co jsem dosud viděl.

Používáme agilní vývojový proces a jako součást toho máme brány, kterými musí každý příběh projít. Jednou z těchto bran je kontrola kódu. Příběh se nepokouší otestovat, dokud nebude provedena kontrola kódu.

Navíc kód ukládáme na github.com. Takže poté, co vývojář dokončí svou změnu, zveřejní odkaz na potvrzení v příběhu.

Poté označíme kolegu vývojáře ke kontrole. Github má systém komentářů, který umožňuje někomu, aby se vyjádřil přímo na řádku příslušného kódu. Github pak odešle e-mail distro, takže někdy někdy dostaneme další oči od některých našich ostatních týmů.

Tento proces pro nás fungoval velmi dobře. Používáme agilní procesní nástroj, který usnadňuje zveřejňování závazků a usnadňuje komunikaci.

Pokud je problém zvláště lepkavý, posadíme se a projednáme ho. Funguje to proto, že je nedílnou součástí našeho procesu a každý si musí koupit, jak tento proces funguje. Můžeme přesunout lístky zpět do probíhajícího, pokud má revize kódu za následek nutnou přepracování a poté může být znovu zkontrolována po provedení změn, nebo si recenzent může všimnout příběhu, že oprava položek je dostatečná a není třeba ji znovu kontrolovat.

Pokud testování něco nakopne zpět, jde to až do konce a všechny další změny jsou také přezkoumávány.

0
Bill Leeper