Funguje na mém počítači: co to je, proč k tomu dochází a jak tomu předejít

Co znamená „Funguje na mém počítači“

„Funguje na mém počítači“ — fráze, kterou vývojář říká, když kolega nebo tester nahlásí chybu, ale na počítači vývojáře se tato chyba nereprodukuje. Navenek to vypadá jako popírání problému, ale technicky je situace reálná: kód může skutečně fungovat v jednom prostředí a selhat v jiném. Rozdíl jednoho bitu v konfiguraci — a chování aplikace se dramaticky změní.

Tato fráze se stala memem v IT komunitě, protože je zároveň pravdivá i zbytečná. Z pohledu vývojáře — kód na jeho počítači skutečně funguje. Z pohledu týmu — problém existuje a je třeba ho řešit, ne ospravedlňovat. Humor situace spočívá v tom, že vývojář říká pravdu, ale tato pravda nepomáhá opravit chybu. Meme je tak populární, že jsou mu věnovány tisíce příspěvků na Redditu, XKCD a DevOps konferencích.

Z pohledu procesů je fráze „funguje na mém počítači“ indikátorem problémů s reprodukovatelností prostředí. Pokud dva vývojáři nemohou získat stejný výsledek na stejném kódu — znamená to, že proces nastavení prostředí není standardizován. DevOps praxe tvrdí: prostředí musí být reprodukovatelné jedním příkazem z repozitáře bez ručních akcí.

Proč se lokální prostředí liší od produkce

Lokální prostředí vývojáře se téměř vždy liší od produkce. Vývojář používá macOS nebo Windows, zatímco server běží na Linuxu. Různé operační systémy mají různé souborové systémy, kódování, časování vláken a systémová volání. I když jsou obě prostředí Linux — verze jádra, glibc, OpenSSL se mohou lišit.

Druhý důvod — sada nainstalovaného softwaru. Na počítači vývojáře může být nainstalována globální verze Node.js 20, zatímco v konfiguraci CI/CD je uvedena verze 18. Nebo vývojář lokálně používá PostgreSQL 16 a v produkci PostgreSQL 14. Rozdíly v dílčích verzích často nejsou patrné, ale velké aktualizace mohou změnit chování SQL dotazů. Podle npm Inc. je 67 % chyb souvisejících se závislostmi způsobeno rozdílem v patch verzích.

Třetí důvod — síťové podmínky. Na lokálním počítači nejsou žádná zpoždění, omezení šířky pásma ani problémy s DNS. V produkci může jakýkoli požadavek na externí API trvat 500 ms místo 5 ms. Timeouty, retry logika, race conditions — všechny tyto problémy se projevují pouze pod skutečným zatížením a v reálných síťových podmínkách. Emulace sítě pomocí nástrojů jako Toxiproxy pomáhá tyto problémy odhalit před nasazením.

Typické příčiny nereprodukovatelnosti chyby lokálně

První příčina — nedostatek dat. Vývojář pracuje s testovacími fixture, zatímco v produkci jsou miliony záznamů s neočekávanými hodnotami. NULL v poli, které vývojář považoval za povinné, Unicode znak ve jméně, příliš dlouhý řetězec — to vše může způsobit chyby, které nejsou reprodukovatelné na lokální databázi se syntetickými daty.

Druhá příčina — různé příznaky kompilace a sestavení. Release sestavení (Release/Distribution) se může lišit od debug sestavení (Debug). Optimalizace kompilátoru, odstranění debug logů, inlining funkcí — to vše může skrýt nebo naopak projevit chyby. Typický příklad: v debug sestavení funguje assert, který selhává v release sestavení kvůli jinému pořadí inicializace proměnných.

Třetí příčina — lokální cache a dočasné soubory. Vývojář si chyby nemusí všimnout, protože v prohlížeči jsou kešovány staré skripty, v Redis jsou uložena zastaralá data a v souborovém systému visí dočasné soubory z předchozích spuštění. Čistý start (režim inkognito, vymazání cache, fresh install) často reprodukuje chybu, která se neprojevovala „sama od sebe“.

Čtvrtá příčina — konflikty globálních a lokálních závislostí. Nástroje jako Ruby gems, Python pip, Node.js npm mohou mít globálně nainstalované balíčky, které pomáhají kódu fungovat lokálně, ale v produkci chybí. Použití virtuálních prostředí (virtualenv, venv, nvm) izoluje projekt od globálních instalací a činí prostředí reprodukovatelným.

Dopad na týmovou práci a důvěru

