<span style="font-weight: bold;">První programovací jazyk je</span> jako první cizí jazyk: naučíš se v něm nejen slova, ale i způsob myšlení. Neexistuje univerzálně nejlepší volba, ale existují kritéria, která ti pomohou vybrat správně. Klíčové je, aby tě jazyk bavil a abys v něm vydržel aspoň tři měsíce. Pokud začneš s něčím, co tě sice láká, ale je to zbytečně složité, skončíš u frustrace a odložíš učení na neurčito.<br>
<br>
<br>
<br>
Jednotkové testy běží rychle, izolovaně a přesně ukazují, kde se něco rozbilo. Integrační testy sice pokrývají více vrstev, ale jejich provoz je nákladný na čas i údržbu. S rostoucí kódovou základnou přestává být volba mezi nimi otázkou preference – stává se z ní ekonomika zpětné vazby. Čím větší projekt, tím důležitější je vědět, kterou vrstvu test pokrývá, a hlavně kdy jeho přidání přinese víc užitku než bolesti.<br>
<br>
<br>
<br>
Praktické rozložení podle velikosti úkolu U malých úkolů (do jednoho dne vývoje) je rozumné držet analýzu v rozmezí 20–30 % celkového času. Například na úkol o osmi hodinách vývoje si vyhraďte dvě hodiny na rychlou analýzu – to stačí na pochopení zadání a ověření klíčových předpokladů. U středních úkolů (2–5 dní) zvyšte podíl analýzy na 30–40 %. U velkých a nejasných úkolů (více než týden) může analýza zabrat až polovinu času, ale to je signál, že byste měli úkol raději rozdělit na menší části.<br>
<br>
<br>
<br>
Typická chyba, kterou vidím u týmů, je honba za stonásobným pokrytím za každou cenu. Programátoři pak píší testy, které jen volají funkce s triviálními vstupy, nebo používají nástroje, které uměle navyšují čísla — třeba provádějí kód přes reflexi nebo vypínají kontroly. Výsledkem je, že metrika vypadá skvěle, ale testy nechytí jedinou skutečnou chybu. Stejně problematické je i pokrytí, které se měří jen v jednom momentě — po změně kódu je často neaktuální. Doporučuji měřit pokrytí průběžně v CI a nastavit si minimální hranici, ale jen jako pojistku proti výraznému propadu, ne jako cíl.<br>
<br>
<br>
<br>
Výběr integrovaného vývojového prostředí (IDE) pro Python může na první pohled vypadat jako nevýznamné rozhodnutí. Stačí ale pár týdnů práce s nevhodným nástrojem a zjistíte, že ztrácíte čas na věcech, které by měly být automatické. Nejčastější chybou je sáhnout po prvním doporučeném editoru z internetu, aniž byste si ověřili, jak zvládá ladění, správu virtuálních prostředí nebo automatické doplňování kódu. Přitom právě tyto funkce rozhodují o tom, jestli budete psát plynule, nebo budete bojovat s každým druhým řádkem.<br>
<br>
<br>
<br>
Mezi nejčastější chyby patří snaha naučit se vše najednou. Často vidím lidi, kteří si koupí tři knihy, projdou dva kurzy a po měsíci jsou zmatení. Místo toho si zvol jeden zdroj a projdi ho celý. Dělej malé projekty, které tě baví: třeba jednoduchou kalkulačku, převodník měn nebo kvíz. Tím si upevníš syntaxi a pochopíš, jak jednotlivé části do sebe zapadají. Vyhýbej se copy-paste kódu z internetu bez pochopení. Pokud něco zkopíruješ, zkoušej to modifikovat a rozebírat.<br>
<br>
<br>
<br>
Třetí situace, kdy je pokrytí spíše škodlivé, je porovnávání mezi týmy nebo projekty. Čísla se dají snadno zmanipulovat a neberou v úvahu specifika domény. Testy pro bankovní převod budou vždy složitější než testy pro zobrazení statické stránky. Místo celkového procenta se proto zaměřte na pokrytí kritických částí — tam, kde chyba stojí hodně peněz nebo ohrozí bezpečnost. Dobrý test je takový, který selže, když dojde k reálné chybě. Pokrytí vám to neřekne, ale můžete si to ověřit mutačním testováním nebo tím, že do kódu záměrně vložíte chybu a podíváte se, jestli testy zareagují.<br>
<br>
<br>
<br>
<span style="font-weight: 800;">Když už víte, co dělat,</span> vyhněte se častým nástrahám. Nepište integrační testy na všechno, co se dá – to vede k monstrózní sadě, kterou nikdo nechce spouštět. Nepoužívejte testovací databázi v paměti, pokud produkční používá jinou – rozdíly v chování vás překvapí. A nepodceňujte údržbu testovacích dat. Pokud integrační test vyžaduje složité nastavení předem, je lepší ho rozdělit na menší celky nebo nahradit kontraktním testem.<br>
<br>
<br>
<br>
Nezapomínejte ani na paměť a výdrž baterie. Aplikace, která v pozadí drží náročné procesy, dokáže vybít telefon za hodinu. Sledujte spotřebu energie a paměti pomocí vestavěných profilovacích nástrojů ve vývojovém prostředí. Pokud zjistíte, že aplikace drží více než 100 MB paměti při minimálním používání, pravděpodobně máte únik paměti, který se projeví až po delším běhu.<br>
<br>
<br>
<br>
Než začnete vybírat, zaměřte se na svůj typický pracovní postup. Pokud děláte převážně skripty pro analýzu dat, budete potřebovat pohodlné zobrazení proměnných a integrovaný průzkumník datových rámců. Při vývoji webových aplikací oceníte spíše podporu šablon, terminál přímo v okně a nástroje pro správu verzí. Nebojte se kombinovat více nástrojů – nikdo vám nebrání používat jednoduchý editor na rychlé úpravy a plnohodnotné IDE na větší projekty. Důležité je, abyste se v prostředí cítili komfortně a nemuseli neustále přepínat mezi okny.
