16  Reprodukovatelný výzkum a udržitelný vývoj

V této kapitole se podíváme na to, jak zajistit, aby náš výzkum byl reprodukovatelný, tj. aby jej kdokoli (včetně nás samých v budoucnosti) mohl zopakovat a dostat stejné výsledky. Současně s tím prozkoumáme i to, jak zařídit, aby byl náš projekt udržitelný, tj. abychom mohli stejným způsobem analyzovat nová data, postup upravovat a recyklovat kusy svého kódu v pozdějších projektech.

Replikovatelnost výzkumu je standardní podmínka vědecké práce: každý výzkum musí být možné zopakovat a každý, kdo jej zopakuje, musí dostat (aspoň přibližně) stejné výsledky. Pokud některou část předchozích výsledků není možné replikovat (jako se nyní zdá, že je tomu např. v experimentální psychologii), pak má příslušný vědec nebo dokonce vědní obor velký problém. To stejné platí analogicky i v komerčním prostředí.

Randall Munroe/xkcd, https://xkcd.com/242/; úprava Dr. Julia Shaw, https://twitter.com/drjuliashaw/status/720361939239448577.

16.1 Replikovatelná analýza

Výzkum obvykle zahrnuje dva kroky: 1) sběr dat (např. pomocí experimentu, pozorování apod.) a 2) analýzu těchto dat (typicky pomocí statistických nástrojů). Oba tyto kroky musí být možné zopakovat: experiment musí být možné replikovat a analýzu reprodukovat. Zde se zaměříme na reprodukovatelnost analýzy.

Analýza je reprodukovatelná, pokud může kdokoli naši analýzu zopakovat od původních dat až po finální prezentaci výsledků a přitom dostane stejné výsledky. Udržitelná analýza navíc znamená, že může zkontrolovat všechny kroky našeho postupu, tj. prověřit, že dávají z věcného i statistického pohledu dobrý smysl. Dobře udržitelná analýza navíc umožní provést stejný postup na nových nebo aktualizovaných datech.

Rostoucí význam replikovatelnosti analýzy ukazuje i to, že v současné době roste i počet vědeckých časopisů, které vyžadují k nabídce článku k opublikování přiložit i data a analytický kód.

Aby byla analýza reprodukovatelná, musí být k dispozici původní data i jasný popis postupu, jak je analyzovat. Data musejí být dostupná ve formátu, který dokáže budoucí analytik snadno přečíst. Zde jsou nejlepší otevřené textové formáty. Data také musejí být dobře popsaná, aby bylo jasné jejich kódování – co znamenají jednotlivé proměnné, v jakých jsou jednotkách, jak jsou kódované chybějící hodnoty apod.

Stejně tak všechny kroky analýzy musejí být dostatečně popsané – tak přesně, aby bylo možné je znovu provést. Ideální popis analýzy je pěkně okomentovaný skript v nějakém volně šiřitelném programovacím jazyce, např. R. Budoucí výzkumník (což je nejčastěji sám autor původní analýzy, který se k problému musí po několika měsících nebo letech vrátit) musí mít vše uspořádané a popsané tak, aby mohl celou analýzu provést znovu a dostat stejné výsledky – a aby se v nich vyznal. Pokud k tomu stačí přečíst si vlastní komentáře a spustit hotový skript, je to velké štěstí.

Replikovatelnost analýzy je jeden z hlavních důvodů, proč používat skriptovací nástroje (jako je  R) místo “klikacího” softwaru nebo Excelu. U skriptovacího jazyka je možné celý kód spustit znovu, přečíst, najít chyby, opravit je i použít kusy vlastního kódu v budoucí analýze. V případě “klikacího” softwaru není možné nic takového možné; v Excelu to sice v principu možné je, ale nikdo nedokáže skutečně pročíst a porozumět závislostem v tabulkovém procesu, aspoň pokud se nejedná o naprosto triviální analýzu.

16.2 Organizace práce

