Karel Minařík: Kód je vyjádřením způsobu myšlení

David Šmehlík, 10.06.2009, 12:00, 8,464 přečtení

Karel Minařík

Pozice: Informační architekt, art director, Ruby programátor
Profil: blog, osobní stránky

Karel Minařík je webový designér a vývojář na volné noze. Vytváří grafická rozhraní webových stránek a aplikací, kód v HTML/CSS, Ruby a Javascriptu. Pravidelně publikuje open source projekty na serveru Github a nepravidelně pak články na blogu Restafari. Konzultuje a školí v oblasti interaktivity, vývoje v Ruby a používání verzovacího nástroje Git. Přednášel o webdesignu na Institutu Digitálních Médií a přednáší úvod do programování na FF UK. Žije v Praze – Podolí se ženou a dvěma dcerami.

Git – nový nástroj pro verzování zdrojových kódů

Poslední dobou ses stal propagátorem i další technologie – Git. O co se vlastně jedná?

GIT je strašně zajímavá věc, kterou vymyslel a naprogramoval Linus Torvalds, autor Linuxu. Je to nástroj pro verzování zdrojových kódů, něco jako rozšířenější CVS nebo Subversion. Linuxoví vývojáři se totiž dostali do křížku s dodavetelem software pro verzování — a tak si napsali svoje. Git je neuvěřitelně jednoduchý a přitom stejně neuvěřitelně flexibilní. Můžeš opravovat revize v historii, přeskládavat je do jiného pořadí, přidat k revizi třeba jen určité řádky rozpracovaného souboru… Git je také distribuovaný nástroj na verzování  — neexistuje nic takového jako centrální repositář, každý lokální repositář je „technicky vzato“ rovnocenný. Má to obrovské výhody: nepotřebujete připojení k internetu pro práci, vše je extrémně rychlé, protože to probíhá lokálně, máte automaticky několik záloh celého repositáře…

Jak to může v praxi fungovat na deployment většího projektu?

Vývojáři se mohou dohodnout, že jedno všem přístupné úložiště bude fungovat jako „centrální“ – a taky to často dělají.

Ale zároveň mohou pracovat lokálně, aniž by rozdělanou práci posílali do centrálního repositáře. A takto rozdělanou práci nebo různé experimenty si mohou verzovat jako vše ostatní.

Nenastává chaos v tom, co je umístěno v centrálním repository a co mají ještě vývojáři u sebe?

Teoreticky ano, ale prakticky se to neděje. Pokud se lidé nejsou schopni domluvit, nedomluví se v žádné situaci a na technologii moc nezáleží. Taky to musí s Gitem umět, protože umí být záludný.

Git má silné vnitřní mechanismy na „branchování“ a „mergování“, tedy větvení kódu do různých nezávislých a oddělených verzí a jejich spojování. Umožňuje úplně jiný styl práce než např. Subversion, v němž se to sice dělá taky, ale většinou se zatnutými zuby.

V Gitu je přirozené pracovat na nějakém úkolu a vyčlenit si celý kód do zvláštní branche. Tak máš možnost zasahovat i do hlavní větve (master, čili trunk v Subversion, pozn. redakce), ale ve své paralelní větvi přitom dělat další změny a zahrnovat tam i změny z hlavní větve.

Takový model řeší typické problémy vývojářů webových aplikací – mám na serveru nějakou verzi aplikace a já zároveň programuji novou funkcionalitu. A najednou chyba, na serveru se musí něco upravit a to hned. Jak se to udělá?! Git tenhle problém zvládá velmi dobře, protože práce s větvemi je snadná, extrémně rychlá, a můžeš určitou část kódu vysunout do branche např. i ex-post.

Lze to hezky vidět na serveru Github, který hostuje Git repositáře. Ten posunul spolupráci při vývoji hlavně open-source software na úplně jinou úroveň: lidé si „forkují“ cizí repositáře, a vytvářejí si tak „vlastní kopii“ třeba Rails, která je stále navázána na původní repositář.

Hosting pro Rails umí v ČR málokdo

Vraťme se k Rails: Proč myslíš, že je ve světě hostingů s podporou Rails tak málo?

Protože je to těžší, než dělat standardní hloupý „shared“ hosting, jak jsme zvláště v Čechách zvyklí. Když se u nás řekne hosting, každý si představí ten nejzákladnější sdílený PHP hosting. A ještě se bude dohadovat, jestli tam bude Safe Mode on nebo off. Hosting pro Rails je o hodně složitější. Hosting nejen pro Rails asi půjde cestou buď virtualizace (VPS) anebo nějakého „cloud“ řešení jako je např. Heroku.

