5 kroků, jak správně zdokumentovat open source licence v repozitáři

Většina týmů se zasekne na tom, že řeší nástroj místo dohody. Git sám o sobě nic neuspořádá. Rozhodující je, kdo kdy vytváří větev, kam se zapisuje a co se považuje za hotové. Začněte tím, že si v týmu napište tři věty: jak pojmenováváte větve, kdo schvaluje změny a co musí být v hlavní větvi vždy funkční. Bez této dohody skončíte s desítkami nepojmenovaných větví a hromadou konfliktů.

Jak propojit licenci s konkrétními soubory U rozsáhlejších projektů nestačí jedna licence v kořeni. Do hlavičky každého zdrojového souboru doplňte krátkou poznámku s identifikátorem licence, ideálně ve formátu, který je strojově čitelný, jako je SPDX. Tím zajistíte, že i při zkopírování jednoho souboru mimo repozitář zůstane licence zřejmá. Typickou chybou je, že vývojáři přidají licenci jen do README a zapomenou na soubory samotné – výsledkem je nejistota pro každého, kdo chce část kódu znovu použít.

Po každém dokončeném úkolu si zapište, jak dlouho skutečně trval. Po pár týdnech budete mít data, ze kterých se dá vycházet. Sledujte, o kolik se váš odhad lišil od reality – ne abyste se trestali, ale abyste zjistili, kde systematicky podceňujete. Nejčastěji to bývá integrace, testování a ladění chyb, které se v odhadech objevují jako jednoduchá položka „testy".

Základní pravidlo, které se vyplácí: hlavní větev je vždy nasaditelná. Nikdo do ní nezapisuje přímo. Každá změna jde přes větev s krátkým životem, obvykle pojmenovanou podle čísla úkolu a krátkého popisu. Větev vytvářejte z aktuální hlavní větve, ne z té, kterou máte otevřenou tři týdny. Pokud si nejste jistí, zda je vaše kopie aktuální, nejdřív si stáhněte změny a teprve pak vytvořte novou větev. Ušetříte si tím polovinu konfliktů.

Začněte tím, že si vyberete jednu běžnou aplikaci, kterou denně používáte, a začnete si psát, co všechno se v ní dá pokazit. Ne jen „nejde mi přihlášení", ale konkrétně: co se stane, když zadám e-mail s mezerou na konci, když vypnu internet uprostřed odesílání, když dvakrát rychle kliknu na tlačítko. Tyto poznámky si veďte v jednoduché tabulce — sloupec pro krok, sloupec pro očekávaný výsledek, sloupec pro skutečný výsledek. Tím vzniká testovací případ, i když jste nikdy žádný oficiálně nepsali.

Testovací pyramida není dogma, ale rozložení nákladů a rychlosti. V praxi jde o to, že čím níž v pyramidě test stojí, tím levněji se udržuje, rychleji běží a tím dřív odhalí chybu. Většina týmů, které mají potíže s kvalitou, nemá slabý test framework, ale obrácenou pyramidu: příliš mnoho pomalých end-to-end scénářů a příliš málo jednotkových testů. Náprava nezačíná nástrojem, ale rozhodnutím, If you have any queries with regards to where by and how to use Http://Crativ.Co.kr, you can speak to us at our own site. co kde testovat.

Poměr velikostí není pevné číslo. U knihovny stačí jednotkové testy a pár integračních. U platebního systému bude integrační vrstva silnější. Rozhodující je, kolik testů dokáže tým udržovat bez toho, aby trávil celý den jejich opravami. Pokud pipeline běží déle než deset minut, je čas přesunout testy níž nebo je rozdělit na rychlou a pomalou část. Rychlá část běží při každém commitu, pomalá před vydáním.
Po schválení změnu sloučte do hlavní větve a větev smažte. Nenechávejte za sebou hromadu mrtvých větví, ve kterých se nedá vyznat. Pokud se změna musí vrátit, použijte revert, ne mazání historie. Vrátí to stav bez přepisu toho, úložné prostory v malém bytě co už ostatní mají. A když se něco pokazí, nejdřív si zjistěte, co přesně je v repozitáři, a teprve pak zasáhněte. Panika a přepisování historie dělají větší škody než samotná chyba.

Commit posílejte malý a s jasnou zprávou. Ne „oprava", ale co se změnilo a proč. Jeden commit by měl jít vrátit zpět, aniž by vzal s sebou něco nesouvisejícího. Když zjistíte, že jste do commitu přidali i něco jiného, použijte rozdělení na části nebo amend, dokud změnu nikam neodešlete. Po odeslání už amend nedělejte, pokud na větvi pracuje někdo další. Typická chyba je nahrát obrázky, konfigurační soubory s hesly nebo složky s dočasnými daty. Do kořene projektu patří soubor, který tyto věci ignoruje, a ten musí být v repozitáři od začátku.

Většina lidí, kteří chtějí začít v testování bez předchozích zkušeností, udělá stejnou chybu: začnou se učit nástroje. Stáhnou si zkušební verzi nějakého softwaru, projdou pár videí a myslí si, že to stačí. Jenže náboráři a testeři v praxi hledají něco jiného — schopnost přemýšlet o tom, co může selhat, a umět to popsat tak, aby to vývojář pochopil a opravil. Nástroj se naučíte za týden. Systémové myšlení trénujete měsíce.

Začněte tím, že do kořene repozitáře umístíte soubor s názvem LICENSE nebo LICENSE.txt. Do něj vložte plný text zvolené licence, nikoli jen odkaz či zkratku. Pokud používáte více licencí pro různé části projektu, vytvořte pro každou samostatný soubor s jednoznačným názvem, například LICENSE-MIT a LICENSE-APACHE. Vyhněte se tomu, aby text licence byl jen v hlavičkách souborů – centrální soubor je místo, kam se lidé dívají nejdříve.