Georgik

Marti Malý napísal vynikajúcu glosu, ktorú by si mala väčšina softvéristov zavesiť nad počítač.

Odporúčam! Glosu nájdete na stránkach zdrojak.cz: Uživatelé nejsou programátoři!

Článok zachytáva jednu veľmi podstatnú vec: Softvér je určený pre niekoho a autor nemusí vôbec patriť do cieľovej skupiny.

Zoberte si marketing. Marketér/obchodník musí hneď na začiatku vedieť akej skupine chce produkt predať. Podľa toho vyrobí kampaň a zvolí štýl komunikácie. V softverárčine to vôbec nie je samozrejmé. Veľké množstvo aplikácii a programov vôbec nemá definovanú cieľovú skupinu. Prípadne cieli na informatikov. A výsledok?

Fatal total error. Uživatel NULL provedl neplatnou operaci #1241.

Update: Ďalšia dobrá reakcia na túto tému je na blogu Schidlo.cz.

Á! Spravíme skvelý softvérový produkt! Super! Dáme tam autentifikáciu, notifikáciu smskami, spravím registráciu cez web formulár, kde bude administračné rozhranie. To všetko bude podporovať single sign-on. Samozrejme nesmú chýbať grafy na hodnotenie a reportovací systém, ktorý generuje všetko v PDF. Ešte to napojíme na možnosť platenia cez Paypal. Administračné rozhranie, na to nesmieme zabudnúť. Hlavne to musí byť user friendly. A ešte tam pravidelne sa budú zobrazovať výsledky z burzy a futbalových zápasov a bude tam podpora pre stromové vyhľadávanie v kategóriách. A to ešte napojíma na podnikový SAP. Hlavne tam ale musí byť táto enterprise komponenta, ktorá je totálne kúl a umožňuje generovať OLAP. A všetko to pobeží na cloude.

Uf?

Rozumiete tomu?

Za ako dlho dokážete vyvinúť takýto produkt?

Vážne, za ako dlho? Manažér sa vás pýta na časový odhad, tak mu nejaký dajte. Veď sa v tej oblasti predsa vyznáte.

Neviete? Ale veď je to úplne jasné. Fakt neviete? Za ako dlho sa dá vyvinúť takýto produkt? Rozmýšľajte, rozmýšľajte…

Ešte stále neviete?

Správna odpoveď! Uvedený príklad je dokonalou ukážkou feature soup. Pokiaľ začnete vyvíjať takýto produkt, tak si pripravte poriadny balík peňazí. Vlastne nie. Pripravte si dva. Jeden použijete na sponzorovanie vývoja a druhý si necháte ako rezervu na doťahovanie aspoň základnej sady vlastností.

V čom je problém?

Je to predsa tak jednoduché. Požiadavky uvedené na začiatku článku vôbec nie sú zadaním, je to čistý chaos.

Dobre, ale my potrebujeme nejako produkt vyvinúť. Čo s tým?

Jedným z možných prístupov je využiť princíp: Minimum feature set. V preklade: minimálna sada vlastností.

Pointou je zamerať sa na minimálne množstvo vlastností, ktoré sú kľúčové pre produkt a pracovať na nich.

Je dôležitá integrácia so SAPom? Prinesie nám niečo? Nóo to by bolo strašne kúl, ale nie. Preč s tým. Potrebujeme multidimezionálny OLAP? Nie? Preč s tým. Atď.

Proces minimalizácie nepodstatných vlastností  rozhodne nie je jednorázová záležitosť. Prehodnotenie by malo prebiehať opakovane, rádovo v týždňových iteráciach. Podpora pre minimalizáciu je často priamou súčasťou agilných metodík, ako napríklad SCRUM.

Dokonca aj Freddy Mercury na túto skutočnosť upozorňoval: Too much features will kill you.

Na SE-Radiu som narazil na jeden veľmi dobrý diel podcastu – Software Archeology s Daveom Thomasom, hovoril o softvérovej archeológii. Tento diel je podľa mňa esenciálny a softvérová archeológia by mala byť súčasťou vývojárskych kurzov.

Dave rozdelil softvérovú archeológiu na dve skupiny. Prvá skupina sa zaoberá výhradne len čítaním a snahám porozumieť dávno zaniknutým vývojárskym civilizáciam. Vyžaduje to trpezlivosť, znalosť jazykov a technológii.  Druhá skupina zahŕňa už aktívny prístup ku kódu a jeho modifikácie.

