Bringa a programozásban: mi ez, okai és hogyan kerüljük el

Mi az a bringa a programozásban

Bringa egy kifejezés a fejlesztői közösségből, amely egy olyan funkció saját megvalósítását jelenti, amely már elérhető kész könyvtár, keretrendszer vagy szolgáltatás formájában. Az angol nyelvű környezetben a reinventing the wheel — a kerék újrafeltalálása kifejezést használják. Magyarul is találkozhatunk a „bringa”, „saját megvalósítás”, „saját bringa” változatokkal.

A metafora eredete összefügg azzal, hogy a kerék az emberiség egyik legrégebbi találmánya. Megpróbálni újra létrehozni a 21. században értelmetlen. A programozásban az analógia még pontosabb: a kész könyvtárak „kerekek”, amelyeket mérnökök ezrei optimalizáltak éveken át. Saját, gyengébb minőségű kerék létrehozása — erőforrások pazarlása.

A RedMonk egy elemző jelentésében (2023) kiszámította, hogy egy átlagos kereskedelmi alkalmazás körülbelül 500 külső függőséget használ. Ha a fejlesztők mindegyiket maguk írnák, a projekt költsége tízszeresére nőne, a piaci bevezetés ideje pedig évekkel. A csomagkezelők ökoszisztémája (npm, Maven, PyPI, NuGet) pontosan azért létezik, hogy elkerüljük a kerék újrafeltalálását.

A bringa jelei

A kód, amely bringa, több jelről ismerhető fel: szabványos feladatot nem szabványos módon old meg, nincsenek tesztjei vagy dokumentációja, nem támogatja a határeseteket, amelyeket a kész könyvtárak már régóta figyelembe vesznek. Gyakran az ilyen kódot a projekt „egyedi követelményeire” tekintettel írják, holott ezek a követelmények semmiben sem különböznek a tipikusaktól.

Különbség a bringa és az egyedi megoldás között

Az egyedi megoldás akkor indokolt, amikor a kész könyvtár építészeti vagy licenc korlátozások miatt nem felel meg. A bringa objektív okok nélkül jön létre — „játszadozási” vágyból, mások kódjába vetett bizalmatlanságból vagy a meglévő eszközök ismeretének hiányából. A különbség alapvető: az egyedi tudatos választás, a bringa hiba.

Miért találják fel a fejlesztők a bringát

Az első és legelterjedtebb ok — a meglévő megoldások ismeretének hiánya. Egy junior fejlesztő nem tudhatja, hogy a JSON elemzésére a szabványkönyvtárban van beépített függvény. Ehelyett kézzel ír egy elemzőt. Ez a probléma különösen a kezdők számára releváns, akik most lépnek be a nyelv ökoszisztémájába.

A második ok — az irányítás illúziója. A tapasztalt fejlesztők néha meg vannak győződve arról, hogy „jobban megírják”, mint a népszerű könyvtár szerzői. A statisztikák ennek ellenkezőjét mutatják: a hibák valószínűsége egy milliók által használt könyvtárban jelentősen alacsonyabb, mint a frissen írt kódban. A Synopsys (2024) szerint az Open Source kód átlagosan 0,1 hibát tartalmaz ezer soronként, a vállalati kód pedig 1–2-t.

A harmadik ok — az újrafelhasználási kultúra hiánya. Azokban a vállalatokban, ahol nem szokás a meglévő megoldásokat felkutatni a munka megkezdése előtt, minden fejlesztő létrehozza a „saját bringáját”. Ez a kód fragmentálódásához vezet: egy projektben három különböző HTTP-kliens megvalósítás is lehet, amelyeket különböző alkalmazottak írtak.

Pszichológiai szempontok

Az IKEA-hatás — egy pszichológiai jelenség, amikor az ember magasabbra értékeli azt, amit maga hozott létre, mint az objektíven jobb kész dolgokat. A programozásban ez a „saját bringa” iránti büszkeségként és annak kész könyvtárral való lecserélésének vonakodásaként nyilvánul meg, még annak nyilvánvaló előnyei ellenére is.

A bringák létrehozásának következményei a projektben

A gazdasági következmények a legnyilvánvalóbbak. A Stripe (2022) becslése szerint a fejlesztők munkaidejük akár 35%-át is olyan kód létrehozására fordítják, amely már létezik kész megoldások formájában. Egy 10 fős csapat fizetésére átszámítva ez évente körülbelül 200 ezer dollár, amelyet a kerék újrafeltalálására pazarolnak.

A technikai következmények közé tartozik a kódbázis növekedése, a tesztlefedettség csökkenése (a saját kódot általában rosszabbul tesztelik), a hibák és sebezhetőségek számának növekedése. Ezenkívül minden saját komponens egy újabb meghibásodási pont, amelyet figyelni és karbantartani kell.

A Google a „Why Google Stores Billions of Lines of Code” (2023) című kutatásában megjegyezte, hogy még a legnagyobb technológiai vállalatban is szigorú döntéshozatali folyamat létezik egy új függőség hozzáadásáról vagy saját megvalósítás írásáról. A legtöbb belső csapat először kész megoldást keres az egységes kódtárban.

Hatás a csapatra

A bringák információs aszinkronitást hoznak létre: amikor egy fejlesztő elmegy, a saját komponense dokumentáció és támogatás nélkül marad. Az új csapattagoknak nem szabványos kóddal kell boldogulniuk, időt vesztegetve, amelyet produktív munkára fordíthatnának.

Gyakori bringák példái a kódban

A leggyakoribb példa — a JSON vagy XML kézi elemzése, pedig szinte minden modern nyelvben vannak beépített eszközök. A fejlesztők rekurzív függvényeket írnak az objektumfa bejárására, nem tudva, hogy a JSON.parse() egy sorban megoldja a feladatot.

