Edytujesz Když se kód začne zamotávat, pište ho takto

Prvním krokem je rozdělit repozitář na dva. V repozitáři s kódem ponechte pouze výchozí hodnoty, které jsou bezpečné pro všechny, a šablony konfiguračních souborů. Skutečné hodnoty pro vývoj, test a produkci patří do repozitáře s konfigurací. Tím získáte dvě nezávislé historie. Kód se dá kdykoli vrátit zpět, aniž byste s sebou táhli změny prostředí. Konfiguraci lze měnit bez nového buildu a bez zbytečného čekání na pipeline.<br><br>Na závěr: čistý kód není jednorázový úkol. Je to návyk. Pokaždé, když dokončíte funkci, přečtěte si ji nahlas. Pokud vám nedává smysl při čtení, nebude dávat smysl ani při ladění. Formátujte kód automaticky, používejte linter a nenechávejte v souboru zakomentované bloky kódu. Verzovací systém vám staré verze vrátí. Čistý kód se nepozná podle toho, že je krátký, ale podle toho, že se v něm dá rychle najít odpověď na otázku, kterou jste si právě položili.<br><br>Nakonec počítejte s tím, že se pyramida bude v čase měnit. Po každém větším posunu v požadavcích si udělejte krátkou retrospektivu nad testovací sadou: které testy odhalily chybu, které jen běžely, a které se musely přepisovat. Podle toho upravte rozložení. Pyramida, která se nevyvíjí spolu s projektem, se dřív nebo později zhroutí pod vlastní vahou.<br><br>Nejčastější důvod, proč se začínající vývojář zasekne na mnoho měsíců bez nabídky, není nedostatek znalostí. Je to snaha naučit se všechno předem. Kandidát si řekne, že nejdřív dodělá další kurz, pak framework, potom cloud a teprve pak začne posílat životopisy. Trh přitom nehodnotí, co umíš, ale co jsi dokázal dodat. Rozdíl mezi teoretickým a praktickým kandidátem je vidět během prvních pěti minut pohovoru.<br><br>Základem je pochopit čtyři věci: metodu, adresu, hlavičky a tělo požadavku. Metoda GET slouží ke čtení dat, POST k vytváření, PUT a PATCH k úpravám a DELETE k mazání. Adresa určuje, na jaký zdroj se ptáte. Do hlaviček patří informace o formátu odpovědi a často také autorizační klíč. Tělo požadavku se posílá jen u metod, které něco vytvářejí nebo mění. Pokud tyto čtyři části popletete, server vrátí chybu a vy budete zbytečně hledat problém jinde.<br><br>Autentizace a klíče: co si pohlídat Většina API vyžaduje prokázání identity. Nejčastěji se setkáte s klíčem v hlavičce, někdy s tokenem, který má omezenou platnost. Klíč nikdy neposílejte do veřejného repozitáře ani ho nevkládejte přímo do kódu, který někam nahráváte. Uložte ho do proměnné prostředí nebo do konfiguračního souboru, který je mimo verzovací systém. Pokud klíč omylem zveřejníte, okamžitě ho zneplatněte a vytvořte nový. Server si všimne neplatného klíče rychle a odpoví chybou, ale škoda může vzniknout dřív, než si toho všimnete.<br><br>Posledním krokem je pravidelná revize. API se vyvíjí a dokumentace musí držet krok. Jednou za čas projděte endpointy, které se změnily, a ověřte, že příklady stále platí. Zvažte i verzování, aby bylo jasné, která verze dokumentace patří k jakému nasazení. Frontend i backend tak mají stejný zdroj pravdy a nemusí se spoléhat na domněnky. Dobrá dokumentace není náklad navíc; je to úspora času při každé integraci.<br><br>Dokumentace REST API není formalita pro archiv. Je to pracovní nástroj, který drží frontend a backend u stejných předpokladů. Pokud chybí, začnou vznikat dohady: jaký formát data poslat, co znamená která chybová odpověď a proč jeden endpoint vrací jinou strukturu než druhý. Výsledkem jsou zbytečné opravy, zpoždění a přepisování hotových částí. Dokumentace má být proto součástí vývoje, ne něčím, co se dopisuje po nasazení.<br><br>Při ladění požadavků se vyplatí začít s co nejjednodušším voláním. Vyberte endpoint, který nic nemění, ideálně vrací seznam nebo jeden záznam. Odešlete požadavek a pečlivě si přečtěte odpověď. Sledujte stavový kód: čísla začínající dvojkou znamenají úspěch, čtyřkou chybu na straně klienta, pětkou problém na serveru. U chyby 401 nebo 403 zkontrolujte autentizaci, u 404 adresu, u 400 tvar požadavku. Nikdy neignorujte chybovou zprávu v těle odpovědi, obvykle přesně popisuje, co je špatně.<br><br>Čistý kód v JavaScriptu není o estetice. Je to o tom, že za půl roku budete v tom samém souboru hledat chybu a nebudete si pamatovat, proč jste tam ten cyklus vůbec psali. První pravidlo zní: pište kód pro člověka, který ho bude číst, ne pro interpret, který ho spustí. Proto používejte názvy, které něco znamenají. `const celkovaCena` místo `const x`. `function spocitejDph()` místo `function f1()`. Pokud název nedokážete vymyslet do deseti sekund, pravděpodobně děláte víc věcí najednou a měli byste funkci rozdělit.