Softvérová archeológia je celkom nešťastne zamieňaná za prístup Indiana Jonesa, teda zahrabať sa do kódu a víťazoslávne z neho vytiahnuť artefakty. Artefakty sú dôležité. Avšak tak ako v archológii, to podstatné spočíva v snahe porozumieť kontextu a pochopiť kultúru.

Dave spomínal jednu zaujímavú techniku: zobrať zdrojový kód, otvoriť ho v editore a zmenšiť písmo na 2px. Stratí sa síce čitateľnosť, ale na povrch vypláva štruktúra kódu. Dokonca je ľahko odpozorovateľné, ktorý kód bol skopírovaný. Pri tak malom písme začnú byť zjavné opakujúce sa vzory v štruktúre kódu.

Dobrá bola aj jeho poznámka k písaniu dokumentácie. Pri archeologickej výprave je dôležité si uvedomiť, že dokumentácia klame. Často sa stane, že po zmene kódu už nie je aktualizovaná. Siahodlhé litánie v docstringu funkcie sú absolútne zbytočné, pretože sa nikto neunavuje to opravovať.

A teraz jeden veľmi zlomový postreh k písaniu dokumentácie v kóde: Pokiaľ dokumentujete ČO funkcia robí, tak je to zbytočné, tieto informácie odvodíte z kódu a z parametrov. Samozrejme krátky náčrt sa hodí, ale nemá význam popisovať všetko a podrobne. Dôležité je dokumentovať PREČO funkcia robí, to čo robí. Relatívne malý rozdiel v písaní textu, kompletné mení jeho kvalitu.

Pokiaľ neviete napísať PREČO funkcia má vôbec niečo robiť, nie je náhodou zbytočná? Nemáte náhodou nejasné zadania? Viete vôbec prečo to celé píšete? Tento prístup veľmi pripomína knihu od Simona Sineka – Start with Why.

Podľa Davida sú veľmi dôležité testy. Pretože testy, na rozdiel od dokumentácie, tak výrazne neklamú.

Pokiaľ sa niekto vydáte na púť archeológa, jednoznačne musíte byť vyzbrojený grepom. Asi najdôležitejší parameter grepu je pre archeológa -v, ktorý neguje výsledok vyhľadávania.

grep -r artefakt * | grep -v Indiana

Uvedený príklad vám pomôže násť všetky riadky so slovom artefakt, pričom tam nebude slovo Indiana.

Pokiaľ aktívne modifikujete kód, tak ako správny archeológ si najskôr nachystáte svoje prostredie a dáte kód do version control (napríklad Git).

Teraz sa môžete pustiť do modifikácii a testovania. Pokiaľ softvér vyžaduje veľa závislostí, uistite sa, že máte bootstrap skript, ktorý vám umožní OPAKOVANE vytvoriť prostredie pre archeologické pokusy. Ak takýto skript neexistuje, je vašou úlohou ho zostaviť. Vývojár/archeológ, ktorý príde po vás, vám nechá vyrobiť minimálne sochu na vašu počesť.

Kód je síce digitálny, ale hnije. Pokiaľ necháte rok stáť kód bez údržby, tak vám proste zhrdzavie.  Je veľmi dôležité si tento fakt uvedomiť. Rozbehnutie zhrdzaveného a zhnitého kódu môže stáť niekoľko dní práce. Dokonca v prípade, že neexistuje bootstrap skript, tú starú herku ani nerozbehnete.

Dave odporučil začínajúcim arechológom, aby si prešli kód interpretera pre jazyku, v ktorom píšu. Napríklad Perl, Python, Ruby alebo PHP. Takáto znalosť umožní lepšie pochopiť fungovanie a štrukturovanie kódu.

Z podcastu som vypichol tie body, ktoré ma najviac zaujali. Určite odporúčam, aby ste si vypočuli tento diel o Softvérovej arecheológii. Ušetrí vám to hodiny frustrácií z nezrozumiteľného kódu.

Niekedy to v archeológii môže dopadnúť aj takto – utekajúci developer opúšťa na svojom prskolete rútiace sa dátové centrum.

Ej bisťu. Tuto za kopčekom, hneď vedľa dedinky v údolí, je Hybe. A tam Pacho Hybský zbojník.