Aby byl naše analýza reprodukovatelná a udržitelná, je třeba, abychom všechny operace prováděli pomocí dobře komentovaného skriptu, tj. nic (snad kromě základní exploratorní analýzy dat) nesmíme “naklikat” ani provádět v konzoli – nic tedy nesmíme dělat ručně. To se týká přípravy dat, veškeré jejich analýzy, tvorby obrázků a tabulek a ideálně i prezentace výsledků, ať už formou vědeckého článku, diplomové práce nebo komerční prezentace.

Analýza dat probíhá ideálně ve třech krocích (ve skutečnosti se člověk od pozdějších kroků často vrací zpět, aby předchozí kroky provedl znovu a lépe). Postup zahrnuje:

  1. přípravu dat,
  2. analýza dat a
  3. prezentaci výsledků (formou článku, diplomové práce nebo komerční prezentace).

Všechny tyto kroky musejí být co nejlépe popsané a zorganizované a všechny musejí mít podobu skriptu, aby bylo možné je zkontrolovat, strojově provést znovu a případně aktualizovat na nových datech.

Organizace dat, skriptů a adresářů

Abyste se později sami vyznali ve vlastní práci (a aby to dokázal i někdo další), je potřeba, aby byl ve všem pořádek. To naštěstí není příliš složité. Prakticky to znamená rozdělení práce do jednotlivých souborů a jejich roztřídění do adresářů (složek).

Na nejvyšší úrovni je vhodné, abyste měli každý svůj projekt v jednom adresáři odděleném od ostatních projektů. V jednom adresáři tak budete mít všechno, co se týká vaší diplomové práce, v dalších data a kód pro seminární práce a v ještě jiných věci pro vědecké nebo komerční projekty. RStudio toto oddělení výrazně zjednodušuje svou podporou projektů. Základní nástroj pro práci s projekty najdete v pravém horním rohu okna RStudia (viz obrázek 16.1). Zde můžete vytvářet nové projekty, otevírat již existující projekty, zavírat otevřené projekty a otevřené projekty konfigurovat. Toto menu vám (mimo jiné) umožní snadno přepínat mezi různými projekty, na kterých pracujete současně. Detailní popis práce s projekty najdete na stránce https://support.posit.co/hc/en-us/articles/200526207-Using-Projects.

Obrázek 16.1: Menu projektů v RStudiu.

V rámci projektového adresáře je užitečné si soubory roztřídit do dílčích adresářů. Nejjednodušší členění do adresářů je následující:

  • rawdata … sem si uložíte původní hrubá data, tj. data ve formátu, v jakém jste je získali od statistického úřadu, z experimentu nebo z jiného zdroje.
  • data … sem si uložíte data připravená k analýze, tj. data, která jste pomocí vlastního R skriptu upravili do podoby, se kterou budete dále pracovat.
  • R (scripts) … sem si uložíte R skripty.

Další podadresáře mohou obsahovat články, komerční zprávy nebo diplomové práce, které s pomocí daných dat a analýzy píšete (paper, report, thesis, apod.), prezentace, které vytváříte (slides) apod. Můžete mít také separátní podadresář na obrázky (figs) a tabulky (tabs), což dává smysl zejména v případě, že stejné obrázky nebo tabulky používáte ve více článcích nebo článku a prezentaci apod.

Hrubá a čistá data

Jak už bylo řečeno, “hrubá data” jsou vstupní data, která jste získali ze statistického úřadu, účetnictví, experimentu nebo jakéhokoli jiného zdroje. Tato data byste neměli žádným způsobem upravovat – ručně, ani jinak. Pokud je máte na papíře, přepište je do elektronické podoby, ale ručně upravte pouze odchylky elektronické verze od papírové. Pokud jsou v původní papírové verzi nějaké chyby, měli byste je zachovat i v elektronické verzi hrubých dat. Pokud máte originální hrubá data v elektronické podobě, nijak je neměňte ani neopravujte. Veškeré opravy byste měli provést až při jejich transformaci na čistá data. Takový postup je nejen poctivější (a bude snazší jej vysvětlit odběrateli vaší analýzy, např. editorovi vědeckého časopisu), ale zejména bezpečnější. Při tomto postupu budete mít vždy k dispozici jak originální data, tak jejich opravy. Pokud jste v opravě udělali chybu, můžete ji vždy napravit.

