http://bloomwiki.org/api.php?action=feedcontributions&feedformat=atom&user=BruceJeanneret9 2026-10-18T00:06:46Z User contributions MediaWiki 1.43.0 http://bloomwiki.org/index.php?title=5_krok%C5%AF,_jak_p%C5%99esn%C4%9B_odhadnout_%C4%8Das_na_code_review&diff=513566 2026-10-12T00:52:06Z

<p>BruceJeanneret9: Created page with &quot;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.&lt;br&gt;&lt;br&gt;Nejdřív s...&quot;</p> <hr /> <div>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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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ší.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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ě.&lt;br&gt;&lt;br&gt;Náhled změn je povinný, ne voliteln&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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á&quot; práce ještě není hotová.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.</div>

BruceJeanneret9