Když chce malíř vytvořit obraz (produkt) vezme štětec (nástroj) a namaluje ho. Jasné jako facka. Co ale vlastně dělá malíř, když vezme tužku a namaluje si nejdřív skicu?
Skica se tvoří stejně jako výsledný obraz, je sama o sobě obrazem ale ve skutečnosti je to nástroj, který autorovi pomáhá výsledný obraz vytvořit. Je mechanickým rozšířením jeho představivosti.
Tato dvojznačnost nástrojů je častá. Když se staví dům, je potřeba nejdřív postavit lešení, které samo o sobě vyžaduje stavařský um, zastalo by i nějaké z funkcí stavby, ale před dokončením je strženo. Dovolovalo jen zedníkům pokládat cihly výše, než kam dosáhnou.
Bohužel co je ve fyzickém světě vidět na první pohled je v myšlenkovém světě bez jednoduchých rozpoznávacích atributů mnohem nejasnější. Kdykoli dochází k mentální práci, podvědomě se předpokládá, že je to práce na výsledném produktu. A to nejen v programování. Ať už otevřete textový editor k sepsání dokumentu, IDE k napsání algoritmu nebo databázi ke psaní dotazů, tak se předpokládá, že výsledek je určen ke konzumaci zadavatelem nebo že je to alespoň část takového výsledku.
Dost se zapomíná na to, že na cestě k výsledku je potřeba vyrobit pomocné konstrukce v mysli samotného autora. Textový editor neslouží jen k sazbě dokumentů, ale i k organizaci a třídění poznámek, které v dokumentu budou. Stejně tak programovací jazyk kromě svého primárního účelu pomáhá rozpoznávat abstrakce a nebo databáze pomáhá s odhalováním souvislostí v datech.
Proč to rozebírám? Protože zda od práce s nástrojem očekáváme hodnotu pro autora nebo zákazníka ovlivňuje úplně všechno. Jaké nástroje si vybíráme, co je na výsledku důležité a co, s kým a jak sdílíme. Například u dokumentu pro zákazníka je důležitá typografie, firemní branding, změnová tabulka, formální revizní proces, prostě vše, co zajišťuje profesionální dojem. Naproti tomu pro organizaci myšlenek, které mají tvořit obsah toho dokumentu, je důležitá velká informační hustota, neustálá kolaborativní dostupnost ke čtení i zápisu, jednoduchost provádění změn, anotace, prostě vše, co obohacuje proces tvorby.
Ty první požadavky nejlépe splňuje Word na sdíleném úložišti, ty druhé markdown texťák v gitu. Stejně je možné proti sobě postavit třeba aplikační servery a REPL nebo BI systémy a Jupyter notebooky. Kámen úrazu je zda, kdy a jak přecházet z jednoho módu do druhého. Ideální by byly samozřejmě nástroje, který dovolují plynulý přechod od iniciálních nápadů k sofistikovanému výsledku a zase zpátky pro další iteraci. Kdo ale někdy zkusil pracovat s Wordem a jeho záznamem změn nebo z druhé strany s generováním .doc souborů z markdownu, ten ví, že to je utopie, ke které se dá jen z jedné nebo druhé strany přibližovat různými sadami kompromisů - One Note, Google apps, AsciiDoc, mind mapy…
V reálném životě řešení tohoto problému neleží v technologii. Malíři se netrápí s tím, že nakreslit skicu je vyhozená práce, když jí nebudou prodávat a výsledný obraz bude na jiném plátně. A stavbyvedoucí se nenaštve na dělníky proto, že se v jejich lešení nedá bydlet. Ekvivalent takových blbostí se při vývoji software děje zoufale často. Jako u každé frustrace je realističtější změnit očekávání, nikoli výsledek.
Abstrakce je potřeba objevovat, ne designovat
Je možné namítnout, že algoritmizace je, na rozdíl od psaní volného textu, inženýrská činnost. Takže ačkoli paralela mezi obrazem a skicou může ještě trochu platit pro textové editory, tak pro programovací jazyky a prostředí už ne, protože tam by se mělo pracovat v mantinelech jasného plánu a ověřených návrhových vzorů.
Takový předpoklad stojí na představě tvorby software jako aktu designu, tedy že autor formuluje problém za pomoci abstrakcí, které si arbitrárně vybere. To je ale podle mě kořen většiny problémů s overengineeringem a jiných diskrepancí mezi vyvinutým řešením a realitou. Mnohem přínosnější je brát vývoj software jako akt objevování, při kterém se snažíme odhalit abstrakce, které jsou v problému inherentně přítomné.
Exemplární systézou všech dosavadních myšlenek je pochopení úlohy refaktoringu. Naivní úhel pohledu jej může považovat za práci na produktu s cílem zvýšit jeho kvalitu a tím i cenu. Realný význam však za mě dokonale shrnul Kent Beck:
My code can’t be tidier than my thinking. The purpose of my tidying is to clarify my thinking by manipulating the code. The code ends up better, but because I understand more not because I somehow forced it to be better in spite of my confusion.
— Kent Beck (@KentBeck) June 28, 2019
Refactoring je nástroj, který asistovanou externalizací vnitřních myšlenkových procesů umožňuje uplatnit schopnosti našeho mozku v problematice mnohonásobně přesahující jeho kapacitu. Je to skica i lešení pro myšlení v jednom.
Douška
Plný rozsah a význam tohole konceptu jsem si uvědomil až ve chvíli, kdy jsem četl knihu o teorii kategorií. Můj intelekt na to hrubě nestačil a v okolí jsem neměl nikoho, kdo by mi poradil. Po čase jsem dokonvergoval k tomu, že otázky, které jsem měl, jsem zformuloval v Haskelu a jelikož je Haskel sám o sobě kategorií, nechal jsem jeho kompilátor, aby mi odpověděl. Buď se mnou souhlasil, nebo mi vysvětlil, co jsem nechápal.
Byl to podivný pocit změnit mentální představu programovacího jazyka z nemyslícího sluhy na chápajícího učitele.