Vždy byste si také měli svá hrubá data přesně popsat, a to zvlášť v situaci, kdy je máte data rozdělená do různých souborů nebo máte různé verze těchto dat (např. předběžnou statistiku i její pozdější revidovanou verzi; data z pilotního experimentu nebo dotazníkového šetření i data ze skutečného experimentu či sběru dat; apod.). Doporučuji, abyste si poznamenali, co je uložené ve kterém souboru, co je jeho zdroj, co je obsahem jednotlivých proměnných, jak jsou oddělené, jaké je kódování souboru, jaké je kódování jednotlivých proměnných (např. jak je označená žena a jak muž), jakých hodnot mohou jednotlivé proměnné nabývat, jak se kódují chybějící hodnoty apod.).

Čistá data jsou data, která budete používat ve vlastní analýze. Tato data si z hrubých dat připravíte sami jejich vyčištěním, filtrací, transformacemi, spojením různých tabulek, převodem na tidy data formát a podobně. Při přípravě čistých dat také opravíte všechny chyby, které se v hrubých datech vyskytují.

Veškerou přípravu čistých dat proveďte ve skriptu, tj. ne v Excelu, v konzoli nebo nějakém “klikacím” programu. Každou transformaci dat (zejména všechny opravy dat) důkladně komentujte: co děláte a proč to děláte, případně i jaké předpoklady o struktuře dat vaše opravy a úpravy předpokládají. Takový postup vám umožní později zkontrolovat, zda jste postupovali správně, opravit případné chyby a celý proces kdykoli zopakovat.

Organizace kódu

Jak již bylo řečeno, všechny operace od přípravy a oprav dat, přes vlastní analýzu, po tvorbu obrázků a tabulek a ideálně i tvorby výsledné prezentace výsledků formou článku, diplomové práce, webu nebo prezentace, by měli dělat pomocí skriptů. R umožňuje i interaktivní práci v konzoli. Pro průzkum dat a zkoušení kódu je to velmi příjemné. Pamatujte však, že nic, co uděláte v konzoli nejde jednoduše reprodukovat. Nakonec byste měli veškerý svůj analytický kód zapsat do skriptu. Pouze skript je možné přečíst a i znovu spustit. (Kód spuštěný v konzoli můžete snadno přenést do editoru ze záložky History.)

Je velmi rozumné, abyste každý skript vždy spouštěli v nové a čisté instanci R. To má několik souvisejících důvodů: 1) Zajistíte tak, aby váš kód neinterferoval s výsledky vaší předchozí práce a 2) aby skutečně obsahoval vše, co vaše analýza vyžaduje. Klasická chyba vzniká v situaci, kdy nějakou proměnnou vytvoříte nebo balík načtete v konzoli nebo předchozím skriptem, a pak je používáte v jiném skriptu. Příště nebo na jiném počítači už váš skript nemusí fungovat správně. V lepším případě zhavaruje; v horším se bude chovat nepředvídatelně. To může být zdrojem těžko laditelných chyb nebo i velké ztráty předchozí práce.

Pro to, abyste každý skript spouštěli v čistém prostředí R, můžete udělat několik věcí. Zejména byste měli v RStudiu v Global Options... v záložce General vypnout volbu Restore .RData into workspace at startup a Save workspace to .RData on exit nastavit na Never, viz oddíl 1.2. Dále je dobré před spuštěním vlastního kódu restartovat R (v RStudiu v menu Session \(\rightarrow\) Restart R nebo klávesovou zkratkou Ctrl+Shift+F10). Ještě lepší však je volat jednotlivé skripty strojově v čistém prostředí R, viz dále. To nejmenší, co můžete udělat, je to, že na začátku svých skriptů (s výjimkou skriptů, které zavádí funkce) vymažete všechny proměnné z pracovního prostředí pomocí rm(list = ls()). Pak teprve načtěte potřebné balíky, vlastní funkce a data. Tento postup však nevymaže balíky, které jste dříve načetli.