Síla Rails je v otevřenosti a dynamičnosti

Občas slýchávám názor, že Ruby dává vývojářům až přemíru volnosti v tom, co si mohou v kódu dovolit. Je to pravda?

Kdo to říkal? Nebyl to David Grudl? Tenhle článek se mu zrovna moc nepovedl… (smích) Ruby prostě dává vývojářům do ruky silný nástroj i díky své otevřenosti a dynamičnosti. To, jestli toho budou zneužívat, nasekají problémy, to je věc jiná. Ještě jsem ale neviděl, že by někdo nasekal problémy kvůli tomu, že může předefinovat operátor plus. Možnosti, které Ruby dává např. v meta-programování za tu trochu opatrnosti stojí.

Proč dělat testy?

Celou dobu se chci dostat k jedné věci – k čemu provádět testy webových aplikací?

To je výborná otázka. Protože klikání se nedá škálovat. Vedl jsem pár bojů o testování se svými kolegy, jeden mi říkal: „Proč bychom měli psát testy, když vlezu na stránku, kliknu a vidím.“ Mýlí se ve dvou věcech. On si jenom myslí, že kliká rychle, ale není to pravda, počítač bude vždycky rychlejší, i kdyby „klikal“ přes emulátory typu Selenium. Ta druhá věc je, že automatizovaný test je opakovatelný a doba jeho provedení neroste exponenciálně.

Představa, že se podívám na jednu stránku, proklepnu si tři čtyři odkazy a vidím, jestli jsem něco nerozbil, je mylná. V aplikaci můžu udělat malou změnu, která se ale rozpustí do celé aplikace a rozbije se třeba úplně jiná stránka, na kterou ty sám při „testování“ nechodíš. Ale testy o ní ví, testy na ni chodí.

To je nejdůležitější část odpovědi na otázku, proč testovat. Současné webové aplikace jsou vcelku složité, je to spousta koleček, která se spolu točí. Je jednoduché to celé rozhodit. Testy jsou určitá ochranná zeď, která stojí okolo kódu a říká ti, že jsi změnil něco, co má na spoustě místech návaznost.

Kolik času je potřeba věnovat psaní testů? Není to špatná časová investice v rámci toho, kolik času by zabralo pouhé opravení konkrétní chyby?

Potíž je v tom, že takhle si to představuje hodně lidí. Často slýchávám věty jako: „Testy nepíšeme, protože na ně nemáme čas nebo by je zákazník nezaplatil.“ Považují testy za něco, co je přilepeno ke kódu a je nutné to dělat navíc a „když zbyde čas“.

Jenže to je jen jedno pojetí testování, a sice to horší: testy jen jako regresní testy proti zavlečení chyb do fungující aplikace. Říká se ale, že testy plní „tři D“: defence, design and documentation. Ta „obrana“ je tedy jen jedna z funkcí testů.

Pro mnoho lidí je ještě důležitější ta funkce „pomocníka při návrhu“ – nejprve napíšeš testy, aby sis nějak cvičně definoval rozhraní, názvy metod, to, jak budeš chtít např. s nějakou třídou pracovat. Pustíš testy, jsou červené a pak můžeš psát do aplikace kód, díky němuž „zelenají“.

To, že pak půlku kódu i testu přepíšeš je věc druhá a je to přirozené. Ale to se stává i při „běžném“, „netestujícím“ programování — ale na rozdíl od něj ti testy udělají jasno, co to vlastně děláš, co to vlastně chceš napsat. Je to docela návykové, když si to člověk vyzkouší.

Je složité s testy pracovat i v jiných nástrojích než v Ruby?

Není. Na většině platforem je to dnes srovnatelně jednoduché. Java, .NET, PHP, všude je možné psát pro kód testy i programovat tím stylem „nejdřív testy, pak aplikaci“. Rails jen — jako u spousty věcí — zpopularizovaly, že je to správné, že se to má dělat, že to jde a není to nějaký „vopruz“. Navíc, už jsme zmiňovali, že Ruby je velmi dynamický jazyk — a testy jsou naše kompilace, naše statické typování.

V čem se tak liší „testová“ mentalita Ruby programátorů od ostatních?

V Ruby je například skoro nemožné vydat knihovnu nebo plugin, který by nebyl pokrytý testy. Nikdo by se o něm s tebou nebavil, lidi by řekli: „Prosím tě, co to je? Má to Readme a dokumentaci? Nemá. Má to testy? Nemá. Balík kódu, co „něco“ dělá, to si nech, to umí každý napsat nějaký kód.“ (smích)

