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í…
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?
- 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. - 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. - 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. - 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. - 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.
Sdílet článek