Kolo v programování: co to je, příčiny a jak se vyhnout

Co je to kolo v programování

Kolo je termín z komunity vývojářů, který označuje vytvoření vlastní implementace funkcionality již dostupné ve formě hotové knihovny, frameworku nebo služby. V anglicky mluvícím prostředí se používá výraz reinventing the wheel — znovuobjevování kola. V češtině se také setkáváme s variantami „kolo“, „vlastní implementace“, „vlastní kolo“.

Původ metafory souvisí s tím, že kolo je jeden z nejstarších vynálezů lidstva. Snažit se ho znovu vytvořit v 21. století je nesmyslné. V programování je analogie ještě přesnější: hotové knihovny jsou „kola“, která byla optimalizována tisíci inženýry po celá léta. Vytvoření vlastního kola nižší kvality — plýtvání zdroji.

RedMonk v analytické zprávě (2023) vypočítal, že průměrná komerční aplikace používá asi 500 externích závislostí. Pokud by vývojáři každou z nich psali sami, náklady na projekt by vzrostly desetinásobně a doba uvedení na trh — o roky. Ekosystém správců balíčků (npm, Maven, PyPI, NuGet) existuje právě proto, aby se zabránilo znovuobjevování kola.

Znaky kola

Kód, který je kolem, lze poznat podle několika znaků: řeší standardní úkol nestandardním způsobem, nemá testy ani dokumentaci, nepodporuje okrajové případy, které jsou dávno zohledněny v hotových knihovnách. Často je takový kód napsán s ohledem na „unikátní požadavky“ projektu, ačkoli ve skutečnosti se tyto požadavky nijak neliší od typických.

Rozdíl mezi kolem a vlastním řešením

Vlastní řešení je oprávněné, když hotová knihovna nevyhovuje z architektonických nebo licenčních důvodů. Kolo vzniká bez objektivních příčin — z touhy si „hrát“, nedůvěry v cizí kód nebo neznalosti existujících nástrojů. Rozdíl je zásadní: vlastní řešení je vědomá volba, kolo je chyba.

Proč vývojáři vynalézají kolo

První a nejrozšířenější důvod — neznalost existujících řešení. Junior vývojář možná neví, že pro parsování JSON je ve standardní knihovně vestavěná funkce. Místo toho napíše parser ručně. Tento problém je zvláště relevantní pro začátečníky, kteří teprve vstupují do ekosystému jazyka.

Druhý důvod — iluze kontroly. Zkušení vývojáři jsou někdy přesvědčeni, že „to napíší lépe“ než autoři populární knihovny. Statistiky říkají opak: pravděpodobnost chyby v knihovně používané miliony projektů je výrazně nižší než v čerstvě napsaném kódu. Podle Synopsys (2024) obsahuje Open Source kód v průměru 0,1 chyby na tisíc řádků, zatímco firemní kód — 1–2.

Třetí důvod — nedostatek kultury opětovného použití. Ve firmách, kde není zvykem zkoumat hotová řešení před zahájením práce, každý vývojář vytváří „své kolo“. To vede k fragmentaci kódu: v jednom projektu mohou být tři různé implementace HTTP klienta napsané různými zaměstnanci.

Psychologické aspekty

Efekt IKEA — psychologický fenomén, při kterém člověk cení to, co sám vytvořil, výše než objektivně lepší hotové věci. V programování se to projevuje jako hrdost na „své kolo“ a neochota nahradit ho hotovou knihovnou i při zjevných výhodách té druhé.

Důsledky vytváření kol v projektu

Ekonomické důsledky jsou nejzřejmější. Podle odhadu Stripe (2022) vývojáři ztrácejí až 35 % pracovní doby vytvářením kódu, který již existuje ve formě hotových řešení. Při přepočtu na plat 10členného týmu to je asi 200 tisíc dolarů ročně promarněných na znovuobjevování kola.

Technické důsledky zahrnují růst kódové základny, snížení testovacího pokrytí (vlastní kód je obvykle hůře testován), zvýšení počtu chyb a zranitelností. Kromě toho je každá vlastní komponenta další bod selhání, který je třeba monitorovat a udržovat.

Google ve svém výzkumu „Why Google Stores Billions of Lines of Code“ (2023) poznamenal, že i v největší technologické společnosti existuje přísný proces rozhodování o přidání nové závislosti nebo napsání vlastní implementace. Většina interních týmů nejprve hledá hotové řešení v jednotném úložišti kódu.

Dopad na tým

Kola vytvářejí informační asynchronii: když jeden vývojář odejde, jeho vlastní komponenta zůstává bez dokumentace a podpory. Noví členové týmu se musí vypořádat s nestandardním kódem a ztrácet čas, který by mohl být použit pro produktivní práci.

Příklady častých kol v kódu

Nejčastější příklad — ruční parsování JSON nebo XML, přestože téměř všechny moderní jazyky mají vestavěné nástroje. Vývojáři píší rekurzivní funkce pro procházení stromu objektů, aniž by věděli, že JSON.parse() řeší úkol v jednom řádku.