A második példa — a HTTP-kliens saját megvalósítása. A szabványos könyvtárak (fetch, axios, OkHttp, URLSession) támogatják a gyorsítótárazást, újracsatlakozást, időtúllépéseket és biztonságot. A saját kliens általában e követelmények közül legalább egyet nem vesz figyelembe, ami élesben hibákhoz vezet.

A harmadik példa — saját naplózási rendszer az SLF4J, Winston vagy Log4j használata helyett. A fejlesztő heteket pazarol annak megírására, amit a kész könyvtárak azonnal elvégeznek rotáció, naplózási szintek, aszinkron írás és monitoring rendszerekkel való integráció támogatásával.

# bringa — kézi CSV elemzés
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# szabványkönyvtár használata helyette
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

Saját ORM antipattern

Saját ORM (Object-Relational Mapping) írása — talán a legdrágább bringa. A kész ORM-ek, mint a Hibernate, Entity Framework vagy SQLAlchemy, évekig fejlődtek, támogatják a gyorsítótárazást, lusta betöltést, migrációkat és több tucat DBMS-t. A saját ORM általában egyetlen adatbázisra korlátozódik, és kritikus hibákat tartalmaz a kapcsolatok kezelésében.

Mikor indokolt a bringa

Tanulás — az egyetlen helyzet, amikor a bringa nemcsak indokolt, hanem hasznos is. Saját elemző, HTTP-szerver vagy ORM írása oktatási célból segít megérteni, hogyan működnek ezek az eszközök a motorháztető alatt. Fontos, hogy ne keverjük össze az oktatási projektet az éles kóddal: ami jó egy saját projektben, az elfogadhatatlan a kereskedelmi fejlesztésben.

Egyedi követelmények valóban igényelhetnek saját megvalósítást. Ha egyetlen könyvtár sem támogat egy adott protokollt, adatformátumot vagy hardverplatformot — az egyedi megoldás létrehozása indokolt. De előbb meg kell győződni arról, hogy a feladat valóban egyedi, nem pedig csak rosszul feltérképezett.

Licenc korlátozások — egy másik legitim ok. Egyes Open Source licencek (GPL, AGPL) összeegyeztethetetlenek lehetnek a vállalat üzleti modelljével. Ilyen esetekben a saját megvalósítás fejlesztése egy megengedőbb licenccel indokolt.

A három próbálkozás szabálya

Létezik egy gyakorlati szabály: mielőtt saját megvalósítást írsz, próbálj meg három különböző kész megoldást találni és tesztelni. Ha egyik sem megfelelő — hozd létre a sajátodat, de dokumentáld, miért utasítottad el a meglévő változatokat. Ez véd a kerék tudattalan újrafeltalálása ellen.

Hogyan kerüljük el a bringák létrehozását

Az első lépés — annak a szokásnak a kialakítása, hogy bármely tipikus feladat megkezdése előtt keressünk kész megoldásokat. Használj keresést a csomagkezelőkben, GitHubon, Stack Overflown. A kutatásra fordított idő többszörösen megtérül a saját kód írásának elkerülésével.

A második lépés — a kódellenőrzés bevezetése a bringák felderítésére összpontosítva. Az ellenőrzés során tedd fel a kérdést: „Miért nem használunk kész könyvtárat ehhez a feladathoz?” Ha a válasz nem tartalmaz objektív okokat — ez egy bringa. Nagyvállalatoknál (Google, Meta) a kódellenőrzés kötelezően tartalmazza a kerék újrafeltalálásának ellenőrzését.

A harmadik lépés — belső tudásregiszter létrehozása. Dokumentáld, milyen könyvtárakat és eszközöket használnak a projektben, milyen feladatokat oldanak meg. Az új fejlesztőknek hozzáféréssel kell rendelkezniük ezekhez az információkhoz, hogy ne hozzanak létre bringákat ismerethiányból. Vezess listát a meghozott architektúra döntésekről (ADR) a választás indokolásával.

• Kutass a csomagkezelőben egy új feladat megkezdése előtt
• Ellenőrizd a nyelv szabványkönyvtárát — a tipikus feladatok 80%-át lefedi
• Használd a kódellenőrzést a bringák felderítésére
• Dokumentáld a könyvtárválasztással kapcsolatos döntéseket
• Frissítsd az ökoszisztémával kapcsolatos ismereteidet konferenciákon és blogokban

Not Invented Here szindróma

A NIH-szindróma (Not Invented Here — „nem itt találták fel”) — egy szervezeti előítélet a külső megoldások használatával szemben. A NIH-szindrómával rendelkező vállalatok inkább mindent maguk fejlesztenek ki, elutasítva az Open Source könyvtárakat, még akkor is, ha azok felülmúlják a saját fejlesztéseket. Ez a szindróma a bringa vállalati változata.

Klasszikus példa — Netscape az 1990-es évek végén, amikor a vállalat éveket töltött a böngésző újraírásával a semmiből a meglévő kódbázis fejlesztése helyett. Eredmény — piaci részesedés elvesztése és felvásárlás az AOL által. Ezzel szemben az Android a Linux kernelre épül, és több ezer Open Source komponenst használ — ez lehetővé tette a termék rekordidő alatti piaci bevezetését.

A Harvard Business Review (2023) kutatása kimutatta, hogy az alacsony NIH-szindróma szinttel rendelkező vállalatok 40%-kal gyorsabban hozzák piacra a termékeket és 30%-kal kevesebbet költenek fejlesztésre. A kód újrafelhasználásának kultúrája versenyelőny a modern szoftverfejlesztésben.

// bringa — saját rendezési megvalósítás
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;
}

// beépített rendezés — szabványos megoldás
arr.sort((a, b) => a - b);