Když se web načítá pomalu, začni u obrázků a serveru

Než konfiguraci zavedete plošně, nasaďte ji na jednom menším projektu a sledujte, kolik času lidé tráví jejím obcházením. Každá výjimka je signál, že pravidlo je špatně navržené, ne že lidé jsou líní. Konfiguraci berte jako kód: verze, kontrola změn, vysvětlení v popisu. A hlavně ji nechte přežít změnu člena týmu. Pokud její fungování závisí na tom, že někdo ví, proč je tam ten řádek, není jednotná, jen zdánlivě funguje.

Nakonec se vyplatí ptát se, co lze zcela odstranit. Zbytečné sledovací skripty, zjistit více duplicitní knihovny a dekorativní animace stojí čas i data. Každý prvek, který na stránce nemá jasný přínos, je kandidátem na smazání. Rychlost není jednorázový úkol, ale důsledek rozhodnutí, která děláš při každé úpravě.

Parametrizované testy a izolace Opakované scénáře se nevyplatí kopírovat. Místo pěti metod použijte [TestCase(1, 1, 2)] nebo [TestCaseSource] s kolekcí vstupů. NUnit pak spustí jednu metodu vícekrát a v výsledcích ukáže, který případ selhal. Pozor na sdílený stav: pokud testy zapisují do statické kolekce nebo mění globální konfiguraci, pořadí běhu rozhodne o výsledku. Každý test má mít vlastní data. Když se stav sdílet musí, použijte [SetUp] a [TearDown] pro přípravu a úklid před každým testem.

Autentizaci popište tak, aby bylo jasné, jak se token získává, kam se vkládá a jak dlouho platí. Uveďte, co se stane po vypršení platnosti a zda existuje obnovovací mechanismus. Pokud použíosvětlení v obývákuáte různé role nebo oprávnění, napište, které endpointy vyžadují jakou roli. Vyhněte se tomu, aby oprávnění byla popsána jen větou „platí obvyklá pravidla". To frontend nepoužije a backend to nebude chtít vysvětlovat při každé integraci.

Začněte tím, že oddělíte tři vrstvy: nastavení, které je stejné pro byt v panelákušechny a měnit se nesmí (formátování, pravidla lintování, verze nástrojů), nastavení, které se liší podle prostředí (adresy služeb, přepínače), a nastavení, které je čistě osobní a do repozitáře nepatří vůbec. Většina týmů tohle smíchá do jednoho souboru a pak se diví, že si lidé přepisují hodnoty lokálně a commitují je omylem. Osobní preference patří do ignorovaného souboru, ne do společného.

Typická past je kopírování konfigurace mezi projekty. Vypadá to jako úspora, ve skutečnosti vzniká několik verzí, které se rozejdou a nikdo neví, která je správná. Držte jediný zdroj pravdy a ostatní projekty na něj odkazujte. Další častá chyba je skrývání tajných údajů v konfiguraci, která se commitne. Tajné hodnoty patří mimo repozitář a do konfigurace se dostávají přes proměnné prostředí nebo správce tajemství. Když se tajemství jednou dostane do historie, je kompromitované navždy a rotace je nutná.

Vynucení místo domluvy Domluva, že se bude něco dodržovat, vydrží do prvního spěchu. Jednotná konfigurace musí být vynucená automaticky: při instalaci závislostí, při spuštění testů nebo v rámci kontroly před přijetím změn. Když kontrola selže, musí být z chybové zprávy okamžitě jasné, co je špatně a jak to opravit. Nejdražší chyba je konfigurace, která selže tiše a jen v některých prostředích. Pokud se nastavení načítá z více míst, musí být pořadí priorit zdokumentované a vynucené v kódu, ne jen popsané v hlavičce souboru.

Další častý problém je spojování příliš mnoha tabulek v jednom dotazu. Někdy to jde, ale pokud se dotaz skládá z pěti JOIN a třech poddotazů, je čas ho rozdělit. Někdy stačí mezivýsledek uložit do dočasné tabulky a pracovat s ním zvlášť. Databáze pak nemusí počítat stejná data znovu a znovu.

Prvním krokem je rozložit úkol na skutečné činnosti, ne na fáze. Místo „napsat API" si napište: projít existující kód, domluvit formát odpovědí s kolegou, napsat testy, nastavit lokální běh, opravit chyby po prvním review. U každé položky si položte otázku, kolik času zabere, než se dostanete k psaní produkčního kódu. Právě tam se skrývá režie, kterou lidé podceňují.

Nakonec se vyplatí sledovat, jaké dotazy se spouštějí nejčastěji. Někdy stačí upravit jeden dotaz, který běží pořád dokola, a výkon se znatelně zvedne. If you have any thoughts regarding where and how to use rady Pro Rekonstrukci, you can get in touch with us at our web-site. Měřte, nehádejte. Bez měření se dá snadno „optimalizovat" něco, co ve skutečnosti problém nezpůsobuje.

Jednotná konfigurace projektu nezní jako vzrušující téma, dokud se nezačne rozpadat. Většina týmů si ji představuje jako soubor, který se commitne do repozitáře a tím to končí. Jenže konfigurace není dokument, je to nástroj. Pokud ji nemá kdo udržovat a vynucovat, do měsíce se z ní stane sbírka výjimek, které si každý vykládá po svém. Rozhodující otázka nezní, co do konfigurace patří, ale kdo ji smí měnit a jak se změna dostane ke všem.