Co konkrétně dělají testy v rámci nějaké aplikace?

Testy mohu právě chápat jako „obranu“ před chybami nebo jako „pomocníka při návrhu“. V každém případě jsou to běžné unit testy, které hlídají, jestli kód dělá to, co od něj očekávám. V Rails je například velmi jednoduché a pohodlné testovat i „klientskou“ část aplikace, simulovat HTTP požadavky na controllery a odhalovat, zda-li aplikace nevrací chybový kód, zda URL /articles/public obsahuje opravdu jen tři publikované články, apod.

Nyní je ale v Ruby komunitě hodně „v módě“ přistupovat k testování ještě jinak: jako ke specifikaci chování aplikace tak, jak ji vidí uživatel — na vyšší úrovni abstrakce než je pouhé testování kódu. Tedy opravdu ve smyslu „Když se přihlásím do aplikace, načte se mi úvodní stránka s textem Vítejte“. Nejoblíbenějším nástrojem k tomuto účelu je „Cucumber“http://c­ukes.info, který právě takovou míru abstrakce umožňuje — a to nejen pro aplikace napsané v Ruby, ale i v Javě, .NETu, a na dalších platformách. A dokonce můžete testy psát česky.

Takto mohu dopředu definovat funkcionalitu a díky tomu, že je to napůl přirozený jazyk, rozumí tomu i neprogramátoři. Mohu pak jednoduše navrhovat aplikaci s projektovým manažerem, s grafikem, se zákazníkem, protože najednou tomu všichni rozumí a mají společný „jazyk“. Cucumber (ve spolupráci s ostatními nástroji jako je např. Webrat) pak takové „textové testy“ umí skutečně spustit.

Jak těžké může být např. pro projektového manažera naučit vývojáře něco takového aplikovat?

Musíš se odpoutat od myšlenky, že cílem práce vývojáře je „dosáhnout výsledku“. Kliknu tady, kliknu támhle, a vidím, že dvě a dvě jsou čtyři. Když uvažuješ takhle, „dosáhneš výsledku“ a pak jdeš buď na další úkol, nebo domů.

Pro mně je kód vyjádřením myšlenky. Elegance, čistota takového vyjádření je to, co je pro mě na programování zajímavé. Každý kód něco „dělá“. A kód napsaný tak, že nejprve píšeš testy a pak teprve kód je několikanásobně kvalitnější, než když to děláš naopak — to potvrzuje každý, kdo to zkoušel. Taky jsem tomu kdysi nechtěl věřit, ale je to tak.

Myslíš, že k tomu nestačí opravdu zodpovědně a kvalitně komentovat kód?

Ne, komentáře pro mně znamenají něco úplně jiného. Slyšel jsem hezké vyjádření, že komentáře často mohou být ne „zápachem v kódu“ (code smell), ale „deodorantem“ – mohou skrývat špatné vlastnosti kódu. Typicky to poznáte u komentářů uvnitř metod. Pokud má metoda padesát řádků, měla by být rozčleněna do několika menších a ty by se měly volat kompozitní metodou. To znamená, že je možno je izolovaně testovat, že kód je přehlednější a lépe se čte.

Komentáře s tím tedy moc nesouvisejí. Je to částečná podpora toho, aby se ve tvém kódu vyznal i někdo cizí. Jsou důležité pro dokumentaci: co dělá tahle třída, s čím souvisí, proč tady je, atd. Ale jestli kód funguje tak, jak má, to z komentářů nepoznáš.

Přidej článek do své sociální sítě:
  • Facebook
  • TwitThis

Zaujal vás rozhovor? Přidejte si RSS 30minut.cz do své čtečky.

Komentářů: 13

Almad

10.06.2009

Výborně, konečně někdo kdo testy popularizuje i u nás ,)

Martin Talavášek

10.06.2009

Senzační rozhovor!

Petr Steinbauer

10.06.2009

Komentáře a dokumentace:
Jsou dost zaváděcí – dokonce jsem se setkal s případem, kdy jsem si přečetl cca 20 stránkovou dokumentaci k nějakému Api – celkem makačka to pochopit a naučit se to.
Zkouším to v akci a nic…
Pak otevřu kod a dobrá čtvrtka funkcí byla prostě prázdná. Nedělali nic, přestože v dokumentaci bylo několik odstavců textů coto všechno zvládá a dělá.

Jinak pěknej rozhovor!

altar

10.06.2009

Komentare:

