Zpět

Boomer development.

Upozornění: Berte následující článek s nadsázkou. Když mluvíme o bůmrech, nemyslíme tím nutně specifickou věkovou kategorii. Spíše lidi, kteří používají překonaný styl programování a těžko se jim zvyká na cokoliv nového.

Je těžké přiznat si, že celý život něco dělám špatně. Obvzlášť, když mě práce, kterou jsem postavil na chybách živí.

Přepisovat kód nováčka je bolest. někdo napsal hromadu kódu, aniž by věděl, jak bude fungovat ve větším měřítku. Často (ne vždy) si ale rád nechá poradit. Bůmr oproti tomu věří svému špatně napsanému kódu. Dlouhé hodiny debugingu přijal za fakt nezbytně spojený s programováním. Uvěřil mýtu, že programování je z 80% debugging a dostává za něj dobře zaplaceno. Ve svém kódu se vyzná jen on, a občas ani to ne. To se mu občas i líbí. On je pán kódu. On je ten, za kým všichni chodí se zeptat jak to funguje. Nikdo jiný totiž neví. A tak ostatní developeři často programují oklikou. Mají strach se dotknout křehkého kódu, ve kterém se nevyznají. Nechcou být ti, kvůli kterým spadne aplikace a tak duplikují kód , reimplementují existující logiku a vytváří si uvnitř aplikace vlastní mikrokosmos, ve kterém se zase vyznají jen oni sami. Aplikace je rozfragmentovaná. Globální změny se musí reimplementovat na několika místech, na psaní testů kvůli toho není čas. Refaktorů se všichni bojí jako čert kříže a tak se z aplikace brzy stane neudržovatelný chaos. Development se zastaví, klientovi dojde trpělivost a zakázku předá někomu jinému.

Lze vůbec bůmra přesvědčit o jeho chybě? Těžce. Refaktorovat celý projekt tak, aby byl napsaný dobře a snadno se rozšiřoval je na dlouho a člověk musí být u celého toho procesu aby pochopil jeho výhody. Bůmři jsou často v pozici autority a tak potřebné změny často ani neschválí. V mnoha dalších případech si pak pouze hrají na svém písečku a odmítají se podílet na jiné práci než jejich přidělené části aplikace.

Nahraditelnost

Programování je ale skupinová činnost. Vyžaduje kooperaci na těch samých částech kódu nejen proto, aby každý developer znal použité funkce a classy, díky čemuž je posléze může použít ve svých částech aplikace, ale také proto, aby když jeden developer odejde na dovolenou, nebo do věčných lovišť, druhý ho mohl snadno nahradit.

Standardy kódu

Každý program by tudíž měl vypadat tak, jako by ho psal jeden programátor, tak, ať na žádného vývojáře nečeká nechtěné překvapení ve způsobu jak je s funkcemi a proměnnými nakládáno.

K tomuto účelu slouží coding standards - sada pravidel, která zajistí konzistentní styl kódu. V praci je tento styl v absolutní většině případů vynucován balíčkem jménem eslint. Ten nejen zajistí konzistentní styl kódu, ale rovněž zamezí vzniknutí některých častých chyb.

Pojďme si ale povědět o stylistyckých chybách, které eslint neodhalí.

Názvy proměnných

  • Názvy proměnných - Bůmři volí kryptické a zkratkovité názvy proměnných, které chápou pouze oni sami. Rádi k nim přidávají různá podtržítka a dle libosti střídají casing. To co nenapíšou do názvu proměnné pak dohání v obrovských komentářích, které mnohdy připomínají román, nikoliv technickou dokumentaci. Správný název proměnné je však tak dlouhý, aby objasnil její význam i bez dokumentace. Proměnná si pak bere svou dokumentaci všude sebou ve svém názvu.

  • Proměnná by rovněž, pokud je to možné, měla říct něco o svém typu. Osvědčila se mi dvě pravidla. Proměnné typu boolean jsou otázky na které lze odpovědět ano/ne. Proměnná typu array je psaná v množném čísle.

  • Pravidla casingu jsou následující: Proměnné a funkce camelCasem. Classy, Interfacy, Typy, Enumy PascalCasem a konstanty UPPER_CASE_SNAKE_CASEM.

  • Co se JSDoc komentářů týče, je lepší se jim úplně vyhnout, většinou totiž dopadají následovně:

