Příliš mnoho bludů

Bronislav Klučka on 05. 3. 2025 21:12

Napadlo vás někdy...

Někteří lidé si myslí, že dependency injection by mělo být použité všude a je nejnovější technologií. Podobně, někteří lidé si myslí, že layered architecture vyřeší všechno a další si myslí to samé o microservices.

Někteří lidé si myslí, že serverless je vhodné vždy, další, že vše by mělo být napsané v Rustu na backednu a Vue3 na frontendu.

Někteří lidé si myslí, že stačí na jednoho člověka nalepit Product Owner, na jiného Scrum Master, poslat je na 2denní certifikační kurz, mít standupy, reviews, retrospektivy, používat Jiru a máte agilní team, který praktikuje Scrum.

Napadlo vás někdy...

Toto vše má jeden společný atribut: nepochopení hodnot a principů.

Pyramida

Na základě čeho děláte rozhodnutí a co ho ovlivňuje? Co dělá jedno chování konzistentní a jiné nekonzistentní?

Hodnoty

Hodnoty reprezentují základní nastavení. Vše co děláte filtrujete těmito hodnotami. Hodnoty definují, co je v pořádku a co není v pořádku a reprezentují nejdůležitější a chtěné atributy toho, co a proč děláte a kým jste. Jsou motivací na pozadí všeho.

Jsou odpovědí na otázku, "proč děláte to, co děláte".

Principy

Principy jsou základní pravidla, která podporují hodnoty, a nastavují hranice. Jsou pravdou za vaším běžným denním chováním. Každá praktická akce, kterou provedete, obsahuje tyto principy.

Jsou odpovědí na otázku, "jak děláte to, co děláte".

Praktiky

Vaše běžné chování na denní bázi.

Nástroje

Nástroje používáte pro vaši denní operativu.

Nástroje musí odpovídat praktikám, které jsou založené na principech, které odrážejí hodnoty.

Cargo kult

Cargo kult je asi nejrozšířenější a nejnebezpečnější blud, se kterým jsem se setkal. Název pochází z chování kmenů v Pacifické oblasti během druhé světové války. Během války, armáda U.S.A. vytvořila na ostrovech v Pacifiku základny. Původní obyvatelé viděli lidi se sluchátky na uších jak mávají vlajkami a pak dorazil náklad (cargo) letadlem.

Poté, co armáda odešla, původní obyvatelstvo začalo nosit na uších kokosové skořápky, mávat látkou a stavět přistávací plochy. Nerozuměli tomu, jak letectvo funguje, proč vojáci dělali, co dělali, nebo proč náklad vůbec dorazil. Věřili, že napodobováním chování dosáhnou stejného výsledku - dorazí náklad.

Kolik chování je jenom imitace? Vidíme někoho něco dělat, přečteme si článek či o někom / něčem, slyšíme a napodobujeme chování bez pochopení hodnot a principů, na kterých je daná věc založena. Bez pochopení základů "proč" a "jak".

Zlaté kladivo

Termín zlaté kladivo označuje nadužívání specifického nástroje nebo praktiky na vyřešení všech problémů.

Měli bychom používat SPA založené na Vue na všechno? Měli bychom? Proč?

Měli bychom použít layered architecture na backend? Opravdu? Proč? Proč jsme si vybrali tento styl a ne jiný? Máme důvod, nebo je to pro to, že to "takhle děláme vždycky"?

To nejhorší, co může developer tvrdit je "Dělám to takhle vždycky už 20 let.". Jediné, co mi to řekne je, že se za 20 let nic nového nenaučil.

Stříbrná kulka

Termín stříbrná kulka popisuje iluzorní představu, že existuje jednoduché řešení pro komplexní problém. Existovat může, ale ne proto, že si to někdo přeje.

Potřebujeme více zákazníků? Přidejme více cool tlačítek do naší aplikace!. Nicméně neexistuje korelace mezi počtem featur a úspěchem aplikace. Všimli jste si někdy, jak jednoduchý je GMail nebo Netflix?

Potřebujeme lepší software. Musíme najmou lepší developery. Možná ano, možná ne. Jsou developeři opravdu důvodem? Hledali jste důvod?

Potřebujeme lepší software. Musíme najmou lepší product managery a ownery. Možná ano, možná ne. Jsou PM/PO opravdu důvodem? Hledali jste důvod?

Tvorba komerčního software je komplexní disciplína. Neexistuje žádné kouzelné řešení všeho.

Více příkladů

Co takhle jeden technický a jeden organizační?

Dependency injection

DI existuje pro řešení specifického problému: možnost poskytnout funkcionalitu bez toho, aby konzument dané funkcionality věděl, odkud daná funkcionalita pochází. Konzument není zodpovědný za její vytvoření a neměl by být. Například logování na aplikační úrovni. Funkce a třídy by neměli vědět, kde se "Logger" vzal, jak funguje, kdo ho vytváří a uvolňuje. Jediné, co potřebují vědět je, že existuje nějaké rozhraní (interface), který poskytuje logovací funkcionalitu.

Jak se DI běžně používá? Řekněme, že máme modul, který má na starost uživatele. Vytvoříme controller, service, repository a model vně tohoto modulu v DI kontejnery na aplikační úrovni a složíme vše postupně pomocí DI. Moje otázka zní: proč? Proč aplikační úroveň ví, jak funguje interní struktura modulu? Proč je jeden DI kontejner pro celou aplikaci? Proč definice "DI" pro modul uživatelů je vedle definice "DI" pro například fakturační modulu? Co mají ty dva moduly spolu společného? Neměl by být modul zodpovědný za vlastní funkcionalitu bez toho, aby interní strukturu zveřejnil? Neměla by service vědět, jaký přesně repositář potřebuje? Proč je definován z venku? Proč definujeme "DI" jako třídy místo minimalistických interfaces? Proč předáváme "DI" v konstruktoru i když s danou přijdou pracuje jen jedna metoda:

Proč? Protože všichni to tak dělají.

Scrum

Agilní vývoj software se stal módou. Stal se produktem, který prodávají konzultanti, kteří nikdy žádný projekt nevedli a brandem, který firmy hrdě hlásí aby vypadali moderně a dynamicky. Jak se potom dělá Scrum? Management definuje priority ("zákazníci jsou hloupí, s těmi nemluvíme"), management definuje timeframes ("developeři jsou hloupí a nerozumí byznysu") a i to, jak mají dělat svoji práci ("na psaní testů nemáme čas"). Developeři mají štěstí, když mohou ovlivnit scope toho, co se vejde do sprintu... občas... a zákazníci mají štěstí, když product manager (nebo někdo jiný) ve slonovinové věži zvažuje jejich potřeby.

Proč je Scrum nejoblíbenější? Není nejlepší agilní framework, ale je to nejlepší volba, jak se tvářit agilně.

Co hodnoty a principy agilního vývoje software? Kdy naposledy jste je četli?