ObrázokV ktoromsi predchádzajúcom blogu som napísal, že komplexnosť v softvérových projektoch je ako cholesterol u ľudí. Neprichádza odrazu a vo veľkom, ale postupne sa gram po grame nabaľuje až jedného dňa je už neskoro. Nejako takto to niekedy vyzerá v softvérových projektoch. Denne prichádzajú zmeny a ak sa robia bez toho, aby sa uvážil ich širší kontext a urobia sa len tak, aby to fungovalo, skôr alebo neskôr začne byť systém menej a menej stabilný, ale hlavne omnoho horšie udržiavateľný. V čase, keď som túto myšlienku napísal, som ani netušil, že nájdem knihu, ktorá dokonale rozpitvá do posledného detailu túto tému. Code Simplicity od Maxa Kanat-Alexandra.

Jedno musím tejto knihe priznať a to, že dokázala pomenovať jeden z problémov vývoja softvéru pomerne presne. A ten problém je, že návrh softvéru je veľmi komplikovaná činnosť, ku ktorej prakticky neexistuje žiadna vedná disciplína. S komplikovanými procesmi sa dá stretnúť aj inde. Postaviť štyridsať poschodový mrakodrap alebo päťkilometrový most tiež nie je jednoduché. Rovnako nie je jednoduché urobiť operácie mozgu. Ale ako architektúra, aj medicína sú samostatné vedné odbory, kde vás takéto veci naučia.

Nie že by sa výpočtová technika na vysokých školách neučila. Ale častokrát vás naučia programovať, naučia relačné databázy a teóriu prekladačov. Návrh softvéru sa učí len veľmi málo alebo vôbec. Čiastočne sa to snažia nahradiť napríklad návrhové vzory, ktoré ponúkajú hotové riešenia na často opakujúce sa problémy. Ale to je len znova nejaká iniciatíva zdola, teda z každodennej praxe, ktorá sa snaží abstrahovať princípy a nejako ich popísať. Chýba tu snaha popísať návrh zhora. Teda začať abstraktnou teóriou a postupovať smerom nadol až do každodenného života.

Vlastne nie som úplne presný. Taká vedná disciplína existuje a volá sa Informatika (o rozdiele medzi informatikou a výpočtovou technikou som už písal kedysi dávno tu). Príkladom je formálna metóda – B metóda. Problém je, že tie postupy, ktoré Informatika navrhuje, sú tak ťažko použiteľné na každodenný život, že sa dajú použiť naozaj len tam, kde ide o život (riadenie dopravných prostriedkov, ktoré sú plné ľudí, alebo riadenie lekárskych prístrojov). Niečo, čo by naučilo robiť správne každodenné rozhodnutia programátora, ktorý sedí v štandardnej IT firme a programuje web, backend systém alebo dátový filter, tu chýba.

Maxove tvrdenie je tvrdé, ale má logický základ. Je to preto, lebo softvér sa narodil ako niečo malé a postupne začal rásť. Keď to bolo kedysi pár riadkov, ktoré písal jeden človek, o 30 rokov neskôr sú to celé tímy, ktoré píšu tisíce riadkov denne. A nikde medzi tým začiatkom a terajším stavom neprišiel bod, kedy by sme si povedali: „Ok, tak ako to bolo doteraz, to nejde. Poďme to robiť od začiatku a tak, ako sa má.“ Sme ako tá povestná žaba, ktorá vyskočí, ak ju hodíte do vriacej vody, ale ak vodu postupne prihrievate, tak sa uvarí.

Max sa snaží zadefinovať vedu návrhu softvéru. Robí to len na 90-tich stranách, čo je veľmi málo, ale aj napriek tomu má bod k dobru, lebo sa to naozaj snaží robiť ako vedu – definuje postupne pojem za pojmom a k tomu pridáva pravidlá. Návrh softvéru je podľa neho o každodenných rozhodnutiach (Vytvorím pre ten kód samostatnú triedu alebo nie?, Použijem alebo nepoužijem referenciu cez rozhrania? a pod.). To rozhodovanie sa musí niečim riadiť a on tvrdí, že by sa malo riadiť myšlienkou, že softvér vznikol, aby pomáhal ľudom a mal by byť vytvorený tak, že je ľahko udržateľný aj po dlhšej dobe.

Tá udržateľnosť je kľúčová, pretože autor tvrdí, že ak máte nejakú funkčnosť, ktorá potrebuje nejakú námahu na implementáciu, tak tá funkčnosť v sebe určite zahŕňa aj nejakú námahu na ďalšie udržiavanie. A práve tá druhá je dôležitejšia (pri dlhodobejších projektoch) ako samotná implementačná námaha.

Dobrý dizajn je niečo, čo výrazne redukuje námahu na udržiavanie softvéru. V tom sa opäť s autorom zhodneme, pretože ja rád tvrdím, že nie je problém naprogramovať ľubovoľný softvér. Môžete si vybrať ľubovoľnú technológiu a ako programátora môžete zvoliť niekoho aj menej skúseného. On vám ten softvér vyrobí. Čo umenie je, ak ste schopný vytvoriť softvér, ktorý sa aj o 3, 5, 10 … rokov bude spravovať aspoň rádovo rovnako jednoducho ako keď začínate. Videl som nejeden projekt, ktorý začítal bombasticky, nabitý pozitívnou energiou a všetkým tým vzrušením z nového, aby bol po pár rokoch ľudom prideľovaný skoro za trest.

Kniha sa neodkazuje na žiaden konkrétny programovací jazyk. Ak ešte nejaký neovládate, tak musíte siahnuť po niečom inom (alebo sa prihláste na vysokú školu). Táto kniha sa vám bude snažiť vysvetliť, že to vyzerá ako jednoduchá vec („Tu dáme takú a takú triedu, tak bude rozhranie a všetko to bude pod REST sieťovými službami…“) je v skutočnosti veda a mali by ste k tomu tak pristupovať. Že svätým grálom každého programátora je jednoduchosť. Robiť veci len tak zložité, ako je to možné a snaží sa vyhýbať rôznym pevným väzbám medzi komponentami. Lebo len jednoduchosť je to, čo dokáže zaručiť, že projekt bude udržateľný aj po rokoch vývoja.