Když se k projektu po půl roce vrátíte a nepoznáváte vlastní kód, problém nebývá v tom, že jste zapomněli syntaxi. Problém je v tom, že jste při psaní nemysleli na člověka, který to bude číst příště. A tím člověkem budete nejspíš vy. Špatně zvolené názvy, příliš dlouhé funkce a moduly bez jasných hranic dělají z každé úpravy detektivní práci. Není to otázka talentu, ale rozhodnutí, která děláte při každém commitu.

Konvence pojmenování nejsou byrokracie. Pokud máte v jedné části kódu getUserData, jinde fetch_user a ve třetí loadUserInfo pro totéž, každý nový člověk v týmu stráví hodiny hledáním rozdílů, které neexistují. Držte se jedné konvence napříč repozitářem a názvy pište tak, aby odpovídaly na otázku „co to vrátí“ nebo „co to udělá“. Pokud si nejste jistí, jak na to, vyplatí se projít si materiály o tom, jak psát čistý kód v JavaScriptu, kde najdete konkrétní pravidla pro pojmenování proměnných, funkcí i tříd. Rozdíl poznáte už při první code review.

Velikost funkcí je druhá věc, která rozhoduje o tom, zda kód přežije. Funkce na sto řádků se šesti úrovněmi vnoření se nedá testovat ani ladit. Rozdělte ji na menší celky, každý s jedním jasným úkolem. Když funkce dělá tři věci, pravděpodobně ji budete muset při každé změně přepisovat celou. Menší funkce se snadněji pojmenovávají, snadněji se testují a hlavně se v nich rychleji najde chyba. Není to o estetice, je to o tom, kolik času strávíte opravami.

Hranice modulů jsou poslední vrstva, na které se láme udržovatelnost. Modul, který importuje deset dalších a sám je importován dvaceti, není modul, ale uzlik. Definujte, co má být veřejné a co zůstane uvnitř. Exportujte jen to, co skutečně potřebujete, a zbytek držte skrytý. Když se za půl roku vrátíte, poděkujete si, že jste tenkrát strávili hodinu navíc nastavením jasných hranic místo toho, abyste je teď hledali v tisících řádcích.