it-swarm-eu.dev

Jak přimíte lidi, aby přijímali kontrolu kódu?

Všichni programátoři mají svůj styl programování. Ale některé styly jsou řekněme ... řekněme to. Takže máte kontrolu kódu, abyste se pokusili stanovit určitá pravidla pro dobrý design a dobré programovací techniky.

Ale většina programátorů nemá ráda kontrolu kódu. Nelíbí se jim, že ostatní lidé kritizují svou práci.

Kdo si myslí, že se mají považovat za lepší než já a říci mi, že je to špatný design, mohlo by to být provedeno jiným způsobem. Funguje to správně? Jaký je problém? To je něco, co by mohli řekni (nebo si řekni, ale neříkej, což je stejně špatné, ne-li horší).

Jak tedy přimíte lidi, aby přijímali revizi kódu bez zahájení války?

Jak je můžete přesvědčit, že je to dobrá věc; to jen zlepší jejich programovací dovednosti a vyhne se spoustě práce později na opravě a opravě miliónkrát věci, kterou hej ... "to funguje"?

Lidé vám řeknou, jak provést revizi kódu (vzájemné programování, formální inspekce atd.), Co hledat v revizi kódu, byly provedeny studie, které ukazují počet vad, které mohou být objeveny před tím, než software zasáhne výrobu atd. Ale jak přesvědčujete programátory, aby přijali kontrolu kódu?

152
user7197

Zjistil jsem, že lidé, kteří nemají rádi recenze kódu, se budou snažit vyřešit cokoli, co zavedete.

Nejlepší způsob, jak se ujistit, že kód, se kterým pracujete, je řádně zkontrolován, je pracovat někde, kde se to považuje za normální způsob kódování, a že najímá pouze vývojáře, kteří se do tohoto prostředí pravděpodobně hodí.

Pokud nemůžete změnit, s kým pracujete, máte možná úspěch, pokud nejprve zadáte svůj vlastní kód ke kontrole. Povzbuďte je, aby s tím našli chybu (troufám si navrhnout doplnění několika úmyslných chyb?), Abyste mohli prokázat, že to ne znamenalo způsob kritiky dotyčného vývojáře. To je hlavní problém, IMO: lidé berou recenze kódu příliš osobně.

170
Jon Skeet

Jednoduché: přiřaďte důležité projekty programátorům, kteří přijímají kontroly kódu. To je jasná zpráva: tento projekt je příliš důležitý na to, aby odešel amatérům.

Programátoři, kteří nebudou spolupracovat, mohou provádět údržbářské práce. Pokud vaše revize kódu nebude široce prováděna, bude to mít vaše společnost spoustu. Vysvětlete, že se jedná o slepou ulici. Tyto produkty budou klesat, budou upuštěny nebo nahrazeny novějšími produkty, které byly zkontrolovány kódem.

Při najímání je jasné, že revize kódu jsou ve vaší společnosti normou. Přiřaďte nové nájemce, kteří přijímají kontroly kódu, novým projektům.

Celkově to řekne vašim vývojářům, že společnost přijímá recenze kódu. Mohou si vybrat: jít nebo vyjít. V žádné společnosti neexistuje budoucnost pro lidi bojující proti společnosti.

39
MSalters

No, opravdu nemůžete, pokud někdo prostě odmítne byt a nejste jejich šéfem.

Ale hlavním důvodem pro přijetí jiného stylu je ...

Konzistence

Myslím, že ať už je jakýkoli šílený styl, musí to být konzistentní. Pokud je tedy projekt vytvořen tímto stylem, musí obvykle zůstat v tomto stylu, pokud neexistuje výjimečně přesvědčivý důvod ke změně. Takže pokud se jejich styl neshoduje; je to fakt, že by se měl přizpůsobit. Žádná otázka zde.

Existují i ​​další problémy, které lze poznamenat, že jsou špatné. Bezpečnost, obecná „špatnost“ atd. To je nepochybné a mělo by se změnit.

Pokud někdo odmítne uznat něco špatného designu, poté, co jste jim ukázal správnou cestu a ukázal jim všechna rizika a problémy s tím, co dělají, myslím, že se musíte sami rozhodnout, jak jednat. Ale doufali byste, že nepracujete s lidmi, kteří jsou tak nerozumní.