/**
 * @param {string} title - title
 * @param {string} author - author
 */
function Book(title, author) {
  return `${title}: ${author}`
}
  • JSDoc bezpochyby měly svůj smysl v dobách, kdy se používal neotypovaný Javascript. Tyto doby už jsou ale dávno pryč a velké (a i malé) projekty ovládnul typescript, který, pokud jej člověk umí používat, perfektně nahradí veškerou další dokumentaci a navíc jeho typová kontrola zachytí hromadu chyb.

Principy programování

  • Tyto principy programování jsou staré skoro jako programování samo. Přesto je většinou právě bůmři neznají. Když jim je budete citovat, dokonce se vám vysmějí, že jsou vhodné leda tak pro akademické plky, nikoliv reálný svět. Vtip tohoto argumentu spočívá v tom, že tato esenciální pravidla programování se na vysokých školách rozhodně neučí.

  • DRY - Aneb Don't Repeat Yourself. Pravidlo jednoduše říkající, že než aby jste napsali dva naprosto stejné kusy kódu, raději je abstrahujte např. do funkce.

  • KISS - Keep It Simple Stupid. Nesnažte se tvořit zbytečně komplikované konstrukce jen aby jste ušetřili pár řádků kódu. Nesnažte se vytvářet zbytečně komplikované konstrukce vůbec. Napiště svou logiku tak, aby byla pochopitelná každým.

  • YAGNI - You Aren't Gonna Need It. Nepiště funkce a kód jen proto, že by se mohl hodit. Nebude se hodit. Nevíte co přijde za pár hodin. Klient se může ze dne na den rozhodnout, že bude provedena změna, která bude znamenat radikální přepis kódu a vaše práce přijde vniveč. Dokonce vy sami můžete přijít na to, že jste se v řešení problému vydali špatnou cestou a hromadu kódu budete muset smazat. Piště jen ten kód, který budete nezbytně potřebovat.

K tomuto bych dodal ještě pár pravidel slušného chování: Nikdy nepřidávejte zakomentovaný kód. Nikdy nepřidávejte nepoužité proměnné. Vždy si po sobě kód přečtěte, než ho pošlete na Pull Request. Vždy provádějte code review.

Historické metody

  • BEM, neboli Block Element Modifier je metoda s libostí používána Bůmrama pro zahlcení css souborů kvantem textů, ve kterých se špatně orientuje. Pro “standardy” typu BEM není v moderním vývoji místo. Každý moderní framework obsahuje komponentový systém, ve kterém si jednotlivý komponent nese jak svou logiku, tak i vzhled; a jeho styly jsou kompletně odděleny od zbytku aplikace. Tím je zabráněno jmenným kolizím a na těch pár řádcích BEM postrádá smysl. Rovněž se stalo standardem, že se používají css preprocessory, které umožňují vytvořit přehledné, do sebe zanořené třídy, např SCSS.

  • JQUERY je další relikt z doby Bůmra, kdy se celá aplikace narvala do jednojo obrovského globálního prostoru a proměnné se mezi sebou bily a znemožňovaly úspěšný vývoj a debugging. Moderní frameworky mají separovanou logickou a zobrazovací vrstvu a většinou znesnadňují přímý vstup do zobrazovací vrstvy a naopak implementují reaktivní systém, který tuto vrstvu váže na logiku a dynamicky jí umožňuje reagovat na změny v ní. Tato separace usnadňuje debugging a dělá kód přehlednější. JQUERY takovou separaci nikdy nemělo a tudíž nikdy nebylo vhodné na větší projekty a i v těch menších dostává od moderních frameworků na frak.

Funkcionální programování

Bůmr píše objektově orientovaný javascript. Na tom by samo o sobě nebylo nic špatného. Bůmr ale píše objektově orientovaný špagetový kód, ve kterém se velmi špatně hledají jakékoliv bugy. Když někdo mluví o tom, že 80% jeho práce je hledání chyb v kódu, s největší pravděpodobností ještě neslyšel o funkcionálním programování.

