Bez dobré dokumentace API se frontend a backend navzájem zablokují

Náboráři a techničtí leadové tráví u jednoho životopisu méně než minutu. Pokud v něm není vidět, co kandidát reálně postavil, končí. Proto dej odkazy na repozitáře hned nahoru, ne na konec. U každého projektu uveď jednu konkrétní věc, kterou sis musel nastudovat sám, a jednu, kterou bys dnes udělal jinak. Tím ukazuješ schopnost reflexe, což je v juniorské pozici cennější než znalost syntaxe nazpaměť.

Pro oddělení se vyplatí zavést šablony a generátory. Konfigurační soubory pište jako šablony s placeholdery a hodnoty doplňujte při nasazení z bezpečného úložiště. Tím se konfigurace stává reprodukovatelnou a verze kódu určuje, jaké klíče aplikace očekává. Když se změní název proměnné, změní se i šablona, ale hodnoty zůstávají mimo repozitář. Výsledkem je, že historie kódu je čistá a konfigurace se dá kdykoli vrátit zpět bez zásahu do zdrojáků.

Testování aplikací začíná u rozhodnutí, co vůbec ověřovat. Než napíšeš první test, sepiš si seznam rizik: co se stane, když aplikace spadne při přihlášení, když ztratí data, když pošle platbu dvakrát. Testy nemají pokrýt všechno, mají pokrýt to, co bolí nejvíc. Praktický postup je rozdělit aplikaci na vrstvy – datová logika, rozhraní, integrace – a pro každou zvolit jiný typ ověření. Bez tohoto rozdělení skončíš u hromady testů, které sice běží, ale nic nechrání.

Responzivitu netestujte jen zmenšováním okna. Otevřete vývojářské nástroje, zapněte zobrazení mřížky a projděte šířky 320, 480, 768 a 1200 pixelů. Sledujte, kde se obsah láme a kde přetéká. Když něco nefunguje, nepište další media query — nejdřív zkontrolujte, zda má rodičovský prvek správný display a zda potomek nemá min-width, který brání zmenšení. Většina problémů vzniká na těchto dvou místech.

Náhled změn je povinný, ne voliteln

Nejčastější důvod, proč se spolupráce frontendu a backendu zadrhne, není technický dluh ani špatná architektura. Je to dokumentace, která buď chybí, nebo popisuje něco jiného, než API skutečně dělá. Výsledkem jsou dohady v chatu, zbytečné přepisování kódu a zpoždění, které nikdo neplánoval. Dokumentace přitom není administrativa navíc – je to nástroj, který určuje, kdo co může dělat a kdy.

Grid a Flexbox nejsou konkurenti. Grid postaví stránku, Flexbox doladí detaily uvnitř komponent. Kdo tuto dělbu práce respektuje, píše méně kódu a méně výjimek. Kdo je míchá bez rozmyslu, skončí s layoutem, který se sám rozpadá při každé změně obsahu.

Nejčastější chyba je vnořovat Grid do Gridu tam, kde stačí Flexbox, a naopak. Další je nastavovat pevné výšky. height: 100vh na mobilu počítá s adresním řádkem prohlížeče a obsah se schová. Místo toho použijte min-height nebo dvh. Pozor také na gap — v Gridu i Flexboxu funguje spolehlivě, ale zatímco v Gridu drží mřížku, ve Flexboxu jen odsazuje položky. Nezaměňujte to s margin, jinak vám vzniknou dvojité mezery na okrajích.

Flexbox je jednorozměrný. Řadí prvky v jedné ose — buď vodorovně, nebo svisle. Hodí se na navigaci, lištu s tlačítky, kartu s ikonou a textem, zarovnání prvku na střed. Když potřebujete, aby se položky zalomily a rovnoměrně rozdělily místo, použijte flex-wrap: wrap a flex: 1 1 260px. Tím dáte prohlížeči minimální šířku a on sám rozhodne, kolik jich zůstane v řadě. Vyhnete se pevným breakpointům.

Rozdělte repozitáře podle toho, kdo co vlastní Prvním krokem je rozhodnout, co je kód a co konfigurace. Kód patří vývojářům, prochází review a vydává se ve verzích. Konfigurace patří provozu nebo konkrétnímu prostředí a často ji spravuje jiný tým. Založte dva repozitáře: jeden pro aplikaci, druhý pro konfiguraci. Pokud to nejde kvůli nástrojům, použijte alespoň oddělené větve s ochranou a jasným vlastníkem. Do repozitáře s kódem nikdy necommitujte soubory s hesly, tokeny ani connection stringy. Místo toho používejte soubory, které se načítají z prostředí nebo z externího úložiště.

V praxi to znamená, že v kódu zůstane pouze výchozí konfigurace bez citlivých hodnot, například vzorový soubor s prázdnými klíči. Skutečné hodnoty se doplní při nasazení. Pokud používáte kontejnery, předávejte konfiguraci přes proměnné prostředí nebo připojené svazky. U klasických serverů se osvědčilo mít konfigurační repozitář naklonovaný vedle aplikace a při deployi ho aktualizovat zvlášť. Tím zmizí konflikty, kdy vývojář přepíše produkční nastavení jen proto, že ho měl omylem v pracovní kopii.

Nakonec nastavte proces, který oddělení udrží. V CI kontrole zakážete commity s tajnými klíči, v repozitáři s konfigurací povolíte pouze oprávněné uživatele a každou změnu konfigurace prožeňte stejným schvalovacím procesem jako kód. Pravidelně kontrolujte, zda se citlivé hodnoty neobjevily v logech nebo v chybových výpisech. Oddělené verzování není jednorázový úklid, ale návyk, který šetří čas při každém nasazení a snižuje riziko, že se produkční nastavení ocitne ve špatných rukou.