30
Noon Silk

Jsem programátor a baví mě recenze kódu. Klíčem k dobrým recenzím kódu podle mých zkušeností je vylepšování kódu.

Když dělám kontrolu kódu s kolegou a on/ona upozorňuje na možná vylepšení nebo číhající chyby, jsem šťastný. Kód se zlepší a pravděpodobně jsme oba trochu chytřejší. Proč by se mi to nelíbilo?

Někteří lidé bohužel vidí revizi kódu jako způsob, jak zdůraznit skutečnost, že váš kód musí mít 4 odsazení mezerami místo 3 odsazení mezerou nebo nějaké jiné neživotaschopné podrobnosti.

Ujistěte se, že lidé, kteří provádějí kontrolu kódu, mohou a budou poskytovat užitečné informace. Pokud poskytuje pouze recenze vstupního kódu něco, co lze snadno provést pomocí nástroje, pak je kontrola kódu ztráta času.

Zkontrolujte, zda recenze kódů nejsou ztráta času a většina vývojářů je bude bavit.

26
Brian Rasmussen

Když řídím projekt, řeknu-li, že uděláme kontrolu kódu, uděláme kontrolu kódu. Budu samozřejmě poskytovat dobré důvody pro jejich provedení, ale na konci dne je mou odpovědností a rozhodnutím je implementovat.

A pokud se to programátorům nelíbí, mohou najít alternativní zaměstnání. Většinu neúspěšných projektů lze užitečně vylepšit tím, že se zbavíme poloviny vývojářů, a podle mých zkušeností je to nejchudší vývojář, který nejvíc namítá proti kódovým recenzím.

12
anon

Jediný důvod, proč jsem si zakoupil do procesu kontroly kódu, bylo to, že asi před rokem osoba, která se je pokusila uvalit, vytáhla kartu nadřazenosti a donutila nás zkontrolovat si kód druhé strany pro daný projekt. Na konci tohoto projektu jsem viděl obrovskou výhodu a nyní se snažím vnést do mých projektů revize kódu.

12
James Hay

„Funguje to“ nestačí. Kód není napsán pouze pro stroje, které mají být spouštěny, ale také pro lidi, kteří mohou číst, přizpůsobovat a vylepšovat. Pokud lidé nemohou najít cestu skrz kód, nemohou dělat všechny tyto úkoly, které jsou starostou programování.

Pokud Joe Programmer řekne: „Nedívej se na můj kód, jsem jediný, kdo to musí pochopit.“ O tom bych pochyboval. Pouze ve výjimečných případech se kód dotýká pouze jedné osoby. A i když tomu tak je: rozumí Joe jeho vlastnímu kódu příští týden, příští měsíc, příští rok? Asi ne.

9
lutz

Téměř v každé komerční provozovně (a většina nekomerčních), programátoři nevlastní kód, který píšou, jejich zaměstnavatel.

Téměř v každém komerčním zařízení (a většina nekomerčních) to vypadá, že většina programátorů si myslí, že je do vlastní kód, který píšou.

To způsobuje obrovské množství problémů s přijetím revize kódu jako techniky pro zlepšení designu ...

Způsoby, jak snížit odpor, mohou zahrnovat:

  • představení párové programování : žádný kód nebude zapsán, pokud se na něj dva programátoři nedívají. Okamžitá kontrola kódu v reálném čase. Ujistěte se, že se páry pravidelně přepínají.
  • najít způsob, jak "anonymizovat" recenze kódu, takže to nemůže být osobní
  • přezkum v malých kouscích, aby nikdo nebyl konfrontován s dlouhými seznamy vylepšení
  • neumožňují odbavení žádného kódu, dokud nebude zkontrolován (a implementovány a zkontrolovány akční body)
  • zavést libovolnou součást platby, která závisí na přijetí revizí kódu

Nedoporučuji žádné (dobře, možná první) výše uvedené konkrétně.

Důležité je získat skutečné pochopení toho, jaké jsou výhrady skutečné, nikoli to, co slyšíte na povrchu. Možná požádejte 5 Whys , abyste se prohloubili?