Přitom není třeba učit se celé nové paradigma, stačí se naučit pár vychytávek, které funkcionální programování přineslo a čas strávený nad bug fixingem se razantně zkrátí. Může k tomu pomoci i dobře nastavený eslint.

Psát své funkce tak, ať nemění globální stav, ani své vstupní argumenty a pouze vrátí novou hodnotu znemožňuje bugům se šířit globálním prostorem. Zavrhnout for a while loopy pro .map, find, filter a reduce metody pole. Omezit psaní class a seznámit se s knihovnou typu lodash nebo ramda člověku zachrání čas i peníze.

Testy

Testy, testy, testy. Každý větší software musí být řádně otestován abychom měli jistotu, že žádná změna nerozbije existující funkcionalitu. Mantrou bůmrů je, že na testy není čas. Často je to proto, že se musí fixovat bugy, které vznikly kvůli neexistujícím testům. Chceme li psát rozsáhlý software, musíme rovněž psát rozsáhlé testy. Testy otestují celou aplikaci za několik desítek minut. To žádný tester nezvládne.

Příliš brzská optimalizace

Další způsob, jak je bůmr schopen znesnadnit vývoj je optimalizace kódu. Člověk by si řekl, že ta sama o sobě nemůže být špatná, ale opak je pravdou. Optimalizace kódu přichází v moment, kdy je kód pomalý. Nikoliv dříve. Optimalizovaný kód totiž často bývá méně přehledný a tudíž se hůře rozšiřuje. Dnešní počítače jsou natolik výkonné, že urychlit kód o pár instrukcí reálně znamená záchranu několika milisekund pro uživatele, kdežto napsat kód čistě na úkor rychlosti znamená záchranu několika hodin či dní developerského času a ten má mnohem větší hodnotu.

Staré rčení říká: Z čistého kódu je snadné udělat rychlý. Z rychlého kódu je těžké udělat čistý. A proto optimalizace má smysl až v ten moment, když narazíme na uživatele, kteří mají problém použít některou část aplikace.

Důležité je také si uvědomit, kde je třeba optimalizace provádět. Největší úzká hrdla jsou zápisy na disk a network requesty. Vyjímečně se stane, že musíte optimalizovat prováděný kód a např. měnit metody pole na loopy (mě se to nestalo nikdy). Co se webových aplikací týče, ve většině případů se optimalizace týkají network requestů a jejich správného bundlování a odesílání. Vtipné je, že právě tuto esenciální informaci vás na škole nenaučí. Místo toho se tam učí tisíc a jeden sortovací algoritmus, ačkoliv v praxi reálně použijete pouze ten vestavěný.

Realistické odhady a sliby

To nejhorší co ale dělá bůmr je, že slepě poslouchá a slibuje nemožné.

Project manažer často nechápe potřeby developera. Jeho priority jsou krátkodobé jak u malých aplikací tak u těch velkých. Často vnímá úspěch příštího dema jako větší prioritu než úspěch aplikace jako celku. Příkladem budiž například hra Cyberpunk 2077. Vývoj celé hry byl v jeden moment zastaven aby se 3 měsíce pracovalo na falešném demu. Jaké zklamání pak čekalo fanoušky, když přišli na to, že hra ani zdaleka není tak propracovaná jako to co viděli v demu. Podobné excesy se ovšem dějí i na jiných místech. Ve své kariéře jsem se několikrát bil do hlavy za to, že jsem poslechl project manažera a odbil svoji práci. Dnes se tomu ve většině případů snažím vyhnout. Řeknu si o svůj čas. Popřemýšlím nad nejlepší možnou inplementací daného problému a napíšu testy. Čas, který bych pak strávil nad vracejícími se bugy strávím nad inplementací nové fičury. Umím říct ne, když vím, že se práce nestihne a ještě větší NE, když mě nutí, abych svou práci odbil. Ne vždy to jde, ale VĚTŠINOU to jde.

Závěrem

A to bych chtěl vzkázat i tobě, čtenáři. Dělej svou práci tak, ať jsi na ni hrdý a to se ti pak vrátí. Nakonec i ten projekt manažer bude rád za tento přístup. A tebe pak práce bude víc bavit.

Slow is smooth. Smooth is fast.