Když píšete commit, myslete na toho, kdo bude změny číst za půl roku
Čtvrtý princip se týká historických dat. Pokud vedete záznamy o tom, jak dlouho trvaly předchozí úkoly, použijte je pro budoucí odhady. Pokud podobná funkce minule zabrala 14 dní, je nepravděpodobné, že tentokrát bude hotová za 3 dny, pokud se zásadně nezměnil tým nebo postup. Sbírejte data průběžně – po dokončení úkolu si poznamenejte skutečný čas, ne jen plánovaný. Po několika projektech uvidíte své vlastní vzorce: kde se obvykle zpožďujete, co podceňujete a co naopak přeceňujete. Tyto poznatky jsou cennější než jakýkoli obecný vzorec.<br>
<br>
<br>
<br>
Rozdíl mezi manuálním a automatizovaným testováním se projeví hlavně v dlouhodobém horizontu. Zatímco manuální testy jsou vhodné pro jednorázové ověření před vydáním nové verze, automatizace se vyplatí, když aplikaci plánujete pravidelně aktualizovat. Automatizované testy vám umožní rychle odhalit regrese, tedy chyby, které vznikly po přidání nové funkce. Vytvořte si proto sadu testů, které spouštíte před každým nasazením. Nejlepší výsledky přináší kombinace obou přístupů: kritické funkce ověřujte ručně, rutinní scénáře nechte na automatizaci. Tak pokryjete širokou škálu případů a zároveň udržíte náklady na údržbu na rozumné úrovni.<br>
<br>
<br>
<br>
Základní návyk: commit jako kotva, ne jako povinnost Začněte tím, že si vytvoříte repozitář přímo v projektu. Už jen to, že máte lokální historii, změní váš přístup. Každou funkci, opravu nebo úpravu stylů ukládejte do malých, logických kroků. Například přidání tlačítka je jeden commit, změna jeho barvy je druhý. Vyhnete se tak situaci, kdy po týdnu nevíte, co se v kódu stalo. Než začnete pracovat, vždy si vytvořte novou větev (branch). To je váš oddělený prostor, kde můžete experimentovat, aniž byste ohrozili stabilní verzi.<br>
<br>
<br>
<br>
Třetí zásadou je rozložení velkého úkolu na menší části. Odhadovat celý modul nebo dokonce celý projekt je téměř nemožné. Místo toho si práci rozdělte na jednotlivé kroky trvající od dvou hodin do dvou dnů. Každý krok musí mít jasný výstup, který lze ověřit. Například „napsat funkci pro validaci e-mailu" je konkrétnější než „implementovat registraci". Čím menší položky, tím snazší je odhadnout jejich náročnost a tím spíš si všimnete případných problémů včas.<br>
<br>
<br>
<br>
Verzování se vyplatí i pro jednoho vývojáře. Když budete mít každou změnu podchycenou, můžete bez obav zkoušet nové přístupy. Špatný nápad můžete zahodit jedním příkazem a vrátit se k osvědčenému stavu. Navíc si vytvoříte zvyk, který využijete v každém dalším projektu. Začněte dnes – vytvořte si první commit a uvidíte, jak se vám uleví. Za pár týdnů si nedokážete představit práci bez toho.<br>
<br>
<br>
<br>
Myslete také na kontext. Commitová zpráva není místo pro kompletní dokumentaci, ale měla by obsahovat odkazy na související úkoly nebo čísla ticketů, pokud je to ve vašem týmu zvykem. Důležité je, aby čtenář okamžitě pochopil, k čemu se změna vztahuje. Nepoužívejte ale zkratky bez vysvětlení – „oprava #123" neřekne nic, pokud čtenář nemá přístup k systému. Raději napište „oprava výpočtu daně (ticket #123)".<br>
<br>
<br>
<br>
Než se do všeho pustíte, nastavte si lokální prostředí tak, jak je popsáno v dokumentaci projektu. Používejte stejnou verzi jazyka, nástrojů a závislostí, aby se chování shodovalo s tím, co vidí správci. A hlavně: pište commit zprávy srozumitelně, v přítomném čase, třeba: "Opravit překlep v návodu". Vyhněte se frázím jako "fix" nebo "update", které nic neříkají. Když budete postupovat podle těchto zásad, první příspěvek přinese užitek jak projektu, tak vám — získáte zkušenost, kontakty a možná i pověst užitečného člena komunity.<br>
<br>
<br>
<br>
Klíčové je psát smysluplné zprávy k commitům. Místo „úpravy" napište „přidána validace e-mailu do formuláře". Pomůže to vám i kolegům. Před odesláním změn na vzdálený server si vždy projděte rozdíly (diff). Díky tomu odhalíte chyby, které byste jinak přehlédli. A pokud si nejste jistí, jak přepínat mezi větvemi, nezoufejte – stačí pár základních příkazů a zbytek se naučíte za pochodu.<br>
<br>
<br>
<br>
Když už se pustíte do kódu, dodržujte zásadu malých změn. Jeden pull request by měl řešit jen jeden problém. Pokud opravujete chybu a zároveň předěláváte formátování, správce to pošle zpět. Rozdělte práci na logické části. Před odesláním si lokálně spusťte testy, ať už jde o unit testy, lintování nebo build. Nezapomínejte, že váš kód musí fungovat v kontextu celého projektu, nejen ve vaší ukázce. Když máte hotovo, napište do popisu pull requestu, co jste změnili, proč a jak jste to testovali. Konkrétní popis je důležitější než sebelepší kód.