První commit do open source, který nechcete poslat
Proč je pojmenování polovina úspěchu Největší problém většiny JavaScriptových projektů jsou proměnné jako data, x nebo temp. Takový název nic neříká a nutí vás procházet celou funkci, abyste zjistili, co obsahuje. Pojmenovávejte proměnné podle toho, co představují, ne podle toho, jak vznikly. Například místo let a = getUsers() použijte let users = getUsers() a místo let flag = true zvolte let isAdmin = true. Boolean hodnoty začněte předponou is, has nebo can – hned je jasné, že jde o pravdivostní výraz.
Když zákazník požádá o odhad času, většina z nás automaticky vsadí na optimismus. V duchu si řekneme, že to stihneme dřív, a sdělíme termín, který nás pak dostane pod tlak. byt v panelákuýsledek? Zpoždění, omluvy a zákazník, který vám přestane věřit. Přitom stačí změnit způsob, jakým o čase mluvíte, a komunikace se stane nástrojem důvěry místo zdrojem stresu.
Na závěr si osvojte práci s malými funkcemi a čistými datovými . Místo dlouhého řetězce if-else pro různé typy zpráv použijte objekt, který mapuje klíče na funkce nebo hodnoty. Tím se kód stane deklarativnějším a snadno rozšiřitelným. Až budete příště psát funkci, zeptejte se sami sebe: rozuměl bych tomu za měsíc, kdybych to viděl poprvé? Pokud ne, přepište ji hned – ušetříte si pozdější hodiny ladění.
Testovací pyramida není jen hezký obrázek v prezentaci. Je to praktický nástroj, který vám ušetří hodiny práce, když ho použijete správně. Základní myšlenka je jednoduchá: čím blíže k uživatelskému rozhraní test stojí, tím je pomalejší, dražší a křehčí. Proto by jich mělo být méně. Naopak jednotkové testy, které běží v milisekundách, by měly tvořit nejširší základnu. Pokud tuto strukturu ignorujete, skončíte s testy, které se bojíte spustit, protože trvají půl hodiny a padají na maličkostech.
Stejně důležité je i pojmenování funkcí. handleClick() je sice časté, ale nic neříká. Zkuste saveUserPreferences() nebo toggleSidebar(). Funkce by měla mít jedno jasné zodpovědnosti – pokud dělá dvě věci, rozdělte ji na dvě. Typická chyba je funkce, která zároveň validuje vstup, posílá požadavek nábytek na míru server a aktualizuje DOM. Takový kód se nedá testovat ani znovu použít. Místo toho vytvořte malé funkce, které lze volat samostatně a které vrací očekávaný výsledek.
Když už máte automatizované nasazení a monitoring, zaměřte se na spolupráci. DevOps funguje jen tehdy, když vývojáři a operátoři sdílejí odpovědnost. To znamená, že vývojář nehodí „hotový kód" přes zeď, ale spolupracuje na nasazení. Zkuste společné on-call služby nebo týmové retrospektivy po incidentech. Cílem je, aby se chyby staly učebním materiálem, ne důvodem k obviňování. Toto je nejtěžší část, ale bez ní je DevOps jen prázdná fráze.
Když se rozhodnete přispět do open source, nejčastější chybou není nedostatek znalostí, ale špatný start. Místo abyste se vrhli na první issue, které uvidíte, začněte prozkoumáním projektu. Přečtěte si soubor s pokyny pro přispěvatele, pokud existuje. Většina větších projektů má jasně daná pravidla, jak vypadá dobrý pull request, jak psát commit messages a jaké testy se spouští. Bez této znalosti riskujete, že vaše práce bude zamítnuta, i když je technicky správná.
Po odeslání pull requestu očekávejte zpětnou vazbu, ať už pozitivní, nebo negativní. Není to osobní útok — code review je standardní proces. Reagujte na komentáře věcně, vysvětlujte svá rozhodnutí a nezdráhejte se klást otázky, pokud něčemu nerozumíte. Pokud vaše změny neprojdou, nevzdávejte to. Analyzujte, co bylo špatně, a zkuste to znovu s jiným úkolem. Každý pokus vás posune dál a příští příspěvek bude kvalitnější. To je celé tajemství úspěšného zapojení do open source.
Co se stane, když místo přesného data nabídnete rozpětí Místo jediného data nabídněte rozpětí, které je realistické. Například „dokončíme to mezi úterým a čtvrtkem". Tím zákazníkovi ukazujete, že počítáte s možnými komplikacemi, a zároveň mu dáváte jasný rámec. Vyhněte se ale příliš širokému rozpětí typu „do dvou týdnů", protože to působí nejistě. Ideální je rozpětí, které zahrnuje váš optimistický odhad a k němu přidává rezervu na nepředvídané události. Uvnitř týmu si pak nastavte interní termín, který je dřív než ten, který sdělujete zákazníkovi.
Základem je rozlišit odhad a závazek. Odhad je váš kvalifikovaný tip, závazek je dohoda, kterou potvrdíte. Když řeknete „bude to do pátku", zákazník to vnímá jako slib. Když řeknete „předpokládám, že to stihneme do pátku, ale potvrdím to ve středu", dáváte mu prostor i kontrolu. Tento rozdíl je zásadní: odhad prezentujte jako pracovní hypotézu, ne jako hotovou věc. Vyhnete se tak situaci, kdy zákazník staví své plány na vašem slibu, který nemůžete dodržet.
