Jan Drábek

Velká část nás programátorů začínala postupným a samostatným učením někde v příšeří svého pokojíčku na prvních hobby projektech. Časem se z koníčků stávají první (malé) zakázky, projekty rostou a volby dalších technologií v podobě dalších jazyků a knihoven přicházejí…

Tento článek vznikl pro firemní blog Trigama International s.r.o., originál najdete zde.

Když jste jediný, kdo na daném projektu či zakázce pracuje a kdy vůbec pracovat bude, je to vlastně vcelku jednoduché. Prostě vyberete a použijete to, co se vám zrovna líbí, nebo zkrátka to, co vás náhodou „cvrnkne do nosu“. Proč to není moudré, se dozvíte v tomto článku.

Nejprve krátce o tom, co to vlastně technologie je – v podstatě je to veškeré SW i HW vybavení, které používáte k dosažení nějakého IT cíle. Patří mezi to zejména:

• Produkty – předpřipravené a znovupoužitelné více či méně samostatné produkty – WordPress, Drupal, Moodle a další.
• Jazyky – fundament základních nástrojů, jak psát aplikaci – PHP, Javascript, React, Python, Go a další.
• Knihovny – balík (zdrojových) kódů usnadňující realizaci konkrétních výpočtů a funkcí ve vaší aplikaci – Nette, Symfony, Bootstrap, Ublaboo Datagrid, jQuery, React, Angular JS či tisíce dalších malých JS knihoven z NPM.
• Návrhové vzory – způsob přemýšlení je také často opomíjená technologie v podobě know-how, osobně sem řadím i souborné (meta) návrhové vzory typu DRY, KISS apod.
• Nástroje – další nástroje, které nejsou zahrnuty v samotné aplikaci, ale používáte je pro sestavování a správu záležitostí kolem své aplikace. Například Composer, NPM, Gulp a další.
• IDE – speciální nástroj, který umožňuje kód psát, číst a chápat rychleji a lépe.

Volba každé technologie v projektu má vliv na řadu dalších věcí a jejímu výběru by proto měla být věnována náležitá péče. Tyto vlivy se dají rozebírat z celé řady úhlů, my typicky při našem vývoji volíme následující: přímé dopady na aplikaci, nepřímé dopady na tým.

Přímé dopady na aplikaci

O přímých dopadech použitých technologií se píše vcelku často, protože jsou takříkajíc „za rohem“. Ve zkratce jde především o následující:

• Bezpečnost – neohrozíme použitím vybrané technologie nějak data či funkčnost aplikace?
• Udržovanost – je technologie udržovaná a jsou chyby opravovány?
• Rozšířenost – je technologie natolik rozšířená, abychom mohli věřit v její rozvoj a údržbu?
• Vyzrálost – je technologie vyzrálá pro produkční použití?
• Chybovost – nestane se naše aplikace po použití náchylnější na chyby?
• Náklady vs. přínosy – kolik problémů použití technologie způsobí a kolik jich vyřeší či usnadní?
• Licenční přijatelnost – můžeme technologii legálně použít a nejsou zde nějaké nečekané dopady licence?

Tyto dopady by vás měly zajímat i v případech, kdy na projektech pracujete pouze vy, obzvláště pokud jde o aplikaci, kterou bude někdo používat – protože jako tvůrci jsme zodpovědní za její chování i selhání.

Nepřímé dopady na tým

Je zde ale i další kategorie dopadů zvolených technologií, o kterých se ale spíše nemluví, případně pouze okrajově. Přitom jejich vliv je sice nepřímý, ale přesto zřetelně viditelný a někdy až zásadní.

• Intuitivnost – dokáže kód používající příslušnou technologii upravit i člen týmu, který ji nikdy předtím neviděl?
• Dokumentace – je technologie dostatečně zdokumentovaná? Nebude dokumentace členy týmu frustrovat?
• Přehlednost – je aplikace díky použité technologii přehlednější a čitelnější pro co nejvíc členů týmu?
• Interakce s vývojáři – jsou vývojáři příslušné technologie normálně komunikativní a vstřícní, pokud jde o relevantní dotazy?
• Soulad s filozofiemi – zapadá do vašeho code stylu a vývojářských standardů? Je v souladu s návrhovými vzory a meta vzory? Neporušuje například DRY či KISS?
• Rozšiřitelnost – lze na technologii dále stavět a rozšiřovat ji?
• Příjemnost – je práce s technologií příjemná? Nebo se jí naopak každý chce vyhnout?
• Podpora kvality – je technologie dobrým startovním bodem pro kvalitnější kód?

Vypadá to vskutku intuitivně, často se ale tyto otázky při volbě technologií ignorují, což může vést k týmové frustraci i vyhoření. Proč je důležité je řešit, ukážu na konkrétní technologii.

Příklad z praxe

Před nedávnem jsem ve výše uvedeném duchu vyhodnocoval stylovací knihovnu Tailwind CSS, se kterou jsem se setkal na jednom menším projektu. Filozofie dané knihovny je přibližně následující:

• Nejprve se vygeneruje maximální CSS se všemi kombinacemi CSS property, barev, velikostí fontů, definovaných breakpointů atp.
• Následně vyvíjíte HTML tak, že namísto používání vlastních definovaných CSS tříd použijete „bg-white h-16 w-16 rounded-full“ (plně zakulacený box s bílým pozadím o 16x16 REM).
• Následně pustíte minifikační skript, který projde všechny vaše HTML soubory a všechny referencované třídy ponechá, zbytek odstraní.

K čemu to vedlo a jaké (by) to mělo dopady na tým?

1. Nepodporuje přehlednost
   Obsah není oddělen od stylování. Jednotlivé property z CSS souboru se akorát přesunuly do class HTML atributu. Víceméně jde tedy o stylování pomocí atributu style, s lehkou výhodou pro responzivitu.
2. Vytváří nesoulad s filozofiemi
   Kód výrazně narostl, a pokud máte opakované stylování například pro každou položku, musíte stylování opakovat nebo definovat třídu. Porušuje DRY a naše vidění KISS. Podpora opakovatelnosti stejného stylování sice lze realizovat, vyžaduje ale nějakou netriviální práci navíc.
3. Není intuitivní, přehledný a nepodporuje týmovou zastupitelnost
   Kodér, který šablonu použil, byl víceméně jediný, kdo do ní dokázal zasahovat.
4. Nepodporuje kvalitní budoucí kód
   Ad hoc zásahy ostatními vývojáři byly spíše ve stylu „shot-gun debugging“, než aby koncepčně upravovaly příslušnou šablonu.
5. Nezapadá do vašich návrhových vzorů a existujícího kódu
   Po napojení na dynamické formuláře a gridy už není možné používat smysluplně minifikaci, protože nedokáže spolehlivě najít použité CSS třídy v PHP souborech.

V jiných bodech knihovna Tailwind naopak excelovala, rozšiřitelnost a nastavitelnost má obrovskou a dokumentace je dobrá. Přesto se domnívám, že použití v našich týmech by vedlo k týmové frustraci, která snižuje produktivitu a může vést až k vyhoření jednotlivců i celých týmů.

Zde ještě o jednom paradoxu – totiž ono i nezvolení konkrétní technologie může mít stejné týmové dopady. Například máme projekt, ve kterém původně nebylo použito ORM, pouze DBAL, o tom ale víc až příště.

Asi si řeknete, že jsme použili kladivo tam, kde by stačil šroubovák… A máte naprostou pravdu. Právě to je jedním z poselství tohoto článku, spolu s tím, že možná váš tým prostě letí na (sonické) šroubováky, a ne na kladiva.