Pred niekoľkými mesiacmi som mal s kolegom pracovnú diskusiu týkajúcu sa aplikácie, ktorú sme v tej dobe vyvíjali. Ešte v ten istý deň večer som si uvedomil, že táto diskusia bola ukážkovým príkladom rozdielneho spôsobu premýšľania: mňa, programátora s dôrazom na detail a presnú formuláciu problému a jeho riešenia, a kolegu obchodníka, ktorého hlavnou úlohou je osobná komunikácia so zákazníkom a ktorý by podľa môjho názoru ani nemal venovať čas tomu, aby sa snažil pochopiť mnohé z technických detailov.
Snažil som sa mu vysvetliť, že v kontexte našej aplikácie je projekt niečo úplne iné, než objekt. Na to som musel (treba čítať ako „mal prirodzenú potrebu“) použiť lineárnu algebru, vektorový priestor a pojmy lineárna závislosť či báza priestoru. Pre mňa je, zdá sa, takýto spôsob premýšľania prirodzeným. Spätne už však neviem povedať, či za to môžu roky štúdia na vysokej škole, kde sme sa algebru učili z knihy, v ktorej sa striedala definícia s vetami, dôkazmi a občasnou poznámkou či cvičením, alebo či som tak fungoval už aj predtým. (A to som ani neštudoval na matfyze, ale na elektrotechnickej fakulte.)
Pokračovali sme v diskusii na tému na čo je pri programovaní algebra? Mojou prvou odpoveďou bolo, že to pomáha premýšľať algoritmicky. Neskôr som si uvedomil, že dôležitejším je schopnosť premýšľať abstraktne.
Abstrakcia pri programovaní je veľmi dôležitá. Medzi veľkosťou aplikácie, požiadavkami na nové funkcionality a zmenou už existujúcich požiadaviek a medzi dôležitosťou abstraktného návrhu pritom existuje priama úmernosť. Rozsiahlu aplikáciu bez kvalitného abstraktného návrhu bude časom náročné udržiavať, rozširovať, a aj požiadavky na zdanlivo triviálne zmeny bude náročné implementovať.
Všetko toto smeruje k uznávaným a v praxi dobre overeným konceptom objektovo orientovaného programovania, návrhových vzorov či doménovo orientovaného návrhu. Programátor navrhne abstrakciu, teda modely a objekty, ktoré iba reprezentujú reálny svet a úlohu, ktorú sa snaží vyriešiť.
V programovaní sú detaily podstatné a dôležité. Počítač, ktorý vykonáva príkazy, teda napísaný kód, neodpúšťa chyby. Ako analógia mi napadajú rôzne formy umenia, ktoré je vysoko subjektívne, a ak by aj spisovateľ spravil gramatickú chybu, je možné, že časť čitateľov si to ani nevšimne. Odhliadnuc od niekoľko nepodstatných prípadov, ktoré spôsobujú skôr iba konflikty medzi spolupracovníkmi, ako napríklad „odsadenie tabulátorom, alebo medzerami? bodkočiarka na konci riadku?“, pri programovaní záleží takmer na každom jednom znaku.
Spoločný menovateľ? Abstrakcia. Vhodne navrhnutý software využíva viacero úrovní abstrakcie a striktne oddeľuje vopred dohodnuté komunikačné rozhranie medzi rôznymi komponentami aplikácie, a ich implementáciu. Vďaka takémuto prístupu sa aj programovanie, ktoré ako som už hovoril, neodpúšťa chyby, môže viac podobať na umenie a diskusia môže byť viac o tom, či je návrh zrozumiteľný, či je rozdelenie funkcionalít do tried či balíčkov dobré. Alebo, na analógii s populárne náučnou knihou, by sme sa mohli pýtať, či bol text rozdelený do vhodných kapitol a či čitateľ je schopný rozumieť textu a pochopiť myšlienku bez toho, aby musel niektoré časti čítať opakovane, alebo listovať v knihe sem a tam.
Vrátim sa na úplný začiatok, kde som písal o ukážkovým príkladom rozdielneho spôsobu premýšľania medzi mnou programátorom a kolegom obchodníkom. Každá z týchto rolí potrebuje inú mieru detailu. Programátor potrebuje napísať kód veľmi presne a podstatný je každý detail. Pre obchodníka je dôležité, aby vedel zákazníkovi popísať funkcionalitu produktu a detaily často nepotrebuje. Obaja však musia spolu komunikovať. Aby takáto komunikácia bola efektívna, je potrebné nájsť spoločný jazyk. Pomocou neho zapíšu rôznorodé požiadavky zákazníkov, a zároveň ho použijú namiesto príliš detailného a technického jazyka.
Z toho vyplýva, že abstrakcia neprebieha iba jedným smerom a neslúži iba pre programátora, aby pred obchodníkom skryl svoj vlastný kód. Abstrakcia slúži aj pre obchodníka, ktorý potrebuje okrem komunikácie produktu smerom k zákazníkovi komunikovať aj rôznorodé požiadavky smerom od zákazníkov smerom do vlastného tímu. Požiadavky od zákazníkov pôsobiacich v rôznych odvetviach síce môžu byť podobné, ale veľmi pravdepodobne sa budú líšiť v tom, ako ich zákazníci pri rozhovore s obchodníkom popisujú, akú legislatívu potrebujú zohľadniť a podobne.
Som presvedčený, že znakom dobrého produktu nie je len to, koľko zarobí svojim investorom, ale aj to, že je svojim používateľom naozaj prospešný a zjednodušuje im ich prácu; to, ako práca na ňom uspokojuje jeho autorov; to, ako rýchlo a jednoducho (a v konečnom dôsledku ako ekonomicky výhodne) je možné ho prispôsobovať pri zmenách prostredia, legislatívy a podobne. Na toto všetko je treba voliť správnu úroveň abstrakcie: skryť implementačné detaily, zovšeobecniť rôzne požiadavky, či pracovať a komunikovať tak, aby sme si všetci navzájom rozumeli. Abstrakcia je dôležitá.
