Proč se odhad času pokazí, když se zapomene na revizi?

Začněte tím, že si ke každé vrstvě pyramidy napíšete, co má chránit. U jednotkových testů to bývá logika výpočtů a hraniční stavy, u integračních testů kontrakty mezi službami, u end-to-end testů klíčové uživatelské cesty. Když se požadavek změní, neptejte se nejdřív, jak upravit testy, ale která z těchto ochran se změní. Tím získáte jasný signál, zda jde o úpravu v jedné vrstvě, nebo o přesun odpovědnosti mezi vrstvami.

Jakmile jeden skript funguje, ulož si ho a napiš k němu krátkou poznámku, co dělá a co potřebuje ke spuštění. Další úlohu řeš stejným postupem: popsat ruční kroky, najít knihovnu, napsat minimální verzi, otestovat, naplánovat. Po několika takových skriptech přestane být Python nástrojem, kterému nerozumíš, a stane se běžnou součástí práce.

Nejčastější problém je sdílený stav mezi testy. Fronta, databáze nebo dočasná složka se nevyčistí a druhý test vidí data z prvního. Před každým testem proto vytvářejte izolované prostředí – vlastní frontu, vlastní schéma nebo alespoň jednoznačný prefix klíčů. Nikdy nespoléhejte na to, že úloha na pozadí doběhne dřív než začne další test.

Typická chyba začátečníka je, že kód spouští ručně v editoru a diví se, že se nic neděje automaticky. Automatizace znamená, že skript běží sám: buď ho naplánuješ, nebo ho spustí jiný proces. Druhá častá chyba je ignorování chybových stavů. Soubor nemusí existovat, síť může vypadnout, v tabulce může chybět sloupec. Ošetři to blokem try a except a loguj, co se pokazilo. Bez logů budeš při prvním selhání hádat.

Pro jednoduché případy postačí middleware, který si drží počítadlo požadavků v paměti. Funguje to tak, že si ke klíči (IP adresa, API klíč, uživatel) uložíte počet požadavků a časové razítko. Při každém požadavku zkontrolujete, zda nevypršelo okno, a případně počet resetujete. Pokud počet překročí limit, vrátíte stavový kód 429 a hlavičku s časem, za jak dlouho to zkusit znovu. Pozor na to, že v paměti to funguje jen pro jednu instanci. Jakmile aplikaci škálujete horizontálně, každý proces má vlastní počítadlo a limit se rozplyne. Řešením je sdílené úložiště, typicky Redis, které drží stavy konzistentní.

Typická chyba je zapomenout na čekání. Nejen na samotné připomínky, ale i na to, než se reviewer k vašemu kódu dostane. Pokud pracujete v týmu, kde review dělá jedna vytížená osoba, může to být klidně den. Do odhadu to musíte zahrnout, jinak budete vypadat nespolehlivě. Stejně tak je chyba předpokládat, že všechny připomínky vyřešíte hned. Někdy je potřeba se domluvit, diskutovat, přepsat návrh. To vše je práce.

Dalším krokem je sledovat, jak dlouho review skutečně trvá. Nestačí jen odhadnout, že to „nějak půjde". Zapište si, kdy jste poslali kód k revizi, kdy přišly první komentáře a kdy jste dokončili poslední úpravu. Po několika úkolech uvidíte vzorec. Možná zjistíte, že review trvá déle v pátek odpoledne, nebo že kolega, který má na starosti bezpečnost, přidá vždy několik připomínek. To všechno jsou faktory, které patří do odhadu.

U operací, které mění více zdrojů, je potřeba idempotentní klíč kombinovat s optimistickým zamykáním. Například při převodu peněz se kontroluje verze zůstatku. Bez toho může i idempotentní klíč selhat, pokud se mezitím změnil stav. U dlouhých operací se vyplatí oddělit přijetí požadavku od jeho provedení. Server vrátí identifikátor úlohy a klient se dotazuje na stav. Opakované vytvoření úlohy se stejným klíčem vrátí stejný identifikátor.

Základem je rozdělit si práci na fáze a každé přiřadit reálný čas. Samotné psaní kódu bývá jen polovina celkové práce. Zbytek tvoří příprava, testování, čekání na review, čtení komentářů a jejich zapracování. Pokud odhadujete jen „čisté" programování, výsledek bude vždy podhodnocený. Praxe ukazuje, že review a následné úpravy zaberou klidně třetinu až polovinu času stráveného psaním kódu. U složitějších změn nebo v týmu, kde je review důkladné, to může být i více.

Automatizace v Pythonu nestojí na složitých znalostech programování, ale na ochotě přepsat jednu konkrétní ruční činnost do skriptu. Vyber si úlohu, kterou děláš opakovaně a mechanicky: přejmenovávání souborů ve složce, kopírování dat mezi tabulkami, stahování stejné sestavy každé ráno. Čím nudnější a čím častější, tím lepší start. Nezačínej abstraktním projektem, u kterého nevidíš okamžitý výsledek.

Každý, kdo někdy plánoval práci na softwarovém úkolu, zná ten pocit: odhad je hotový, termín zapsaný, a pak přijde code review a připomínky. Najednou je vše jinak. Přitom stačí málo – systematicky do odhadu zahrnout i čas na revizi a zapracování připomínek. Nejde o žádnou vědu, ale o návyk, který se vyplatí pěstovat od prvního ticketu.