http://www.youtube.com/watch?v=y7teLUbAURA

“Baúúú! Vaúúú!”

“Pánske vozy idú! A veľkú ťrchu nesú! Tam musí byť dukátov!”

“Kde?”

“Neďaleko Važca!”

“Nááá kóóónééé!”

“A kde by sme ich vzali?”

“… No, tak utekajme.”

Vtipné, zábavné. Teraz zmeňme  žáner. Z humorného filmu sa prenesieme do amerického thrilleru.

Za siedmimi horami a siedmimi daňovými systémami, niekde na pomedzí Lamanšského prielivu a Balkánskeho poloostrova, bola malá sotfvérová firma. Darilo sa jej. Inu bohatieri z manažmentu si povedali: “Načim je nám do sveta sa hotovať.”

I začali plány na veľkú expanziu do zemí amerických plánovať.

Prileteli do Ameriky. Tu ich nie chlebom a soľou uvítali, ale dolárom a hamburgerom ich hostili. I manažment šťastne grafíky v exceli vyfarboval a revenue si počítal a index na burze zvyšoval. V každom štáte ich vítali s radostným džavotom a s nadšením v očiach  softvér nakupovali.

I bohatieri a hrdinovia skoro by na vavrínoch zaspali, keby sa do zeme Texas zvanej nevybrali.

Hamburger uvítací čakali. I právnici v kravatách s kufríkom k nim pristúpili, rukami si s nimi potriasali. Uchlácholení bohatieri si ani nevšimli, odkiaľ tu na nich právnici zbrane vytasili. I bohatieri naši, do hlavní softvérových patentných brokovníc pohliadnuť museli.

“Bohu dušu a nám doláre”, zrúkol hlavný právnik, význemne softvérovým patentom zahrozil.

Hádam aj o gate by ich zbojníci v právnickom háve pripravili, keby si bohatier Ivánuška na radu starej matere nespomenul.

“Ivánko. V ďalekých zemiach amerických, tam kúsok za Picburgskými humnami, v sklenennom paláci, žije kráľovná ríše Kaľifornskej. Ak  by si sa v problémoch ocitol, na toto telefónne číslo zapískaj. Pomoc dorazí.”

Ivánuška neváhal, na číslo zapískal. Div divúci sa udial.

Zo zeme začali právnici vyskakovať, ani čoby prútkom čarovným šibol. I banditi za právnikov preoblečení, čo softvérovými patentnými bambitkami mávali, sa na útek dali. Fujázdili preč, ani čoby sedemhlavý protimonopolný úrad v pätách mali.

Keď sa banditi sťaby gáfor vyparili, z diaľky sa do uší bohatierom prevolávanie na slávu donieslo. Ľudia z malých aj veľkých softvérových firiem na ulice vychádzali a na slávu bohatierom prevolávali.

“Dobrý človeče, prečo tak rozradostený jasáte a kotrmelce z radosti metáte?”, pýtal sa Ivánuška.

“Zachránili ste nás! Títo banditi kradli financie z našich softvérov a vždy nám bambitkami patentnými hrozili. Ani web stránku sme si spraviť nemohli.”

I vyzeralo všetko dobre, softvér sa predával, trh rozkvital. Čitateľovi však neunikne jeden detail. Kam sa banditi podeli? Kde tie svoje nové pikle kujú, ako ozbíjať softvérárov svojimi patentnými bambitkami?

Ako tak chodím po svete, tak sa od ľudí dozvedám rôzne hrôzostrašné príbehy o diletantizme pracovníkov alebo nadriadených. Nehovorím o slávnej afére Slovensko vs. Írko. Mám na mysli rôzne príhody od strojov. Zostáva až rozum stáť nad tým, ako sú ľudia vynaliezaví. Ako dokážu obísť všetky ochranné mechanizmy v absolútnej naivite: “Veď to predsa nevadí.”

Ďalšie príbehy o tom, ako bol vedúci niekoľko krát upozornený na to, že jeho riešenie problému je nedostatočné. V záchvate silného ega vyhlásil: “Šak to je dobre! Šak to nevadí!” A dôsledky prišli na návštevu o mesiac. Zobrali si na návštevu aj kamarátku Katastrofu. Spoločnými silami sa im behom pár sekúnd podarilo vyradiť celú prevádzku na niekoľko dní.