9
Mike Woodhouse

Když jsem vývojář, nemám rád kontrolu kódu.

Ale já opravdu chci zkontrolovat kód, pokud jsem vůdce. Víme proč.

Někteří vývojáři však určitě nebudou rádi recenze kódu, stejně jako já.

Co takhle tring anonymní kontrola kódu?

Můžeme napsat příklad kousky kódu nebo tipy po recenzi kódu zjistit, co je lepší způsob.

Jednoduchý příklad:

originální kus:

s=objGotFromSomewhere.doSomething()

lepší kousek:

if(objGotFromSomewhere!=null){
      s=objGotFromSomewhere.doSomething()
  }

poznámka:

V nějakém projektu jsme dostali ... problém, způsobený .. důvodem

tipy:

vždy zkontrolovat ...

Můžeme to vložit na wiki nebo někam a pak o tom mluvit na týdenním setkání týmu. Tech Leader to udělá a povzbudí starší vývojáře a všechny členy týmu, aby to také udělali.

Myslím, že anonymní je důležité, to znamená, že nikdo neví, kdo vygeneroval špatný kód.

Lidé možná nemají rádi recenze kódu, ale rádi budou vědět, co je lepší způsob.

9
chiesa

S pár recenzemi jsem udělal dobré zkušenosti. Dva lidé si navzájem prozkoumávají zdrojový kód, zatímco oba sedí před stejným monitorem. Dbáme na to, aby to nebyli vždy stejní lidé a aby bylo jasné a předem dohodnuto, co oba hledají.

Přezkoumání kódu však vyžaduje otevřené lidi, kteří jsou ochotni přijmout kritiku.

8
Benedikt

Měl by mít vyšší oprávnění k zavedení procesu kontroly. I ti, kteří se zpočátku proti tomuto nápadu bouří, by snad měli přijít, aby viděli jeho výhody. Pokud to ne ... dobře, nemůže to opravdu pomoci.

Pokud jste jen osamělý bojovník mezi nezaujatými vrstevníky, budete mít mnohem těžší čas. Klíčem v obou scénářích však je, aby recenzenti pochopili, že se nejedná o osobní útok na jejich dovednosti, ale spíše o týmovou snahu rozdrtit everyones chyby efektivněji.

7
deceze

Jak přimíte lidi, aby přijali kontrolu vašeho kódu?

Nemůžeš, takže ne. A vy nejste zodpovědní za práci někoho jiného, ​​dokud nebudete požádáni, abyste za to převzali odpovědnost.

Můžete přistupovat ke své „recenzi“, takže je to spíše jako „zpětná vazba“. Nejste to šéf, který hledá věci, které někdo udělal špatně, jsou to dva profesionálové diskutující o různých přístupech ke stejnému problému.

IMO, každý dva programátoři přijdou s různými způsoby, jak vyřešit problém, a oba mohou mít pravdu.

Zeptejte se recenzenta: „Co považujete za výhodu tohoto přístupu?“ Také uveďte nevýhody, které vidíte, a výhody vašeho alternativního přístupu. Požádejte o potvrzení DA, na které jste upozornili - „souhlasíte, že by to mohl být problém s kódem, který máte?“

Myslím, že většina konfliktů v programování pochází z hodnotových rozdílů a hádání, co by se mohlo v budoucnu stát. Lidé mohou strávit hodiny dohadováním se o něčem úplně neurčitém. Zaměřte se nyní na skutečné problémy, méně na (ale nevyhýbejte se) věcem, které by se mohly stát později.

7
Beth

Nejlepší způsob je, aby rozhodnutí pocházelo od programátorů, kteří to dělají.

Navrhoval bych využít dovednosti některých lidí a začít diskusí o tom, jak zajistit, aby skupina mohla spolupracovat. Také bych hovořil o způsobech, jak zajistit, aby dovednosti programátorů na pracovišti zůstaly aktuální.