Fráze „funguje na mém počítači“ ničí důvěru v týmu. Pokud vývojář pravidelně nemůže reprodukovat chyby, kolegové začnou pochybovat o jeho kompetenci nebo důkladnosti testování. Časem to vede k mikromanagementu: každou změnu musí zkontrolovat druhý vývojář, což zpomaluje vývoj. Podle Google Project Aristotle psychologická bezpečnost v týmu přímo ovlivňuje produktivitu a neustálé spory o prostředí jsou jedním z faktorů jejího snižování.

Druhý problém — zpomalení code review. Pokud vývojář nemůže reprodukovat chybu lokálně, může odmítnout pull request kolegy se slovy „ u mě to funguje — takže problém je u tebe“. To vyvolává konflikty a zpožďuje dodávku funkcí. Standardizace prostředí tento konflikt odstraňuje: pokud oba vývojáři pracují ve stejném Docker kontejneru, otázka „u koho to funguje“ ztrácí smysl.

Třetí problém — ztráta chyb v trackeru. Chyby, které se „nereprodukují u vývojáře“, jsou často uzavírány s poznámkou „nelze reprodukovat“ (Cannot Reproduce). Za měsíc se chyba objeví v produkci a její oprava stojí 10krát více. Pravidlo: pokud se chyba reprodukuje alespoň u jednoho člověka — existuje bez ohledu na to, zda funguje u vývojáře nebo ne.

Jak standardizovat prostředí vývojáře

První a nejúčinnější způsob — Docker. Celý projekt by měl být spuštěn pomocí docker-compose up bez dalších akcí. Databáze, cache, fronta zpráv, webový server — vše běží v kontejnerech. Vývojář instaluje pouze Docker a Git. Zbytek — uvnitř kontejnerů. To zaručuje, že všichni členové týmu mají stejné prostředí bez ohledu na operační systém.

Druhý způsob — správci verzí. Pokud Docker není možný (licenční omezení, legacy infrastruktura), použijte nvm (Node.js), rbenv (Ruby), pyenv (Python), sdkman (Java). Správci verzí umožňují přepínání verzí jazyků a nástrojů v rámci projektu. Soubory .nvmrc, .ruby-version, .python-version by měly být v repozitáři a kontrolovány CI/CD.

Třetí způsob — Vagrant pro virtuální stroje. Vagrant spouští virtuální stroj se zadaným operačním systémem a konfigurací nad VirtualBox nebo VMware. Uvnitř VM jsou všechny závislosti instalovány pomocí provisioning skriptů (shell, Ansible, Puppet). Vagrant je těžší než Docker, ale poskytuje úplnou izolaci na úrovni OS — užitečné pro projekty závislé na konkrétní verzi Linux jádra.

Čtvrtý způsob — makefile a bootstrap skripty. I jednoduchý Makefile s cíli install, test, build, clean může standardizovat běžné úkony. Příkaz make install by měl nainstalovat všechny závislosti, nakonfigurovat databázi a vytvořit testovací data. Jednotný vstupní bod pro všechny vývojáře vylučuje ruční chyby při nastavení prostředí.

Nástroje pro prevenci odchylek prostředí

Hlavní nástroj — lock-soubory závislostí. package-lock.json (npm), yarn.lock (Yarn), Podfile.lock (CocoaPods), pubspec.lock (Flutter) fixují přesné verze každého balíčku. Bez lock-souboru mohou dva vývojáři, kteří instalují závislosti v různých časech, získat různé dílčí verze. Lock-soubor by měl být v repozitáři a neměl by být ručně upravován.

Druhý nástroj — .env.example v repozitáři. Šablona proměnných prostředí s komentáři. Vývojář ji zkopíruje do .env a vyplní své vlastní hodnoty. CI/CD pipeline kontroluje, že všechny povinné proměnné jsou nastaveny. Podle GitLab 2023 týmy používající .env.example snižují počet incidentů souvisejících s proměnnými prostředí o 40 %.

Třetí nástroj — pre-commit hooky. Automatická kontrola, která se spouští před každým commitem: linter, formatter, kontrola typů, testy. Pokud jsou hooky nastaveny stejně u všech vývojářů, chyby formátování nebo typů, které „prošly na lokálním počítači“, se nedostanou do produkce. Husky pro JavaScript a pre-commit pro Python jsou populární řešení.

Čtvrtý nástroj — CI/CD pipeline, který spouští testy v čistém prostředí. Pokud testy procházejí v CI, ale ne lokálně — problém je v nastavení lokálního prostředí. Pokud testy neprocházejí v CI — pull request se neslučuje. Toto přísné pravidlo vylučuje pronikání chyb, které „fungují lokálně“, do hlavní větve.