September 6, 2010

Indikátory pre softvérové projekty

Softvéru je kopec. Niektorý softvér prežíva a je udržiavaný len vďaka enormnému úsiliu a stratách na budgetoch. Iný softvér proste frčí jedna radosť.

Ako je možné zistiť nakoľko riskantné budú práce na softvérovom projekte? Zostavil som sadu indikátorov, ktoré umožňujú veľmi rýchlo zhodnotiť projekt. Pokiaľ je väčšina nasledujúcich indikátorov pre projekt pozitívna, malo by sa vedenie projektu zamyslieť (ak už nie je neskoro).

Indikátor 1. Tím nepoužíva version control. Toto je dnes už fatálny indikátor. Pokiaľ zistíte, že version control nie je na mieste, utekajte preč! Tak rýchlo ako sa len dá!

Indikátor 2. Tím kopíruje binárky a libky s programom priamo do version control. Toto indikuje typický zlý návyk a lenivosť ľudí. Zbytočné megabajty vo version control spomaľujú prácu a checkout projektu môže trvať aj 20 minút (v lepšom prípade). Pri snahe o drobnú opravu v kóde sa jednoducho strávi niekoľko hodín len checkoutovaním.

Indikátor 3. Tím builduje aplikácie pomocou IDE a nevie aplikáciu zbuildovať bez IDE. Silne sa obmedzujú možnosti nasadenia projektu.

Indikátor 4. Návod na deployment začína slovami: Skopírujeme tieto Jary/libky/rožky do adresára. Indikuje nezvládnutý alebo neexistujúci deployment postup. To je veľmi nebezpečné, v prípade poškodenia produkčného servera bude nahodenie trvať veľmi dlho, ak bude vôbec možné. Taktiež pridanie nového člena do tímu je veľmi drahé a časovo náročné.

Rozumným riešením použitie nástroja na automatizáciu, ako je napríklad Maven.

Indikátor 5. Tím nemá Wiki. Toto je veľmi zle, pretože znalosti sa strácajú. Nový člen tímu jednoducho nemá odkiaľ čerpať informácie, prečo je daný kus softvéru riešený tak ako je.

Indikátor 6. Tím nepoužíva softvér, ktorý vyvíja.

Indikátor 7. Tím alebo manažment považuje písanie testov len stratu času. Veľmi nebezpečné. Nesťažujte sa potom na straty na budgetoch.

Indikátor 8. Pred releasom nie je spustený ani unit-test, ani integračný test. Testuje sa na používateľovi, ktorý s tým ale vopred nesúhlasil.

Indikátor 9. Kontinuálna integrácia je pre tím cudzie slovo.

Indikátor 10. Neporiadok na stoloch a pracovisku. Tento nesoftvérový indikátor môže až prekvapivo dobre kopírovať stav serverových aplikácií.

Apríl 28, 2010

Softvérová archeológia

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.

Január 23, 2010

Tvorba máp do hier – TaT Tile Map Editor

Podľa môjho názoru, vytvorenie počítačovej hry preverí všetky developerské zručnosti. Znalosť vývojárskych nástrojov, programovacieho jazyka a debuggeru je základ. To však rozhodne nie je všetko. Preverí aj to, či developer dokáže vytvoriť aplikáciu tak, aby bežala na počítači aj niekomu inému. Preverí vynaliezavosť a kreativitu pri tvorbe scenára. Naviac dnes je už pomaly všetko zosieťované a tak preverí aj jeho schopnosť prepojiť hru do sieťového prostredia. Vytvorenie hry preverí aj silu vôle. Dotiahnuť aplikáciu do úspešného konca, rozhodne nespočíva len v písaní kódu.

A hlavne je to zábava. Veľa vývojárov berie aplikácie príliš seriózne a potom to aj tak vyzerá. Má to všetku funkcionalitu, ale nikto to nechce používať. Toto je pekne popísané vo vzore Soviet Style.

Jednou z častí hry je aj tvorba levelov. Tu totiž skončí väčšina nádejných tvorcov. Pokiaľ nemáte k dispozícii nástroje, ktoré môže používať aj normálny človek a vytvárať pomocou nich vlastné levely, tak hra zakape.

Dobrá správa, nemusíte plytvať svojím drahocenným časom, použite TaT Tile Map Editor. Jedná sa o voľne dostupný editor máp napísaný v Jave. Základom je možnosť tvorby dlaždičkových máp. Nadefinujete si grafiku do štvorčekov a potom pomocou nej skladáte mapu levelu. Za veľmi dôležitú vlastnosť považujem, že dokáže pracovať s vrstvami. Takto si môžete vytvoriť zložitejší svet, postavičky môžu chodiť  napríklad aj za stĺpom.

Výsledný projekt je uložený do ZIP archívu, kde sa napríklad nachádza samotná mapa v súbore global.xml. Tento editor som využil pri tvorbe PF2010. Jednotlivé časti mapy, ktoré sa postupne zobrazujú po nazbieraní 10 vločiek, sú riešené ako vrstvy tej istej mapy.

Osobne tento editor odporúčam. Myslím si, že autorom hier môže ušetriť množstvo vzácneho času.