Jednou z cest vpřed je samozřejmě kontrola kódů, ale existují i ​​jiné cesty, které by mohly být úspěšné, například čtení a diskuse o knize o tom, jak programovat. Doporučuji „Čistý kód: Příručka agilního softwarového řemesla“ ( http://www.Amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 ).

Další věcí je nechat každý programátor představit své projekty před skupinou, když něco dokončili. To přirozeně zajistí, aby se nejškaredější věci nenapsaly, a každý se bude cítit hrdý, že něco provedl.

6
Alexander Kjäll

Osobně si myslím, že programátor, který nemá rád recenze kódu, je jen velmi špatný programátor. Pokud píšete dobrý kód, nemusíte se bát kontroly. Ve skutečnosti byste mohli být chváleni za svůj styl. Ale pokud si zvyknete psát špatný kód, pak si dokážu představit, proč by někdo nechtěl recenzi. Ale mít někoho jiného poukazovat na chyby ve vašem stylu je jen užitečné pro zlepšení své vlastní zkušenosti! Měli byste se poučit z recenze, ne se jí vyhýbat. Je to obrovský nárůst kvality kódu.

Když provádíte kontrolu kódů, ujasněte si, že to děláte pro zlepšení kvality kódu, nikoliv pro trestání špatných vývojářů. Zajistěte, aby vaši programátoři považovali tyto recenze za vzdělávací, nikoli za způsob měření jejich výkonu.

Měl jsem spoustu kontrol kódu a specializoval jsem se na složité algoritmy, takže můj kód má tendenci vypadat trochu složitěji pro ostatní. Kolegové programátoři mě považují za velmi dobré v tom, co dělám, a prostě miluji revizi svého kódu, protože má vzdělávací hodnotu. A samozřejmě, občas v mém kódu najdou nějaké malé chyby, ale obecně jsou tyto recenze kódu zlepšování kvality práce osoby, která kód kontroluje!

6
Wim ten Brink

K provádění recenzí používáme ReviewBoard . V naší společnosti jsou recenze dobrovolné: pokud děláte něco zajímavého (podstatné doplnění nebo změny), očekáváme, že vytvoříte žádost o recenzi, kterou provedou kolegové ve vašem týmu. Vybraní členové týmu pak mohou kontrolu schválit nebo požádat o další změny.

Pokud potřebujete vynutit recenze, protože programátor nehraje, může se od všech vyžadovat, aby se zavázali SCM, aby předložili kontrolní ID, které je před přijetím označeno jako schválené.

5
MathieuK

Ne vždy předpokládej, že problém je na jejich konci. Možná to děláte špatně.

Zjistěte, proč se jim nelíbí, a místo toho, aby automaticky předpokládali, že jsou „špatní programátoři“, nejprve zvažte, zda mohou mít nějaký bod a že můžete být špatným recenzentem kódu nebo jednoduše špatně komunikovat. Je to možné.

Pokud vaše pravidla pro kontrolu kódu/styl nejsou subjektivní, svévolná nebo šílená, bude pro ně snadné vysvětlit zdůvodnění jakémukoli kompetentnímu profesionálnímu programátorovi. Pokud nemůžete, možná budete muset přehodnotit buď to, co děláte, nebo jak to prezentujete.

V opačném případě, pokud je problém pouze u jednoho nebo dvou jedinců, je pravděpodobné, že se u těchto lidí jedná o hlubší problém v oblasti lidských zdrojů a že to nemá nic společného s revizí kódu, věc revize kódu je pouze příznakem tohoto většího problému.

5
frankodwyer

Pokud máte na starosti projekt od začátku nebo jste hlavním vývojářem, měli byste být schopni provádět revize kódů tím, že je zavedete jako součást své metodiky projektu. Pokud je to nutné, ujistěte se, že jsou recenze prováděny. Pokud jste na starosti a někteří lidé vás nebudou následovat, musíte je přesvědčit, aby se s programem dostali, nebo je nahradili lidmi, kteří to udělají.

Pokud to nemáte na starosti, musíte přesvědčit členy týmu, že je pro ně přínosem provádět kontroly kódu. Začněte přesvědčením ostatních členů týmu, aby zkontrolovali váš kód. Zdokumentujte svůj design a rozhraní a projděte je kódem. Poté si pro sebe vytvořte souhrnné recenze a akční položky a rozešlete je členům svého týmu. Pokud z toho bude mít prospěch, bude to týmu rychle patrné.

Pokud existuje odpor, musíte zjistit, jaké jsou námitky lidí. Mohou být platné. Například projekt může být dostatečně malý a celý tým může být natolik zkušený, že každý v projektu účinně recenzuje celý kód v projektu i bez formálních recenzí.

Považuji recenze kódu za nejužitečnější na velmi velkých projektech, kde není možné, aby jedna osoba skutečně prošla celý kód, kde jsou nezkušení vývojáři, kteří potřebují zpětnou vazbu, aby si mohli rozvíjet své kódovací a analytické dovednosti, nebo kde jsou nekódování. členové týmu, kteří musí rozumět designu a kódu. Přezkumy považuji za nezbytné nebo dokonce povinné, pokud existují právní důsledky nebo horší, pokud se kód nezdaří (např. Systémy řízení letu letadel). Považuji je za nadbytečné, když pracuji s ostřílenými programátory, kde všichni v týmu produkují kód, kde je projekt malý a členové týmu jej kód neustále čtou a kritizují.

4
Jeff Leonard

Musíte uznat, že nemůžete „přimět“ lidi, aby přijali kontrolu kódu.

Můžete udělat kompilátor dělat to, co chcete, ale s lidmi je nejlepší, na co se můžete zaměřit, je:

"Jak mohu být vlivnější při kontrole kódu jiné osoby?"

... a to je úplně jiná otázka.

4
Leon Bambrick

Myslím, že největším problémem s recenzemi kódu je to, že někteří lidé je nemohou udělat správně. Například umístění finále před třídu/metodu/parametr/nic nezáleží a nemělo by být v revizi kódu. Dalším příkladem je použití nesprávné smyčky, protože pouze foreach je v pořádku. Vyžadovat komentář. Optimalizace String +/StringBuilder/StringBuffer. Kdybych dostal kontrolu kódu s některou z těchto věcí, myslel bych si, že ten chlap je idiot, a kdybych nebyl nucen změnit kód, tak bych to neudělal.

Také někdy jsou nástroje pro kontrolu kódu prostě špatné, například výchozí PMD (Java) ráda říká, že třída má příliš mnoho metod, takže jsem vytvořil, že jsem vytvořil abstraktní nadřazené třídy a tam Push některé metody. Mohl jsem rozdělit třídu do 2 tříd, ale myslím, že API bude jednodušší použít se všemi těmito metodami v jedné třídě (je to malé lib a moje návrhové rozhodnutí). Někteří lidé budou vždy používat pouze výchozí nastavení, takže by to nemělo být mizerné.

4
martin

Princip 1-3-2 platí zde (Mluvím 1. osoba, poté 3. osoba, pak 2. - v tomto pořadí).

První prioritou je cvičte, co kážu, což znamená, že se nejprve obávám, že řeknu „potřebuji“ zkontrolovat kódy (a dělat je).

Pak, pouze pokud se atmosféra nepřizpůsobuje recenzím kódu, začnu říkat, že lidé potřebují kontrolu kódu (a vyjmenuj dobré důvody).

Teprve poté, pokud vše ostatní selže (a já mám pravomoc :)), stanovím zákon a řeknu „potřebuješ“ kontrolu kódu. To je část, o které lidé správně vyjmenovali, ale já Twitch teprve tehdy, když mentalita třetí osoby není poslední. Pokud nedokážu mluvit v první osobě a nepraktikuji to, co kážu, nejsem jen „neúčinný“ přesvědčovatel, ale jsem mnohem víc blbec.

