Edytujesz Když se větev rozbije, tým ztrácí celý den

Když se požadavky mění, největší problém nebývá počet testů, ale jejich křehkost. Testy, které opisují konkrétní podobu odpovědi nebo přesný sled kroků v UI, se rozbijí při každé úpravě. Řešením je testovat kontrakty: co musí platit na rozhraní mezi vrstvami, ne jak přesně to vypadá uvnitř. Kontraktní testy přežijí změnu implementace, dokud zůstane stejný slib vůči okolí. To výrazně snižuje počet testů, které je nutné přepisovat při každé změně zadání.<br><br>Poslední věc, kterou většina týmů podceňuje, je sdílená odpovědnost. Když se něco pokazí, nehledejte viníka, ale proces. Zaveďte krátkou retrospektivu po každém větším problému a ptejte se, co změnit. Git je nástroj, ne omluva pro chaos. Tým, který má jasná pravidla a dodržuje je, nemusí řešit, kdo co rozbil. Prostě ví, kam se podívat a jak to spravit.<br><br>Nejrychlejší cesta k rozbitému kódu je potvrdit refaktoring bez kontroly náhledu. Většina prostředí umí zobrazit diff ještě před zápisem změny. Zvykněte si tento náhled procházet, zvlášť u přejmenování, které sahá i do textových řetězců, komentářů nebo konfiguračních souborů. Právě tam vznikají chyby, které kompilátor neodhalí: přejmenovaný klíč v konfiguraci, přepsaný název v logovací zprávě, nefunkční odkaz v šabloně. Náhled zabere pár sekund, hledání rozbité konfigurace klidně hodinu.<br><br>Do odpovědi vždy přidejte metadata: celkový počet (jen pokud ho umíte spočítat bez drahého COUNT(*) přes celou tabulku), odkaz na další stránku a informaci, zda existuje předchozí. U kurzorové paginace počet záznamů často vynechte úplně – je to poctivější než vracet číslo, které trvá sekundy. Limity držte nízko (například 20–100) a vynucujte je na serveru, ne v dokumentaci.<br><br>Typické situace, kdy NoSQL dává smysl První je horizontální škálování. Když potřebujete rozložit zátěž na mnoho běžných serverů a relační databáze s replikací a shardingem začíná být příliš složitá, dokumentová nebo sloupcová databáze to zvládne přirozeněji. Druhá je nestrukturovaný nebo rychle se měnící obsah. Pokud ukládáte logy, telemetrii, produkty s desítkami různých atributů nebo uživatelské profily, kde se pole často přidávají a ubírají, pevné schéma jen přidělává migrace. Třetí je extrémní poměr zápisu ke čtení. Senzory, měřiče a sběr událostí potřebují hlavně rychle zapsat; NoSQL to zvládá bez režijních nákladů na transakce.<br><br>NoSQL není náboženství ani univerzální lék. Je to nástroj pro situace, kdy relační model naráží na škálování, schéma nebo objem zápisu. Pokud tyto problémy nemáte, zůstaňte tam, kde jste. Pokud je máte, vyberte podle dotazů a konzistenčních nároků, ne podle popularity.<br><br>Kontrakty místo kopírování scénář<br><br>Sloučení samo o sobě nestačí. Rozhodněte, zda používáte sloučení s historií, nebo přeuspořádání commitů. Obě varianty mají své místo, ale míchat je nahodile vede k nečitelným dějinám. Pro většinu týmů platí: do hlavní větve jde změna jako jeden smysluplný celek, ne jako hromada commitů typu „oprava" a „ještě oprava". Před sloučením si větev lokálně spusťte, ať víte, že projde. Pokud selže, neposílejte ji dál.<br><br>Praktický postup je začít od dotazů, ne od dat. Sepište, jaké dotazy budete volat a jak často. Pak zvolte typ databáze, který je umí obsloužit bez skenování celé kolekce. Před nasazením otestujte scénář výpadku jednoho uzlu a chování při souběžných zápisech. Zjistíte tak, zda zvolený model konzistence odpovídá vašim požadavkům. A hlavně: jednu databázi neměňte za druhou bez měření. Často stačí relační databázi správně indexovat nebo přidat cache a NoSQL není potřeba.<br><br>Pull request není formalita, ale místo pro kontrolu Pull request bez kontroly je jen způsob, jak protlačit změny. Aby měl smysl, musí mít jasná pravidla: maximálně několik stovek řádků změn, popis co a proč, a alespoň jeden člověk, který kód skutečně přečte. Pozor na typickou chybu: recenzent schválí vše, protože je pátek odpoledne. Lepší je mít méně pull requestů a opravdu je číst. Menší změny se kontrolují rychleji a snáze se vracejí, když se něco pokazí.<br><br>Základem je krátká životnost větví. Čím déle větev žije, tím větší konflikty přinese. Ideálně by větev neměla přežít déle než dva dny práce. Když něco trvá déle, rozdělte to na menší části. Praktický návyk: ráno si větev aktualizujete z hlavní linie, ne až před sloučením. Pravidelné začleňování změn z hlavní větve je otrava, ale ta otrava je přesně to, co brání velkému výbuchu na konci.<br><br>NoSQL je označení pro skupinu databází, které neukládají data do tabulek s pevným schématem a cizími klíči. Místo toho pracují s dokumenty, klíč-hodnota páry, širokými sloupci nebo grafy. Vznikly z potřeby zvládnout objemy dat a rychlost zápisu, na které relační databáze přestávaly stačit. Nejsou náhradou relačních databází za každou cenu, ale řešením konkrétních problémů.