https://www.it-core.eu/wiki/api.php?action=feedcontributions&feedformat=atom&user=PenneyCascarret 2026-09-04T23:51:45Z User contributions MediaWiki 1.44.2 https://www.it-core.eu/wiki/index.php?title=Kdy%C5%BE_p%C3%AD%C5%A1ete_commit,_myslete_na_toho,_kdo_bude_zm%C4%9Bny_%C4%8D%C3%ADst_za_p%C5%AFl_roku&diff=199733 2026-08-29T05:11:29Z

<p>PenneyCascarret: Created page with &quot;Nakonec myslete na to, že dokumentace je živý artefakt. Stanovte odpovědnost – backendový vývojář, který endpoint vytvoří, by měl také aktualizovat popis. Pravidelně kontrolujte, že příklady v dokumentaci odpovídají reálným odpovědím. Automatizovaný skript, který porovná schéma se skutečnou odpovědí, vám ušetří ruční kontrolu. Když dokumentace přestane lhát, frontend přestane hádat a spolupráce se stane plynulou – což je př...&quot;</p> <hr /> <div>Nakonec myslete na to, že dokumentace je živý artefakt. Stanovte odpovědnost – backendový vývojář, který endpoint vytvoří, by měl také aktualizovat popis. Pravidelně kontrolujte, že příklady v dokumentaci odpovídají reálným odpovědím. Automatizovaný skript, který porovná schéma se skutečnou odpovědí, vám ušetří ruční kontrolu. Když dokumentace přestane lhát, frontend přestane hádat a spolupráce se stane plynulou – což je přesně to, co od dobré dokumentace očekáváte.&lt;br&gt;&lt;br&gt;Častým problémem je chybějící verze API. Pokud změníte strukturu dat, starší aplikace se přestanou chovat správně. Proto od začátku nastavte verzování v URL (např. /v1/) a v dokumentaci vždy uvádějte, kterou verzi daný popis pokrývá. Změny v rámci jedné verze by měly být zpětně kompatibilní – přidávejte nová pole, ale neměňte typy ani neodebírejte stávající atributy. Při větší změně vytvořte novou verzi a v dokumentaci nechte upozornění na přechodné období.&lt;br&gt;&lt;br&gt;Jak se vyhnout nejčastějším nástrahám při psaní commitů Jednou z nejčastějších chyb je popisování toho, co jste udělali, místo toho, proč jste to udělali. „Přidal jsem kontrolu na null&quot; neřekne nic o tom, že tím řešíte pád aplikace při výpadku sítě. Zaměřte se na příčinu a důsledek. Dále se vyhněte vágním formulacím jako „opravy&quot;, „změny&quot;, „refaktoring&quot;. Pokud refaktoring nemění chování, napište to – pak je jasné, že se nemáte bát o funkčnost.&lt;br&gt;&lt;br&gt;Poslední věc, na kterou mnoho lidí zapomíná, je realistický přístup k první nabídce. Neber práci, která je úplně mimo tvou oblast, jen proto, že je dostupná. Pokud chceš dělat backend, nezačínej jako tester, když ti to neleží – můžeš se tak na roky zaseknout na pozici, která tě nenaplňuje. Na druhou stranu buď otevřený tomu, že první práce nemusí být vysněná, ale měla by ti dát prostor růst směrem, který chceš. Ptej se na to, s jakými technologiemi budeš pracovat a jak vypadá mentoring – to je důležitější než drobné rozdíly v náplni práce.&lt;br&gt;&lt;br&gt;Další praktický krok je nastavit si pro každý jazyk vlastní terminál nebo příkazovou řádku. Mnoho projektů má skripty pro build spouštěné v různých prostředích. Pokud máte jeden terminál, který se přepíná podle aktuálního souboru, ušetříte si spoustu klikání. V praxi to znamená, že když stojíte v souboru Python, terminál se automaticky spustí s virtuálním prostředím. Když přejdete na JavaScript, terminál se přepne do Node.js prostředí. To vám umožní spouštět testy a linting bez ručního zadávání příkazů. Ale pozor, tohle vyžaduje, aby byl každý jazyk izolovaný ve svém vlastním adresáři nebo alespoň měl jasně oddělené konfigurační soubory.&lt;br&gt;&lt;br&gt;Když tým začne pracovat na jednom repozitáři, přestává být git jen nástrojem pro ukládání verzí. Stává se komunikačním protokolem, který rozhoduje o tom, jak rychle se vyvíjí funkce, jak snadno se opravují chyby a hlavně jak často dochází ke konfliktům. Mnoho týmů podcení výběr workflow a skončí u chaotického pushování do hlavní větve, což vede k přepisování cizí práce a ztrátě času.&lt;br&gt;&lt;br&gt;Další pastí je míchání nesouvisejících změn do jednoho commitu. Pokud opravujete chybu a zároveň přejmenováváte proměnné, vznikne z toho nepřehledná směs. Budoucí čtenář nebude schopen rozlišit, co je podstatné. Dělejte menší commity, každý zaměřený na jednu logickou jednotku. Pokud potřebujete provést více změn, rozdělte je do více commitů, i kdyby to znamenalo více práce navíc. Historii pak lze snadno číst a případně vracet zpět.&lt;br&gt;&lt;br&gt;Druhý krok je zviditelnit svou práci. Nemusíš být aktivní na sociálních sítích, ale měj veřejně dostupné portfolio, kde je vidět tvůj kód i to, jak přemýšlíš. Napiš pár krátkých textů o tom, co jsi při projektu řešil, a hlavně to, jaké chyby jsi udělal a jak jsi je opravil. Firmy nehledají někoho, kdo nikdy nechybuje – hledají někoho, kdo se z chyb umí poučit. Zaměř se na to, aby tvoje portfolio bylo jednoduché, přehledné a bez zbytečných efektů, které odvádějí pozornost od tvé práce.&lt;br&gt;&lt;br&gt;V praxi se osvědčuje pravidlo „jedna větev = jedna logická změna&quot;. Před začátkem práce si zkontroluj, že vycházíš z aktuálního stavu hlavní větve, a větvi dej výstižný název, který popisuje úkol (například „oprava-prihlasovani&quot; místo „feature1&quot;). Po dokončení změn ji co nejdříve sluč zpět pomocí pull requestu nebo merge requestu. Právě pull request je místem, kde se odehrává code review – nikdo by neměl slučovat vlastní práci bez kontroly kolegy, a to ani v malém týmu. Tím se zachytí nejen chyby v logice, ale i špatně pojmenované proměnné nebo chybějící testy.</div>

PenneyCascarret https://www.it-core.eu/wiki/index.php?title=User:PenneyCascarret&diff=199731 2026-08-29T05:11:26Z

<p>PenneyCascarret: Created page with &quot;Autor blogu dílnou i obývákem sází na osvědčené tipy. Píšu o tom, jak skloubit funkčnost s teplem domova. Nejraději ukazovat chytrá řešení, která zvládne každý.&quot;</p> <hr /> <div>Autor blogu dílnou i obývákem sází na osvědčené tipy. Píšu o tom, jak skloubit funkčnost s teplem domova. Nejraději ukazovat chytrá řešení, která zvládne každý.</div>

PenneyCascarret