Obvykle není dobré, abyste měli všechny svoje kód v jednom dlouhém monolitickém skriptu. Minimálně je rozumné oddělit hlavní kód od funkcí, které si vytváříte. Funkce umístěte do jednoho nebo více skriptů a kód, který je volá do jiných skriptů. To má dva dobré důvody: 1) Umožní vám to tyto funkce snadno recyklovat, tj. používat ve více skriptech (např. při analýze dat i ve výsledném reportu a tvorbě prezentace) i v pozdější analýze. 2) Výrazně vám to usnadní ladění kódu.

Současně je rouzmné vytvořit si různé skripty, které voláte postupně: 1) skripty pro vyčištění a opravy dat, 2) analytické skripty a případně 3) skripty, které vytvářejí obrázky a tabulky pro prezentaci výsledků. Při tom samozřejmě funkce stále umisťujete do samostatných skriptů.

Při psaní svých skriptů byste měli dodržovat několik základních postupů:

  1. Nic nekódujte “na tvrdo”. Pokud ve svém kódu používáte nějakou konstantu, zaveďte pro ni na začátku skriptu proměnnou a všude jinde volejte tuto proměnnou. Okomentujte také, co daná proměnná představuje a proč má právě tuto hodnotu. Nejenže tak bude váš kód čitelnější, ale také bude lehčí jej upravovat. Pokud se např. hodnota dané konstanty změní, bude stačit upravit ji na jediném místě, místo abyste ve svém kódu hledali všechny výskyty řetězce 2.7 a upravovali je ručně – s rizikem, že některý z výskytů tohoto řetězce představuje jiný koeficient. Pokud ve svém projektu používáte hodně konstant (typicky to budou cesty k různým souborům), můžete zvážit vytvoření separátního skriptu s konstantami. To vám umožní je snadno načíst v různých skriptech nebo projektech.

  2. Nikdy se neopakujte – vytvořte funkci. Obecně platí, že žádný kus kódu (sekvenci řádků) byste nikdy neměli psát dvakrát – místo toho si napište funkci. Důvody viz kapitola 7. Někdy potřebujete některý kus kódu spustit vícekrát a funkce se k tomu nehodí. Typický příklad je zavedení konstant nebo cest k souborům, které používáte ve více skriptech. Ani v takovém případě se neopakujte. Všechny konstanty mějte v jednom souboru a načtěte je všude, kde je budete potřebovat, pomocí funkce source(). I zde se však vyplatí zvážit, jestli je nezavést jako funkce.

  3. Používejte vždy relativní cesty k souborům. Absolutní cesta začíná v kořenovém adresáři systému (/home/arnost/diplomka/data/xyz.xlsx nebo C:\work\diplomka\data\xyz.xlsx). Naproti tomu relativní cesta začíná v pracovním adresáři. Pokud je oním pracovním adresářem adresář dilomka, je odpovídající relativní cesta data/xyz.xlsx. Vždy byste měli používat relativní cesty, protože ty budou fungovat i v případě, že celý projekt předáte kolegovi, přesunete na jiné místo v adresářové struktuře nebo na jiný počítač. Naproti tomu absolutní cesty se v takovém případě rozpadnou. Pamatujte také, že na velikosti jmen souborů (v některých operačních systémech) záleží!

  4. Zafixujte random seed. Pokud cokoli ve vašem skriptu používá generátor náhodných čísel (jako je tomu často v případě simulací, vzorkování, bootstrappingu, bayesovských algoritmech apod.), měli byste vždy nastavit počáteční stav generátoru náhodných čísel pomocí funkce set.seed(). Tím zajistíte, že skript vždy vrátí zcela stejný výsledek. Navíc může být velmi užitečné provést analýzu robustnosti, tj. ověřit si, že výsledek bude podobný i v případě, že použijete jiný počáteční stav generátoru náhodných čísel.

  5. Dodržujte nějaký styl psaní kódu. Počítači je to jedno, ale pro člověka bude kód mnohem čitelnější, což sami oceníte, když se k němu budete muset časem vrátit. Víc o stylech najdete v oddíle 1.8.

  6. Skript nesmí nikdy nevratně měnit pracovní prostředí počítače. To zejména znamená, že byste ve skriptu nikdy neměli instalovat balíky, měnit cesty, měnit options() apod. Pokud už něco změníte, měli byste na konci skriptu vše vrátit do původního stavu. (To nemusí být tak jednoduché, když váš skript spadne. V takovém případě je dobré používat funkci on.exit().)

  7. Ukliďte po sobě. Pokud váš skript vytváří nějaké průběžné soubory, mění cesty apod., měli byste po jeho skončení vše uklidit.