ps. Všimněte si, jak jsem to řekl první osobě :)

4
Alexander Bird

Abych nabídl jinou perspektivu, občas jsem objevil, že recenze kódu se unášejí do věcí, které nemají smysl ani diskutovat. Jako bych nechal toho chlapa prohlížet můj kód a říkat, že v jedné z poznámek, které jsem přidal do kódu, nemám správnou interpunkci (stop). I když je subjektivní, zda je taková věc důležitá (pokud píšete inline dokumentaci, která se například dostane do vydaných dokumentů, může to být důležité), v mém případě to samozřejmě nebylo.

Myslím, že revize kódu jsou povinné, téměř vždy mi pomohly komentáře v revizi kódu, a někdy trvá trochu času, než nový člen týmu pochopí, proč jsou důležité. Je však také důležité, aby byla zachována objektivita, každý návrh by měl mít objektivní důvod a neměl by být učiněn kvůli subjektivním preferencím recenzenta.

Takže odpovědět na otázku - je dobré mentorovat nové členy týmu o důležitosti a účelu revize kódu ve fázi, kdy je pravděpodobné, že budou poslouchat. A se zkušenostmi se naučí, že to není osobní. Je také důležité mít ty správné lidi, kteří jsou recenzenty, nikoli lidé, kteří k ostatním vnucují své subjektivní názory.

