17. 1. 1999
V poslední době při práci na počítači málem propadám panice -- není takřka dne, abych nenarazil na nějakou novou chybu softwaru. Jednou mi vytuhne Linux, podruhé se zhroutí Emacs (pravda, je to vývojová verze, ale to ji snad neopravňuje k takovému chování, ne?), potom se zase WWW prohlížeč snaží bez ohledu na nastavení v mailcap spustit nenainstalovaný program, příště fetchmail přestane v určité situaci stahovat poštu, protože poštovní démon sice striktně dodržuje RFC, ale chová se jinak než sendmail, jindy zjistím, že instalace IRC klienta postrádá dokumentaci, a nakonec prostředek, s jehož pomocí vytvářím tento text, generuje HTML dokument neodpovídající HTML specifikaci. Člověk by nejraději tu nepřátelsky chovající se bedýnku vypnul a vrátil se k osvědčené tužce a papíru -- tužku lze v případě poruchy snadno vyměnit. Bylo by to ale nejlepší řešení? Nebude rozumnější se s tím počítačem raději nějak domluvit?
Zamysleme se, jaké máme možnosti. První, co člověka napadne, je udělat to stejně jako s tou tužkou. Jenomže: Víte třeba o nějakém stoprocentně funkčním operačním systému vhodném pro pracovní stanici? A kde je zaručeno, že použitím jiného WWW prohlížeče nedojde pouze k nahrazení stávajících chyb chybami jinými? Tudy asi cesta nepovede.
Dobře, spokojíme se tedy s programy, co máme, a zkusíme se k nim chovat šetrněji. Nastavíme si ulimit na procesy, aby příště paměť nevyčerpaly a Linux nevytuhl, místo vývojové verze Emacsu použijeme verzi stabilní, WWW prohlížeči podstrčíme wrapper tvářící se jako onen neinstalovaný program, místo stávajícího poštovního démona si nainstalujeme sendmail, dokumentaci k IRC klientovi si stáhneme a nainstalujeme sami a HTML dokumenty budeme psát přímo v HTML. Pomůže to? Ne. Příště se nám spustí procesů deset, paměť opět dojde a Linux opět zcepení. Příští verze Emacsu se bude hroutit, protože chyby ve vývojové verzi si nikdo nevšiml. WWW prohlížeč se bude snažit spustit jiný nenainstalovaný program pro jiný typ objektu. Na počítač se sendmailem se nám někdo probourá. Po instalaci nové verze IRC klienta budeme dokumentaci aktualizovat ručně. Vytvoření HTML dokumentu přímo v HTML nám dá více práce. Problémy jsme nevyřešili, pouze jsme je oddálili.
Už je to tak, vypadá to na nejhorší -- není zbytí, chyby bude nutno opravit. Představa výsledku je poměrně lákavá. Linuxový počítač nebude nutno resetovat, Emacs poběží měsíc bez nutnosti nového spuštění, WWW prohlížeč bude volat, co má, pošta bude přicházet bez problémů, dokumentace k IRC klientovi bude aktuální a ten HTML dokument bude přímo potěšení psát. Že bychom tedy přeci jen nalezli výhodné řešení?
První otázkou je technická proveditelnost. Jaký software nám umožní se s chybami nějak vypořádat? Má například smysl opravovat chyby programu, jehož autor nám staví hráze proti jeho plnému využití? Možná má, ale nejsou-li k programu dostupné zdrojové texty, těžko chybu opravíme. Nesmíme-li program předávat přátelům, neopraví nám chybu zkušenější kamarád. Nesmíme-li šířit změněnou verzi programu, nemůžeme ostatním uživatelům poskytnout program opravený a musíme jen trpně čekat, kdy a jestli vůbec autor naši opravu do programu zařadí.
Veškerým umělým hrázím a bariérám se můžeme vyhnout použitím free softwaru. Free software nám zajišťuje, že můžeme program volně používat, volně s ním nakládat a v neposlední řadě máme volnou ruku pro boj s chybami.
Ano, slyším, jak křičíte: "Ale já nejsem programátor, neumím chyby v programech opravit!" "Programovat umím, ale na opravení všech těch chyb nemám čas!" "Však to stejně opraví někdo jiný!"
Spoléhat na to, že s chybou něco udělá někdo jiný, se obvykle nevyplácí. Jednak si jí nikdo jiný nemusí všimnout, jednak ji nemusí považovat za důležitou a jednak, jak jinak, si může říci, že s tím něco udělá někdo jiný. Existuje celá řada spolehlivě přežívajících chyb, o kterých člověk ví a diví se, že s tím už někdo něco neudělal.
Nedostatek času? Schválně, kolik času jste již v součtu strávili obcházením té staré chyby? A nepotloukli jste se náhodou kvůli ní během vzteklého bušení do stolu? A kolika dalším lidem se kvůli téže chybě mohlo stát totéž? Jak dopadá statistika spotřebovaného času a způsobených úrazů ve srovnání s náklady na zajištění opravy chyby?
A kdo neumí chybu opravit? Může pomoci ji odstranit tím, že chybu oznámí. Chyby, o kterých nikdo neví, odstraněny být nemohou. Je lépe chybu oznámit vícekrát než vůbec. Podle mých zkušeností podstatně častěji nastává druhý případ -- oznámím-li chybu, autor programu o ní ještě neví.
Pakliže program s chybou je free software a máme dostatek odhodlání se s chybou nějak vypořádat, zbývá jediné -- zařídit, aby chyba byla opravdu opravena.
Při oznamování chyby je nutno mít na paměti hlavní cíl -- co nejrychlejší odstranění chyby. Proto je potřeba autorovi poskytnout co nejužitečnější informace o chybě. Především se podívejte, jestli program přímo neobsahuje nějaký nástroj na oznamování chyb a pokud ano, tak jej použijte. V každém případě je nutno autorovi sdělit co nejpřesnější návod, jak chybu zreprodukovat. Pokud autor může chybu vyvolat i na svém počítači, je velká šance, že se mu ji podaří opravit. Přesný návod k vyvolání chyby vede k jejímu odstranění obvykle výrazně rychleji, než stejně obšírná hypotéza uživatele, čím by asi chyba mohla být způsobena. Bývá také dobré připojit informaci o použité verzi programu a o systému a prostředí, ve kterém program provozujete. Nadbytečná informace většinou škodí méně než chybějící informace.
Mnozí uživatelé bývají odrazováni reakcí autorů. Softwarový vývojář je typicky velmi zaměstnaný člověk, který dělá tolik věcí najednou, že na žádnou z nich nemá dost času. Jeho ochota odpovídat na cokoliv bývá velmi nízká. Je tedy potřeba při komunikaci s ním zvolit správnou taktiku, jinak se může stát, že zpráva bude ignorována. Obecně platí dva principy: 1. čím je zpráva stručnější a přesnější, tím větší je pravděpodobnost, že bude vzata na vědomí; 2. není dobré nechat se čímkoliv odradit hned napoprvé, někdy to chce trochu natrénovat.
Někdy je možné využít ještě další komunikační vrstvy mezi autorem a uživatelem. Například narazíte-li na chybu programu instalovaného z balíčku Debian GNU/Linuxu, můžete chybu oznámit prostřednictvím debianovského Systému sledování chyb debianovskému údržbáři balíčku. Pro tento účel lze s výhodou využít program bug ze stejnojmenného balíčku, stačí jej jednoduše spustit a dále vás vede. Oznamovat chyby lze i v češtině, podívejte se na http://www.debian.cz/proj/. Oznámení chyby prostřednictvím Debianu má tu výhodu, že debianovský údržbář má s údržbou balíčku obvykle daleko méně práce, než má autor s vývojem programu, a má tedy více času na komunikaci s vámi. Může od vás zjistit podrobnější informace o chybě a autorovi pak zaslat již přesnější zprávu. Navíc chyba může být způsobena balíčkem, nikoliv programem samotným. Samozřejmě i v tomto případě platí výše uvedené zásady. Může být také užitečné nahlédnout na http://www.debian.org/Bugs.
Kvalita programu se odvíjí nejen od kvality a vynaloženého úsilí jeho tvůrce, ale i od kvality a vynaloženého úsilí jeho uživatelů.