Proč nepodcenit volbu technologie pro tým?

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.

 
22. 1. 2020 20:28 programming


Tagy

informace (20), návod (2), mysql (1), užitečné (6), internet (1), komix (99), humor (99), ironie (1), Bůh (2), škola (38), plánování (1), Čas (2), hříchy (1), otroctví (1), esej (4), Erasmus (24), project management (2), programming (16), teamwork (1), bad code (1), práce (1)

Hledání

Odběr zpráv

RSS feed Blog (RSS)