4
alps123

Recenze s otázkami, nikoli příkazy

Domnívám se, že zásadním problémem vašeho recenzního procesu je myšlenka, že musíte krkem vynutit cokoli. Místo toho položte otázky jako „Proč jste se rozhodli jít s přístupem X místo Y?“

To je přiměje, aby přemýšleli o svém vlastním procesu kódování, místo toho, aby je nutili přijmout váš proces kódování. A hej, možná se něco naučíš.

3
Sean

Nikdy jsem neměl šanci se zapojit do kontroly kódu, ale myslím si, že je to určitě vynikající postup.
Aby byla recenze kódu dobře přijata, můžete si nechat uspořádat školení o tom, jak učinit „pozitivní kritiku“.

A mimochodem, takové školení by také mohlo být příležitostí připomenout lidem principy rozvoje společnosti/projektu a udělat nějaké budování týmu.

2
Patrick Honorez

Za prvé, jako u všech problémů, začněte tento řešit sami. Ujistěte se, že děláte vše pro to, aby recenze kódu byly co nejproduktivnější a nejkonfrontační.

  1. Nepoužívejte recenze kódu k prosazování osvědčených postupů, když můžete použít automatizaci nějakého druhu. Mějte po ruce standardní knihovny, abyste splnili nejběžnější úkoly: šifrování, přístup k databázi atd. Pomocí AOP a injekcí politiky se starejte o standardizované protokolování, auditování, bezpečnostní omezení atd. Spíše než konfrontovat vývojáře a procházet je, aby to udělali „správně“ "tak to jen usnadněte." Jsme líní, takže se vydáme cestou nejmenšího odporu.
  2. Nekontrolujte názvy proměnných, standardizované bloky komentářů a další nitpicky detaily. Pokud není název proměnné obtížné pochopit, je to v pořádku. „Konzistence“ je jen výmluva k uplatňování autority a každý ji může vidět.
  3. Nemáte ve své skupině nejstrašivějšího chlapa, aby prováděl recenze. Nebo se postarejte, aby lidé, kteří se střetávají s osobními konflikty, kontrolovali kód druhé strany.
  4. Při každé kontrole kódu si dejte občerstvení a nápoje. Každý má rád občerstvení a nápoje.
2
Chris McCall

Podle mých zkušeností má pár programování mnohem více výhod než jen recenze. Nejen, že najde více chyb, ale podporuje více kreativních řešení, sdílení znalostí, budování týmu, otevřenou komunikaci a umožňuje týmu neustále vylepšovat přirozený styl programování.

Pokaždé jsem byl v týmu, který vyzkoušel recenze, dostane konfrontaci a pak se rozzáří, když se objeví tvrdý termín.

Pro zkušeného vývojáře může být obtížné přizpůsobit se myšlence recenzí, ale když klikne, dynamika skutečně nabude. Vyzkoušejte to na pár týdnů a zjistěte, zda to funguje pro vás.

1
Eric Nicholson

Zkuste je prodat z hlediska učení . Téměř každý programátor, kterého jsem potkal, se rád učí a já osobně jsem se při každé kontrole kódu něco naučil (ať už jsem byl recenzentem nebo recenzentem).

Jakmile však začnete recenze, je vaší úlohou zajistit, aby byly užitečné. Nenechte se zapadnout do drobných formátovacích argumentů (vezměte je offline). Použijte nástroje pro statickou analýzu (jako FindBugs pro Javu), vyhledejte TODO, zkontrolujte všechna varování kompilátoru, zkontrolujte úplnost dokumentace atd.

Čím cennější informace nalezené v recenzi, tím úspěšnější budou recenze.

