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

Zaveďte si pravidlo, že main je vždy zelený. Když se build nebo testy rozbijí, řeší se to okamžitě, ne až po dalším commitu. Kdo změnu způsobil, ten ji opraví nebo vrátí. Sloučení dělejte přes takzvaný squash jen tehdy, když chcete z mnoha drobných commitů jeden smysluplný celek. Jinak zachovejte jednotlivé commity, ale pište k nim jasné zprávy v rozkazovacím způsobu a s vysvětlením proč, ne jen co. Historie je pro lidi, kteří přijdou po vás.<br><br>Nakonec se vyplatí měřit, ne hádat. Změňte jeden prvek, změřte dobu a plán, a teprve pak dělejte další úpravu. Sledujte nejpomalejší dotazy průběžně, protože seznam se mění s tím, jak rostou data. Výkon není jednorázový úkol, ale rutina: aktualizovat statistiky, hlídat nevyužívané indexy a kontrolovat, jestli podmínky nebrání jejich použití.<br><br>Typická chyba je sdílený stav mezi testy. Statická cache, singleton připojení nebo testovací databáze, kterou jeden test zapíše a druhý čte, vytváří závislosti, které se projeví až ve chvíli, kdy se sada rozroste. Izolujte data na úrovni transakcí nebo schématu pro každý test. Není to zdarma, ale je to levnější než ladit náhodné pády v CI.<br><br>Základem je krátká životnost větve. Čím déle ji držíte otevřenou, tím větší je šance, že se vzdálí od main a při sloučení vznikne konflikt v desítkách souborů. Ideálně by změna měla být hotová a sloučená během jednoho až dvou dnů. Když jde o větší práci, rozdělte ji na menší logické celky, které jdou sloučit samostatně. Před každým commitem si projděte, co posíláte. Používejte git status a git diff, ať neposíláte omylem konfigurační soubory s hesly, dočasné soubory nebo velké binárky. Do kořene projektu patří soubor, který tyto věci ignoruje, a měl by být v repozitáři od začátku.<br><br>Aktualizace a řešení konfliktů bez zbytečného stresu Než začnete pracovat, aktualizujte svou větev o změny z main. Použijte rebase, pokud chcete čistou historii, nebo merge, pokud chcete zachovat kontext větvení. Obě varianty jsou správné, ale tým by měl zvolit jednu a držet se jí. Rebase na veřejně sdílené větvi nedělejte, přepisovali byste historii ostatním. Konflikty řešte lokálně, nikdy neposílejte větev s nevyřešenými značkami. Po vyřešení spusťte testy a build, ne jenže soubory vypadají dobře. Častá chyba je slepé přijetí jedné strany konfliktu bez pochopení, co druhá strana měnila. Když si nejste jistí, zavolejte kolegovi a projděte změnu spolu.<br><br>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.<br><br>Začněte tím, že si pro každý test odpovíte na jednu otázku: selže tento test, pokud změním implementaci, ale chování zůstane stejné? Pokud ano, je to test jednotkový a nemá sahat na databázi, síť ani souborový systém. Pokud ne, patří do integrační vrstvy. Toto pravidlo zní banálně, ale při refaktoringu odhalí desítky testů, které dělají obojí a nedělají nic pořádně.<br><br>Nakonec si nastavte ochranu hlavní větve: zakázané přímé zápisy, povinné schválení a povinné testy. Bez toho se dřív nebo později najde někdo, kdo si řekne, že to tentokrát stihne rychleji. Tato pravidla nejsou byrokracie, ale způsob, jak se k sobě chovat slušně. Tým, který je dodržuje, tráví méně času opravami a více času psaním kódu, který funguje.<br><br>Než začnete řešit větve a Pull Requesty, musíte se domluvit na jedné větvi, která je vždy nasaditelná. Říkejte jí klidně main nebo master, ale musí platit, že obsahuje jen to, co je otestované a připravené jít na produkci. Do této větve nikdo neposílá commity přímo. Každá změna jde přes novou větev a kontrolu. Pokud tohle není jasné, dřív nebo později se stane, že si dva lidé přepíší práci a dohledávání zabere celý den. Název pracovní větve by měl nést informaci: typ změny a krátký popis, například oprava-prihlaseni nebo nova-fakturace. Vyhněte se názvům typu test, vetev2 nebo jmeno-prijmeni.<br><br>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.<br><br>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.