v extremnim programovani, ktere funguje hodne podobne co se testu tyce jak je uvedeno veclanku, je dokonce komentare zakazano psat, protoze progrmatorum je pak lito je mazat a nechce se jim refaktorovat kod :).

Jinak testy predem jsou zaklad, zrychluje to vyvoj a clovek v noci klidne spi

Martin

10.06.2009

Jenže v praxi přijde klient, tady máme PHP hosting, projekt tam MUSÍ běžet (sám neví proč, ale musí), začněte.

Pak se ukáže, že je tam nějaké PHP 4…

Samozřejmě se takový člověk dá poslat do ..ele, ale sehnat projekty, kde si člověk sám rozhoduje o všem, to může být problém.

paranoiq

10.06.2009

díky za úžasný rozhovor!

fabian

10.06.2009

Inspirativni rozhovor. Diky!

Peter Kahoun

10.06.2009

Jeden z těch rozhovorů, které mi nebyly ztrátou času. Dík. (Kdo je David Šmehlík? Trochu mi tu chybí stručná about-stránka.)

Botanicus

11.06.2009

„V Ruby je například skoro nemožné vydat knihovnu nebo plugin, který by nebyl pokrytý testy. Nikdo by se o něm s tebou nebavil, lidi by řekli: „Prosím tě, co to je? Má to Readme a dokumentaci? Nemá. Má to testy? Nemá. Balík kódu, co „něco“ dělá, to si nech, to umí každý napsat nějaký kód.“ (smích)“

Jen technicka: s testy mas pravdu, to se v Ruby fakt hodne dodrzuje, ale co se dokumentace tyce, tak tu naopak skoro nikdo nepise a kdyz jo, tak dost strohou. Dokumentaci zpravidla maji vetsi veci, ktere se nedaji tak rychle nastudovat z kodu, Rails, Merb, xmpp4r etc, ale bezna Ruby knihovna zpravidla nic moc. Konecne ono ty tooly pro generovani dokumentace v Ruby jsou dost mizerne, RDoc je hodne primitivni nastroj, Yard zacina vypadat hezky, ale porad neni v uplne rozumnem stavu.

David Šmehlík

11.06.2009

@Peter: Děkuji za vyjádření, k otázce „Kdo je David Šmehlík…“ Zkuste Google, dotaz „David Šmehlík“ nebo „YellowMedia“ :-)

Ondrej Cernos

11.06.2009

Tvrzení, že testy zpopularizovaly Rails je poněkud odvážné. O testech se mluví léta a dělají se léta, například javovský framework jUnit měl release verze 3.4 v roce 2000 a o testovací hype jede od dob hypu kolem extrémního programování – a, ruku na srdce, kde tenkrát byly Rails.
Nic proti nim, jen mi občas připadá, jak kdyby před Rails – v ústech některých rubařů – byly počítače jen dřevěné a šlapací.

Karel Minařík

11.06.2009

@Ondřej: Asi to zase nevysvětlím správně, ale zkusit to můžu .)

Nejde o „dřevěné a šlapací“, přece. Naopak, Rails jsou poutavé tím, že toho relativně málo vynalézají: ActiveRecord, MVC, REST jsou věci staré, tedy dřevěné a šlapací, a Rails je oprášily a implementovaly. Rails nikdy netvrdily „a teď všichni koukejte, objevili jsme k-o-l-o!!!“

Podobně je to s testováním. Nikdo netrvrdí, že Rails „objevily“ testování. Nikdo netvrdí, že Rails „objevily“ unit testy. Však taky Test::Unit v Ruby (stejně jako většina ostatních implementací pro cokoliv) emuluje jUnit. Ale:

  1. „Testovací kultura“ je dle mého v Ruby/Rails světě daleko rozvinutější než jinde. (Kde „jinde“ jsou zejména „ostatní platformy a technologie pro vývoj webových aplikací“.) Sociologický průzkum na to téma by byl skvělý, ale neznám ho, takže se musím spokojit jen s tím co vidím svýma očima.
  2. Nejde o unit testy, jak jsem zmiňoval i v rozhovoru. Jde právě třeba o akceptační testování typu Cucumber, které nyní „lidi od Ruby“ popularizují. Že je to věc stará a dávno známá přitom nikdo nezpochybňuje.

syntaxsugar

11.06.2009

Dekuji! Velice pekny rozhovor.
Dobre napsane testy jsou zakladem rychleho a kvalitniho vyvoje aplikaci. Bohuzel, napsat dobry test je predevsim pro zacinajici programatory obcas orisek, protoze maji sklon psat slozite testy, popripade je upravovat „aby kod konecne prosel“.

Vložte svůj komentář