1
Brad Cupit

Kontrola kódu je nezbytnou součástí prevence závažné katastrofy na začátku. Mnoho hlavních vývojových obchodů ŽÁDÁ o jejich kontrolu kódů.

Pro to, aby lidé snáze přijímali, by měli recenzenti dodržovat pokyny. Pokud se jednotlivec cítí, jako by byl vybrán, nebo že by recenzent mohl mít zášť, může se zdráhat projít kontrolou. Pokud budou všichni předem informováni o pokynech a o tom, co recenzent bude hledat, možná budete mít lepší příjem. Nikdo nemá rád subjektivitu, když odráží jejich kariéru nebo výkon.

Na základě zkušeností jsem spolupracoval s řadou vývojářů na významných profilech vládních kontraktů, které byly přezkoumávány proti kódům. Kde nás to dostalo? Cesta za plánem a cesta k rozpočtu. Vývojáři, kteří mají něco skrýt, budou odolní vůči lidem, kteří procházejí jejich prací, protože si jsou dobře vědomi svých krátkých příchodů.

Byla to moje zkušenost, že ti, kdo nechtějí nebo jsou vůči recenzím odolní, jsou také stejní lidé, kteří se nechtějí učit a přizpůsobovat svůj styl myšlení problému, který je po ruce, což může být pro projekt kluzký svah, když osoba je v rozhodovací roli.

Něco jiného, ​​o čem přemýšlet; pokud rozpočet a společnost to mohou zpřístupnit, má někdo, kdo je pověřen výhradně kontrolou kódu, nebo dokonce někoho přivede z jiného projektu k provedení kontroly. Pokud neexistuje žádný předchozí vztah, může být pro obě strany snazší.

Pokud vše ostatní selže a vy se obáváte, postoje lidí mohou vytvářet problémy pro projekt celkově, zdokumentovat jej a respektovat tento problém na nadřízeného. Jít za někým nebo upozornit na jeho krátké příchody pro vás bude vypadat špatně a může upozornit na vaši vlastní práci.

1
Doomspork

Překvapilo mě, že se nikdo nezmínil o agilní praxi zvané „The Perfection Game“, která je součástí Core Protocols . Základní protokoly naznačují, že programátoři by měli snadněji přijímat revizi kódu.

Shrnuto, takto to funguje:

  • programátor se zeptá nějakého potenciálního recenzenta, zda je v pořádku hrát dokonalou hru
  • je-li recenzent v pořádku, recenzent zkontroluje kód a dá hodnotu 1 až 10, v závislosti na hodnotě, o které věří, že k němu může přidat kód (například pokud říká 1, může to znamenat, že se jedná o kousek hovna, ale já ano trochu tomu nerozumím, nepomůže, nebo to může znamenat, že je to téměř perfektní, nemohl bych dělat lépe. Pokud recenzent řekne 10, na druhou stranu by to znamenalo: váš kód je kus blbosti , ale máte štěstí: mohu vám s tím pomoci, protože jsem odborník na tento druh svinstva).
  • recenzent vysvětluje, co má rád (, nikoli to, co nemá rád ) v recenzovaném kódu
  • programátor se poté zeptá, co by bylo potřeba, aby byl tento kód dokonalý, a recenzent to vysvětlí.
  • programátor pak děkuje recenzentovi a v případě potřeby změní svůj kód.

Samozřejmě to může být opakováno, dokud programátor přestane hledat dokonalost, nebo recenzent už nemůže pomoci (dá nízké hodnocení a programátor se tam zastaví).

Je to trochu formální, jak vyplývá z Core Protocols, ale programátor je vždy zodpovědný za změny kódu a požaduje kontrolu jako službu. Obvykle tento druh recenze nepoužije k odmítnutí odpovědnosti, naopak by se programátor měl zeptat jiného recenzenta, pokud daný nebude schopen pomoci.

Perfection Game se nemusí vztahovat na každý případ, protože funguje na dobrovolném základě (tuto otázku chápu jako dotaz na povinné kontroly kódu). Rovněž se ukázalo, že „revize kódu“ se týká mnoha základních praktik (v agilním světě jsou pouze Perfection Game a Pair Programming dva zcela odlišné druhy kódových revizí).