Dokumentování kódu

Veškerou svou práci byste měli dokumentovat, a to na několika úrovních. Měli byste si napsat

  • co obsahuje daný soubor, ať už datový nebo skript
  • v jakém pořadí se mají skripty spouštět
  • co dělá každý úsek kódu
  • co dělá každá funkce, jaké vstupy bere a jaké výstupy vrací

To vše je dobré napsat do obyčejných textových souborů (tj. např. ne dokumentů MS Word), protože je přečte každý – a to i za několik let, až se složitější datové formáty změní. O dokumentaci dat a postupu práce jsme mluvili výše. Nyní se podíváme na dokumentaci kódu. R umožňuje dokumentaci napsat přímo do skriptu jako komentář (vše za znakem # do konce řádku R ignoruje, tj. jedná se o komentář).

V každém R skriptu doporučuji si nahoru napsat, co tento skript dělá, jaká data či jiné prerekvizity potřebuje ke svému běhu a jaké výsledky vytvoří (ať už v podobě vytvořených dat, výpisu do konzole nebo čehokoli jiného).

Dál doporučuji u každého logického kusu kódu napsat, co dělá a jak to má fungovat. Nepište technikality typu “sečtu dvě čísla”, ale popište, jak má použitý algoritmus zhruba fungovat.

U funkcí je užitečné si napsat zhruba to, co u funkcí v balících nabízí dokumentace:

  • co funkce dělá, tj. co je jejím cílem,
  • jak funkce funguje, tj. jak funguje použitý algoritmus,
  • jaké vstupy funkce očekává – a to jak věcně (např. že první vstup je vzdálenost mezi městy v metrech), tak co se týče datové struktury (že to má být celé nebo reálné číslo),
  • jaký výstup funkce vrací (se stejnými podrobnostmi jako v případě vstupů) a
  • příklad použití – toto už není zcela nezbytné, ale může to pomoci, pokud v příkladu ukážete, jak připravit vstupní data a jak interpretovat výsledky.

Pokud chcete něco udělat a dosud jste to neudělali, je dobré si to poznamenat. Klasické místo, kam si psát úkoly, je soubor TODO umístěný do hlavního adresáře projektu. Jednotlivé úkoly si však můžete psát i přímo do kódu – jako komentář # TODO: text úkolu. V R si pak můžete nainstalovat balík todor, který vám do Addins v RStudiu přidá možnost strojově najít TODOs a další komentáře (FIXME, CHANGED, IDEA, HACK, NOTE, REVIEW, BUG, QUESTION, COMBAK a TEMP). Ve VS Code můžete použít rozšíření Todo Tree.

Pořadí spuštění skriptů

Pokud jste stůj kód rozdělili do několika různých skriptů, je potřeba jasně označit, v jakém pořadí se mají spouštět. Pokud řešíte jednoduchý projekt, ve kterém máte pouze dva skripty (prepare_data.R a analysis.R), pak je vše jasné a jednoduché. Někdy je však projekt větší: první skript připraví data z jednoho zdroje, druhý skript ze druhého zdroje, třetí ze třetího, čtvrtý je spojí dohromady, pátý obsahuje vámi definované funkce a nemá se přímo spouštět a šestý provede žádanou analýzu. V takovém případě záleží na tom, v jakém pořadí se skripty spustí. Existuje několik možností, jak zařídit, aby budoucí výzkumník věděl, jak postupovat:

  1. Pořadí, v jakém se mají skripty spouštět, si napíšete do textového dokumentu.
  2. Své skripty očíslujete vzestupně podle pořadí, v jakém se mají spouštět (tj. první skript se např. bude jmenovat 01_prepare_data_on_unemployment.R, druhý 02_prepare_data_on_inflation.R, atd.).
  3. Napíšete si skript, který pojmenujete např. build.R, který postupně zavolá pomocí funkce source() jednotlivé skripty ve správném pořadí.
  4. Napíšete si shellový skript, který jednotlivé R skripty zavolá ve správném pořadí. V Linuxu můžete použít bash, ve Windows např. PowerShell. V tomto shellu pak svůj skript můžete spustit např. pomocí prográmku Rscript
  5. Použijete make.

První varianta je poměrně nešikovná. Druhá je lepší, ale stále vyžaduje ruční restart R a následné ruční spuštění R skriptů. Třetí možnost je podstatně lepší, protože se jednotlivé skripty automaticky. Tento přístup má však jasnou nevýhodu: všechny skripty se spustí ve stejné instanci R, tj. všechna data a balíky, které nechá první skript v paměti R tam zůstanou ve chvíli, kdy se spustí druhý skript. Je pak na vás, abyste z paměti smazali vše, co tam v následujícím kroku nechcete mít. Čtvrtá možnost podstatně lepší, protože řeší i tento problém.

Poslední možnost je však zdaleka nelepší. Program make je malá, ale extrémně užitečná utilitka. V souboru Makefile umožňuje nadefinovat, jak výstupní soubory závisejí na vstupních souborech – např. že soubor unemployment.RData závisí na skriptu 01_prepare_data_on_unemployment.R a datovém souboru unemp.xlsx. Pokud popíšete závislosti správně, pak vám stačí spustit make, a ten se postará o to, aby se všechny skripty spustily ve správném pořadí. Oproti jednoduchému shellovému skriptu to má velkou výhodu: Pokud něco upravíte, shellový skript musí provést všechny kroky přípravy dat a analýzy od začátku do konce. Naproti tomu make provede pouze ty kroky, které logicky následují za změnou. Pokud si napíšete Makefile, RStudio vám otevře novou záložku Build, která vám umožní make spouštět jedním kliknutím přímo z RStudia.

make je poměrně komplexní nástroj. Většinou vám však budou stačit základy. Ty se můžete naučit např. ve video kurzu http://v4.software-carpentry.org/make/index.html.

Testování kódu

Než svou analýzu můžete prohlásit za hotovou, měli byste svůj kód důkladně otestovat. Zejména byste si měli ověřit, že váš kód poběží ve zcela čistém prostředí R, tj. po jeho restartu (viz výše). Tak se ujistíte, že váš skript načítá všechny balíky, které potřebuje, a že podobně načítá nebo vytváří i všechny použité proměnné. Velmi užitečné je i spuštění skriptu na jiném počítači.

Kromě testování celého kódu se může vyplatit napsat si i jednotkové testy jednotlivých funkcí. K tomu můžete využít např. balík testthat.

16.3 Zálohování a správa verzí

Svůj kód i data byste měli zálohovat, nebo ještě lépe použít nějaký systém správy verzí. Ten vám umožní nejen zálohovat staré verze kódu, ale také mít vedle sebe několik verzí modifikovaného kódu (větve), synchronizovat kód snadno mezi různými počítači, spojovat různé verze kódu a řešit jejich konflikty, spolupracovat s kolegy a případně se vrátit ke starší verzi kódu.

Pokud nechcete používat skutečnou správu verzí, můžete např. svá data nebo kód zazipovat do souboru, který bude ve svém jménu obsahovat číslo verze nebo datum, a tento soubor uložit lokálně ve svém počítači, nebo mnohem lépe do cloudu: na Dropbox, GDrive, OneDrive apod. (nebo si jej aspoň schovat ve vlastní poště). Pro kód je však mnohem lepší použít skutečný systém správy verzí.

Jako nejlepší systém správy verzi se v současnosti jeví git, protože má nejlepší podporu jak v RStudiu a VS Code, tak i grafických nadstavbách a v cloudových úložištích. git je malý prográmek, ale naučit jej efektivně se používat vyžaduje jisté úsilí. To se však v průběhu času hravě vrátí. Navíc se git můžete učit používat postupně, jak porostou vaše nároky. Na webu najdete mnoho dobrých zdrojů, které vám umožní se naučit git používat. Můžete se podívat např. na webu https://www.atlassian.com/git.

Podpora gitu v RStudiu je poněkud primitivní. Pokud chcete dělat složitější věci, můžete se podívat na různé grafické nadstavby gitu. Jedna z nejlepších je GitKraken (https://www.gitkraken.com/).

Jako cloudové úložiště pro git můžete zdarma použít např. GitHub (https://github.com/), BitBucket (https://bitbucket.org/) a další.

Správa verzí dat je složitější problém. Hrubá data se však obvykle nemění tak často, takže si vystačíte se primitivním řešením pomocí zipu, data a uložení na cloud. Některé cloudové služby navíc také umožňují primitivní správu verzí. Čistá data samozřejmě nemá velký smysl zálohovat, protože se dají kdykoli vygenerovat znovu z hrubých dat pomocí zálohovaného kódu. (Pokud však proces jejich generování trvá tak dlouho, že je chcete kešovat, můžete použít stejný postup.)

16.4 Jak zajistit budoucí funkčnost kódu

Ani skripty, které jsou dobře organizované a mají k dispozici originální data, nemusí být možné v budoucnosti spustit. To se může stát z mnoha různých příčin:

  • Balíky R se vyvíjejí a přitom nejsou vždy zcela zpětně kompatibilní; některé balíky dokonce po čase zaniknou a jsou odstraněny z CRANu.
  • Balíky R často používají systémové knihovny nebo jiné programy, které se také vyvíjejí.
  • Také samotné R se vyvíjí. Jeho vývojáři sice dbají na velkou konzervativnost a zpětnou kompatibilitu, ale v některých případech (z dobrých důvodů) dochází k mírné změně chování.

To stejné samozřejmě platí pro všechny softwarové nástroje; R zde patří mezi ty spíše udržitelnější.

Co tedy můžeme dělat proto, aby náš kód byl v budoucnu udržitelný? Zde se nabízí několik rad:

  1. Nepoužívejte nedokumentované vlastnosti. Některé funkce mohou v některých situacích udělat něco, co chcete, i když to nebyl jejich původní účel. Ani ti nejkonzervativnější tvůrci balíků však nezaručují, že takové náhodné chování funkcí zůstane zachováno.

  2. Používejte balíky, které mají aktivní vývoj a hodně uživatelů, tj. je pravděpodobné, že tu budou jejich moderní verze i v budoucnu.

  3. V případě balíků ze skupiny tidyverse sledujte vývoj funkcí. Některé funkce jsou označeny jako deprecated, jiné jako experimental. Těm je lepší se vyhnout.

  4. Uložte si, jakou verzi R a všech balíků používáte. Většinou můžete z CRANu instalovat i starší verzi (pokud to systémové knihovny vašeho počítače umožní). Vypsat verzi R a použitých balíků můžete buď funkcí sessionInfo() nebo lépe devtools::session_info(), která zaznamená víc informací.

Pokud si opravdu potřebujete být jistí, že nějakou svou analýzu udržíte po velmi dlouhou dobu bez údržby v chodu, můžete využít balík renv, viz https://rstudio.github.io/renv/articles/renv.html. Balík renv implementuje systém, který vám umožní zafixovat verze ostatních R balíků. Odpadne tedy problém s tím, že na daném počítači je nějaký balík ve starší nebo novější verzi, než kód předpokládá.

Ani to však nemusí stačit, pokud chcete udržet svůj kód v běhu beze změny po velmi dlouhou dobu, protože v čase se může změnit vlastní R a různé systémové knihovny, které R balíky interně volají. V takovém případě je řešením celou vaši aplikaci zabalit do kontejneru, např. pomocí Dockeru. Tak vzniknou kontejnery, které budou obsahovat vše, co je potřeba k tomu, aby vaše aplikace běžela. V případě potřeby je pak můžete spustit na jakémkoli počítači, který podporuje Docker, což platí pro Linux, Windows a (v nějaké míře) i pro macOS. Více o Dockeru se dozvíte např. na https://docs.docker.com/ nebo https://www.youtube.com/watch?v=gAGEar5HQoU&t=1458s. Speciálně pro uživatele jazyka R jsou vhodné také návody https://solutions.posit.co/envs-pkgs/environments/docker/ a https://colinfay.me/docker-r-reproducibility/.

16.5 Prezentace výsledků

Jakmile máte hotovou analýzu, většinou potřebujete výsledky prezentovat ostatním. Dnes se nabízejí čtyři základní způsoby prezentace výsledků:

  • lineární text (článek, diplomová práce, business report apod.); typickým výstupním formátem je zde PDF nebo MS Word,
  • hypertext s “živými prvky”; typickým výstupem zde jsou webové stránky, případně oživené JavaScriptovými aplikacemi,
  • prezentace (slides); typickým výstupem zde je PDF nebo HTML, případně PowerPoint nebo
  • aktivní web, který reaguje na vstupy svých uživatelů a přepočítává a aktualizuje své výsledky podle jejich vstupů.

Dříve bylo tyto výstupy potřeba vytvořit v nějakém třetím softwaru (LaTeX, MS Word, PowerPoint apod.). Člověk psal text nebo vytvářel prezentaci a do nich přepsal nebo myší přetáhl výsledky analýzy dat z R. Tento přístup má však minimálně tři nedostatky: 1) přenášení výsledků je pracné, 2) snadno při něm vznikne chyba a 3) výsledek není reprodukovatelný – pokud se změní data nebo analýza, je třeba celou práci provést znovu (přičemž mohou snadno vzniknout další chyby). R naštěstí umožňuje mnohem lepší postup: smíchat text a analytický kód a z něj strojově vytvořit požadovaný výstupní formát (PDF, HTML, MS Word apod.).

