Edytujesz Sdílený commit vs. vlastní větev: jak nerušit tým při vývoji

Praktické kroky, jak pyramidu postavit v reálném projektu Nejdřív si vyhraďte čas na analýzu kritických cest. Sedněte si s týmem a napište si tři až pět nejdůležitějších uživatelských scénářů, jako je registrace, přihlášení nebo vytvoření objednávky. Tyto cesty pokryjte end-to-end testy. Vše ostatní, co je vedlejší, řešte na nižších vrstvách. Když narazíte na funkci, která potřebuje ověřit logiku, napište pro ni jednotkový test. Když potřebujete ověřit, že data správně putují mezi vrstvami, přidejte integrační test. Tím zajistíte, že každá vrstva dělá to, k čemu je určena.<br><br>Další častou chybou je přepisování historie větví, které už někdo jiný stáhl do svého lokálního úložiště. Pokud použijete příkaz, který změní pořadí commitů nebo je sloučí do jednoho, ostatní členové týmu přestanou mít konzistentní obraz o tom, co se děje. Proto historii měňte pouze u větví, které jsou výhradně vaše, nebo u commitů, které ještě nikdo nesdílel. U sdílených větví vždy raději vytvořte nový commit, který danou změnu opraví, než abyste přepisovali minulé záznamy.<br><br>Redux není nástroj, který by se hodil do každé aplikace. Pokud teprve začínáte, často narazíte na doporučení sáhnout po něm hned na začátku. To je ale cesta k tomu, že strávíte hodiny psaním boilerplate kódu a akcí, které ve skutečnosti žádný problém neřeší. Než Redux vůbec do projektu přidáte, položte si otázku, zda vaše aplikace skutečně sdílí stav mezi mnoha komponentami, nebo zda se data pohybují jen lokálně.<br><br>Když tým začne psát automatizované testy, většinou skončí u rozsáhlých end-to-end scénářů, které procházejí celou aplikací. Na první pohled vypadají solidně, ale po pár týdnech se ukáže pravý opak: běh trvá desítky minut, každá změna v rozhraní rozbije desítky testů a doba opravy převyšuje čas, který testy ušetří. Základní poučka zní: čím výše v pyramidě test stojí, tím je dražší na údržbu a tím méně jich má být. Přesto ji týmy soustavně ignorují a pak řeší důsledky.<br><br>Nakonec si osvojte zvyk pravidelně testovat vlastní návrhy. Není nutné mít laboratoř – stačí, když si sednete k hotové obrazovce a projdete si hlavní úkoly, jako byste byli uživatel. Zeptejte se sami sebe: Kde váhám? Co je nejasné? Jak dlouho mi trvalo najít klíčovou funkci? Takovýto self-test odhalí mnoho nedostatků dřív, než aplikaci vypustíte do světa. A když můžete, nechte si návrh projít někým, kdo vaši aplikaci nezná – jeho pohled je přesně ten, který potřebujete.<br><br>Konkrétně: pokud máte funkci, která počítá slevu, testujte ji na úrovni jednotkových testů. Pokud potřebujete ověřit, že se sleva správně uloží do databáze a zobrazí v seznamu, použijte integrační test. E2E si nechte na registraci, platbu nebo přihlášení – tedy na procesy, kde kombinace více systémů dává smysl. Tím získáte rychlou zpětnou vazbu, protože jednotkové testy běží v řádu sekund, zatímco E2E často v minutách.<br><br>Nezapomínejte také na rychlost. Testovací pyramida není jen o počtu testů, ale o čase, který jejich spuštění zabere. Ideální je, když jednotkové testy běží do pěti minut, integrační do patnácti a E2E do hodiny. Pokud vám E2E běží déle, rozdělte je do skupin podle kritičnosti a spouštějte je v noci. Ale pozor – noční běh znamená, že chybu objevíte až ráno. Proto se vyplatí mít aspoň pár klíčových E2E testů v CI, které běží při každém commitu.<br><br>Druhým krokem je práce s vizuální hierarchií. Uživatel by měl na první pohled vidět, co je nejdůležitější. Vytvořte jasný kontrast mezi primárním a sekundárním prvkem – hlavní akční tlačítko zvýrazněte, vedlejší akce ztlumte nebo umístěte stranou. Nezapomeňte na dostatečné mezery mezi prvky; přeplácané obrazovky působí chaoticky a zvyšují chybovost. Místo mnoha barev použijte jednu akcentovou barvu pro interakce a neutrální pro pozadí. Testujte také čitelnost textu – minimální velikost písma pro běžný obsah by měla být alespoň 16 pixelů, a to nejen na mobilu.<br><br>Praktickým testem, zda váš tým dodržuje správný workflow, je rychlost, s jakou se nový člověk dokáže zorientovat v historii. Pokud vidí jasné a krátké commity, které popisují jednu konkrétní věc, a hlavní větev obsahuje pouze stabilní verze, je vše v pořádku. Když naopak v historii najdete commity s hromadnými změnami nebo s popisem typu „oprava 2", je čas nastavit pravidla. Začněte s jednoduchým pravidlem – žádný přímý zápis do hlavní větve. I malý tým o dvou lidech tím předejde zbytečným konfliktům a zrychlí dodávání funkcí.<br><br>Při slučování větví dochází nejčastěji ke konfliktům v souborech, které upravuje více lidí současně. Typickým příkladem je konfigurační soubor, do kterého každý přidává svoje řádky. Abyste konfliktům předcházeli, pravidelně si do své větve přetahujte změny z hlavní větve. Tím udržíte svoji větev aktuální a sloučení nakonec proběhne rychleji. Pokud už ke konfliktu dojde, řešte jej vždy v místní kopii a před odesláním změn si projděte celý výsledek. Nikdy nespoléhejte na automatické sloučení, které může tiše přepsat důležitou logiku.