5 kroků, jak přesně odhadnout čas na code review

Na závěr si odhad po dokončení porovnejte se skutečností. Uložte si, kolik času zabralo psaní, čekání na review i zapracování. Po několika úlohách uvidíte svůj osobní koeficient, o který se dá odhad upravit. Pomůže i domluva v týmu na maximální velikosti změny pro jedno review. Menší změny se recenzují rychleji a připomínky se zapracovávají snáz. Odhad tím přestane být hádání a stane se použitelným číslem.

Nejdřív si zmapujte, jak dlouho vám code review obvykle trvá. Projděte posledních pět až deset změn, které šly do review. Zapište si, kdy jste je odeslali a kdy přišlo poslední schválení. Získáte reálná čísla místo dojmů. Pokud review běží ve vlnách, změřte i dobu, kdy změna čekala na recenzenta. Právě čekání bývá největší a nejhůř odhadnutelná položka.

Prvním krokem je ujasnit si, kdo co vlastně řídí. U externího dodavatele nemůžete přímo nařizovat lidem, co mají dělat. Můžete ale ovlivnit prostředí, ve kterém pracují. Sepište si se zástupci dodavatele tzv. pracovní dohodu: kdo je produktový vlastník, kdo technický vedoucí, jak často se scházíte a co se stane, když se priority rozjedou. Bez toho se každá retrospektiva zvrhne v hádku o tom, čí úkol je důležitější.

Nejčastější chyba je psát media queries pro každou komponentu zvlášť a ještě předtím, než je hotový základní layout. Média mají řešit výjimky, ne hlavní chování. Pište je mobile-first: nejdřív definujte rozložení pro úzký displej a teprve přes @media (min-width: 48em) přidávejte sloupce či větší mezery. Vyhněte se pevným breakpointům podle konkrétních telefonů; vázat se na šířku zařízení je past, protože ta se pořád mění. Rozumné hranice jsou dnes kolem 40em, 48em a 64em.

Rozdělte odhad na tři samostatné části Samotné psaní kódu je jen první část. Druhou je vlastní code review — tedy čas, kdy někdo jiný čte, komentuje a vy se ptáte. Třetí je zapracování připomínek. Pro každou část udělejte odhad zvlášť a pak je sečtěte. Vyhnete se tomu, že review spadne do stejné kolonky jako vývoj a vy na něj zapomenete. U menších změn počítejte s kratším review, ale s větší pravděpodobností několika kol. U velkých změn je review delší a připomínky hlubší, i když jich může být méně.

Náhled změn je povinný, ne voliteln

Zapracování připomínek neznamená jen přepsat řádek. Často jde o přečtení kontextu, návrh nového řešení, úpravu testů a opětovné spuštění pipeline. Připočtěte i čas na odpovědi v komentářích a na vysvětlování, proč jste něco udělali jinak. Pokud recenzent navrhne změnu architektury, může jít o práci na několik hodin i dní. Proto si u každé připomínky poznamenejte, zda jde o kosmetickou úpravu, nebo o zásah do logiky.

Většina vývojářů refaktoruje myší: označí blok, rozbalí kontextové menu, vybere příkaz, počká na náhled a potvrdí. U jednoho zásahu to nevadí. U stovky zásahů během odpoledne se z toho stane hlavní činnost dne. Vestavěné nástroje pro refaktoring přitom mají klávesové zkratky, jen o nich lidé nevědí, protože je vývojová prostředí necpou do popředí. První krok tedy není učit se nové příkazy, ale přestat sahat po myši u těch, které používáte pořád.

Odhad času na vývoj je často složený jen z psaní kódu. Jenže code review a zapracování připomínek umí sebrat klidně třetinu až polovinu celkového úsilí. Kdo to nezapočítá, dostane se do skluzu nebo odevzdá práci později, než slíbil. Následujících pět kroků pomůže odhad zpřesnit.

Typická chyba je odhadovat review jako pevnou konstantu. Ve skutečnosti závisí na vytížení recenzentů, na složitosti změny a na tom, kolik lidí se do review zapojí. Další častou chybou je zapomenout na opakované review. Po zapracování připomínek se změna vrací ke kontrole a může přinést další kolo. Do odhadu proto přidejte rezervu alespoň na jedno až dvě dodatečná kola. Vyhnete se tak překvapení, že „hotová" práce ještě není hotová.

Pozor na to, jak nástroj pracuje s rozsahem závislostí. Pokud máte v monorepu balíčky, které na sobě závisí pomocí přesných verzí, každé vydání jednoho balíčku znamená, že musíte vydat i všechny závislé. To je správné, ale snadno to vede k lavinovému efektu. Řešením je používat rozpětí, například pomocí symbolu ^, ale jen tam, kde to dává smysl. U interních balíčků se často vyplatí závislost specifikovat pomocí pracovního prostoru, tedy odkazem na lokální balíček, a teprve při publikaci se nahradí konkrétní verzí. Tím se vyhnete ručnímu přepisování čísel.

Monorepo s více balíčky znamená, že v jednom repozitáři spravujete několik samostatně publikovatelných knihoven nebo služeb. Verzování takového celku je jiné než u jednoho projektu. Nejde jen o to, jaké číslo verze napsat do souboru package.json, ale hlavně o to, jak zajistit, aby se verze jednotlivých balíčků neposouvaly chaoticky a aby na sebe závislosti správně navazovaly. Pokud tohle podceníte, dřív nebo později narazíte na nekonzistentní vydání, kdy jeden balíček vyžaduje verzi druhého, která ještě neexistuje.