Druhý příklad — vlastní implementace HTTP klienta. Standardní knihovny (fetch, axios, OkHttp, URLSession) podporují cachování, znovupřipojení, time-outy a bezpečnost. Vlastní klient obvykle nezohledňuje alespoň jeden z těchto požadavků, což vede k chybám v produkci.

Třetí příklad — vlastní systém logování místo použití SLF4J, Winston nebo Log4j. Vývojář ztrácí týdny psaním toho, co hotové knihovny dělají okamžitě s podporou rotace, úrovní logování, asynchronního zápisu a integrace s monitorovacími systémy.

# kolo — ruční parsování CSV
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# použití standardní knihovny místo
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

Antivzor vlastního ORM

Psaní vlastního ORM (Object-Relational Mapping) — možná nejdražší kolo. Hotové ORM jako Hibernate, Entity Framework nebo SQLAlchemy byly vyvíjeny roky, podporují cachování, líné načítání, migrace a desítky DBMS. Vlastní ORM se obvykle omezuje na jednu databázi a obsahuje kritické chyby ve správě připojení.

Kdy je kolo oprávněné

Učení — jediná situace, kdy je kolo nejen oprávněné, ale i užitečné. Napsání vlastního parseru, HTTP serveru nebo ORM pro vzdělávací účely pomáhá pochopit, jak tyto nástroje fungují pod kapotou. Důležité je nezaměňovat vzdělávací projekt s produkčním kódem: co je dobré pro osobní projekt, je nepřijatelné v komerčním vývoji.

Unikátní požadavky skutečně mohou vyžadovat vlastní implementaci. Pokud žádná knihovna nepodporuje specifický protokol, formát dat nebo hardwarovou platformu — vytvoření vlastního řešení je oprávněné. Ale nejprve se musíte ujistit, že úkol je skutečně unikátní, ne jen špatně prozkoumaný.

Licenční omezení — další legitimní důvod. Některé Open Source licence (GPL, AGPL) mohou být nekompatibilní s obchodním modelem společnosti. V takových případech je vývoj vlastní implementace s permisivnější licencí oprávněný.

Pravidlo tří pokusů

Existuje praktické pravidlo: než napíšete vlastní implementaci, zkuste najít a otestovat tři různá hotová řešení. Pokud žádné nevyhovuje — vytvořte vlastní, ale zdokumentujte, proč byly stávající varianty odmítnuty. To chrání před nevědomým znovuobjevováním kola.

Jak se vyhnout vytváření kol

První krok — vytvoření návyku hledat hotová řešení před zahájením práce na jakémkoli typickém úkolu. Používejte vyhledávání ve správcích balíčků, na GitHubu, Stack Overflow. Čas strávený průzkumem se mnohonásobně vrátí díky upuštění od psaní vlastního kódu.

Druhý krok — zavedení code review se zaměřením na odhalování kol. Při revizi se ptejte: „Proč pro tento úkol nepoužíváme hotovou knihovnu?“ Pokud odpověď neobsahuje objektivní důvody — je to kolo. Ve velkých společnostech (Google, Meta) code review zahrnuje povinnou kontrolu znovuobjevování kola.

Třetí krok — vytvoření interního registru znalostí. Dokumentujte, jaké knihovny a nástroje se v projektu používají, jaké úkoly řeší. Noví vývojáři by měli mít k těmto informacím přístup, aby nevytvářeli kola z neznalosti. Veďte seznam přijatých architektonických rozhodnutí (ADR) s odůvodněním volby.

• Prozkoumejte správce balíčků před zahájením nového úkolu
• Zkontrolujte standardní knihovnu jazyka — pokrývá 80 % typických úkolů
• Používejte code review k odhalování kol
• Dokumentujte přijatá rozhodnutí o výběru knihoven
• Aktualizujte znalosti o ekosystému na konferencích a blozích

Syndrom Not Invented Here

NIH syndrom (Not Invented Here — „není vynalezeno zde“) — organizační předsudek proti používání externích řešení. Společnosti s NIH syndromem preferují vyvíjet vše samy, odmítají Open Source knihovny, i když převyšují vlastní vývoj. Tento syndrom je firemní verzí kola.

Klasický příklad — Netscape na konci 90. let, kdy společnost strávila roky přepisováním prohlížeče od nuly místo rozvoje stávající kódové základny. Výsledek — ztráta podílu na trhu a převzetí společností AOL. Naproti tomu Android je postaven na jádře Linuxu a používá tisíce Open Source komponent — to umožnilo uvést produkt na trh v rekordním čase.

Výzkum Harvard Business Review (2023) ukázal, že společnosti s nízkou úrovní NIH syndromu uvádějí produkty na trh o 40 % rychleji a utrácejí o 30 % méně na vývoj. Kultura opětovného použití kódu je konkurenční výhodou v moderním vývoji softwaru.

// kolo — vlastní implementace řazení
function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }
  return arr;
}

// vestavěné řazení — standardní řešení
arr.sort((a, b) => a - b);