Tak si vravím: Zlatý softvér. Tam sa vývojárom a konzultantom nič moc zlé stať nemôže. List im neustrihne ruku alebo vyradením všetkých ochranných senzorov nezničia elektro-rozvody, na ktoré sa vyleje roztavený kov. Ako je to s tým softvérom len dobre.

Hm. Lenže…

Softvér je všade…

Softvér je občas tvorený z rovnakou mierou diletancie…

Následky môžu byť niekoľko násobne väčšie…

Tfujtajbl aj so softvérom.

Skúsili ste niekedy hodiť na stenu chleba s maslom alebo parenú buchtu? Čo sa stane? Prilepí sa. Na stene zostane minimálne fľak. Zopakujme celý experiment so sušeným hrachom. Zoberieme za hrsť sušeného hrachu, mávneme rukou a hodíme hrach o stenu.

S údivom môžeme sledovať výsledok experimentu. Sušený hrach sa od steny odráža. Na stene nezostáva prilepený. Akoby hrach na stenu hádzal.

Čo to má spoločné so softvérom? Veľmi veľa. Softvér obsahuje chyby a obsahuje ich veľa. Nemusí sa jednať o chybu štýlu, že sa vám v bankovom systéme odčítajú dva výbery z bankomatu namiesto jedného. Ale napríklad o nepríjemnú “chybu”, kedy musíte 10x kliknúť na okienko a potom sa otočiť na kolieskovej stoličke a v pravý moment stlačiť enter.

Čo s takýmito chybami? Vačšinou je dobré ich oznámiť autorom, aby ich odstránili. Takže sa pripravme na hod. Uchopíme problém. Rozoženieme sa. A hádžeme.

Problém dopadne do ticket systému, ktorý ho dostatočne spomalí, aby nešťastných vývojárov nezhodil zo stoličky a nepriklincoval o stenu. V ticket systéme zostane problém hybernovaný a uchovávaný len s malým množstvom pôvodnej energie. Pôvodná energia mohla byť skutočne ohromujúca, niekedy pripomínajúca výbuch sopky. Len namiesto kamenných bômb, padajú veľmi ťažké nadávky.

Ako vidíme, obranný účinok ticket systému je úžasný. Niektoré tickety sú preradené do sekcie vyhnívacia nádrž a po roku sú zmazané, ako nerelevantné.

A čo s tým robiť? Prečo ticket nie je vyriešený včas? Jednoducho preto, že nie sú dostatočné sily a manažment nevidí v tickete dostatočnú dôležitosť, aby preorganizovával vývojárov. Často tieto tickety znamenajú opravu 1-2 riadkov kódu. Čo je však podstatnejšie, 1-2 dni času vývojára. Na konci mesiaca už len zostane otázka: a kto to zaplatí?

Tak si ticket zostáva naďalej pekne hybernovaný a možno jedného dňa bude vyriešený. Poznám tickety, ktoré by už mohli chodiť aj do škôlky. Jednak majú na to vek a naviac už dorástli do slušnej veľkosti, tým ako si ich vývojári medzi sebou prehadzovali a pridávali komentáre.

Seriózne, čo sa s tým dá robiť? Zo strany klienta, je dôležité, aby si uvedomil, že proti nemu stojí ticket systém, cez ktorý musí jeho problém prebublať. Namiesto zvyšovania energie problému útočným a inzultatívnym tónom, radšej použiť asertívnejší prístup. Nakoniec, je dôležitá spolupráca a nie je dobré hodiť všetko na hlavu nešťastných vývojárov.

Zo strany dodávateľa softvéru je dôležité prehodnotenie priorít a namiesto sypania 30 nových vlastností za týždeň, vysypať len jednu. Zbytok úsilia venovať tomu, čo ľudí páli. Toto rozhodne nie je triviálna plánovacia úloha. Môže sa stať, že ticket je v rozpore so samotnou podstatou systému a musí byť zvolené úplne iné riešenie.

Softvér nie je vec, ktorú si kúpite v obchode a zavesíte nad kuchynskú linku. Samozrejme, že softvér, za ktorým je množstvo kvalitnej práce, sa takto môže javiť. Na kvalitný softvér je potrebná rozumná spolupráca oboch strán. Ako dodávateľa, tak odberateľa.