Některé praktiky jsou snáze přijímatelné než jiné a záleží také na týmu a individuálním programátorovi. Jako doplněk bych také odpověděl na původní otázku tím, že řeknu, že revize kódu jsou snazší, když mezi členy týmu existuje důvěra.

Ať už jste zvolili jakýkoli postup, Důvěra vůči kolegům v týmu je rozhodně jádrem přijímání programátorů při kontrole kódu.

0
kriss

Ještě jedna možnost: Udržujeme pravidelné „úvahy“ o našem procesu se všemi programátory na projektu. Součástí této praxe je „analýza kořenových příčin“ chyb, které se nedávno objevily. Co to způsobilo? Byla to regrese? Byl to nedostatek testování IE6? Pomohlo by ti to zeptat se Joe? Cílem je zjistit, proč tyto chyby máme a co můžeme změnit, abychom jim zabránili.

Pokud jsou revize kódu vhodným nástrojem, vyjde to během diskuse. A budou to sami programátoři, kteří ji představí, a tak od začátku získáte mnohem více buy-inů. Dohodli jsme se, že před kontrolou musí být zkontrolován veškerý kód. Vývojáři to obvykle žádají, ale pokud na to zapomenou, šíleně to přiznají ... vědí, že nejen vzdorují „managementu“, ale jdou proti dohodě týmu .

(Nebo pokud to není vhodný nástroj, lidé mají šanci vysvětlit proč.)

0
ndp

Mám jinou situaci. Protože nejsem velmi zkušený vývojář, rád bych před každým vydáním provedl kontrolu kódu. Většinu času však kontrola kódu prostě nezapadá do našeho napjatého harmonogramu. Nebo si moje společnost nemyslí, že je to natolik důležité, aby to bylo možné. Totéž platí pro testem řízený vývoj. Pokud budu mít opravdu nějaké otázky, vezmu si staršího vývojáře, aby se podíval na můj kód. Není to ideální, ale pomůže mi to vylepšit si mé kódovací schopnosti.

0
logoin

Pokud neprovedou kontrolu kódu, pak jednoduše ... prostě je propustí. Očividně se příliš nezajímají o zlepšování. Není třeba udržovat mrtvou váhu.

0
Alex Baranosky

Zajistěte, aby kontrola kódu byla povinnou součástí odevzdání kódu do úložiště hlavní řady.

To je to, co můj tým dělá, a to zvyšuje kvalitu kódu a téměř úplně vylučuje možnost pochybného kódu, který by jej uvedl do kódové základny, aniž by byl konkrétně označen jako „technický dluh“.

Používáme Git a Gitorious pro správu našich kódových databází a repozitářů.

Existuje úložiště hlavní řada, nikdo se k tomu přímo nezavazuje, ale odtáhne se z něj do svých soukromých klonů na Gitorious serveru.

Work and Push se zavazuje klonovat na svém soukromém serveru a poté provést sloučení požadavků , aby požádali o začlenění jejich změn do hlavní linie.

Někdo jiný odpovídá na žádost o sloučení, nejlépe technický vedoucí týmu/projektu, a zkontroluje kód změny, použije je, zkompiluje a provede testy, a pokud je vše v pořádku, posouvá změny do - mainline repozitář a uzavře požadavek na sloučení.

Týmové/projektoví techničtí vůdci reagují na své požadavky na sloučení s někým jiným v týmu, což je skvělá zkušenost s učením juniorských členů, pokud není k dispozici partner.

Ať tak či onak, nyní je na háku více než jedna osoba, protože špatný kód je zavázán do úložiště hlavní řada a ovlivňuje zbytek týmu a společnosti jako celku. Pokud starší člen týmu odpoví na většinu požadavků na sloučení, je kvalifikován k opravě nebo odmítnutí špatných implementací nebo návrhů, než může ovlivnit celou základnu kódu.

Tyto mini kódy recenze jsou mnohem užitečnější než tradiční recenze kódu, které jsou obvykle ztráta času. Recenze návrh jsou mnohem cennější, protože správná * implementace ** špatného design je mnohem horší než špatná implementace a - správný design.

0
user7519