Existuje několik možností, jak propojit strukturovaný text s R-kovým kódem. Historicky nejstarší je Sweave. Jeho základem je LaTeXový dokument, do kterého jsou vloženy kusy R-kového kódu. Tímto způsobem je možné vytvořit lineární text i slides ve formátu PDF. Druhou možností je RHTML. Zde je základem HTML kód, do kterého je opět vložen R-kový kód. Tímto způsobem je možné vytvořit webové stránky ve formátu HTML. Oba přístupy mají své výhody (zejména plnou kontrolu nad výstupem). Mají však dvě velké nevýhody: 1) Vlastní kód je složitý, vyžaduje znalost LaTeXu nebo HTML a zdrojový text může být poněkud nepřehledný. 2) Výsledkem je vždy jen jediný možný výstup (PDF, nebo HTML).

Mnohem zajímavější možností je tak R Markdown: R-kový kód je vložený do jednoduchého textového souboru s několika málo značkami, popisujícími formátování dokumentu. Tento základ je možné pomocí utilitek knitr, pandoc a Quarto převést do velkého množství výstupních formátů současně: do PDF, HTML, MS Wordu, LibreOffice, LaTeXu, ConTeXtu a mnoha dalších.

Výsledkem takového postupu je dokonale reprodukovatelný výzkum: od hrubých dat na začátku až po vlastní prezentaci výsledků na konci. Tímto způsobem vnikla i tato kniha. Víc o této možnosti se dozvíte v následující kapitole.