Bicicleta în programare: ce este, cauze și cum să eviți

Ce este bicicleta în programare

Bicicleta este un termen din comunitatea programatorilor care desemnează crearea propriei implementări a unei funcționalități deja disponibile sub formă de bibliotecă, framework sau serviciu gata făcut. În mediul anglofon se folosește expresia reinventing the wheel — reinventarea roții. În română se întâlnesc și variantele „bicicletă”, „implementare proprie”, „bicicletă proprie”.

Originea metaforei este legată de faptul că roata este una dintre cele mai vechi invenții ale omenirii. A încerca să o creezi din nou în secolul XXI este lipsit de sens. În programare analogia este și mai precisă: bibliotecile gata făcute sunt „roți” care au fost optimizate de mii de ingineri de-a lungul anilor. A crea propria roată de calitate inferioară — o risipă de resurse.

RedMonk într-un raport analitic (2023) a calculat că o aplicație comercială medie folosește aproximativ 500 de dependențe externe. Dacă programatorii ar scrie fiecare dintre ele singuri, costul proiectului ar crește de zeci de ori, iar timpul de lansare pe piață — cu ani. Ecosistemul managerilor de pachete (npm, Maven, PyPI, NuGet) există tocmai pentru a evita reinventarea roții.

Semnele bicicletei

Codul care este o bicicletă poate fi recunoscut după câteva semne: rezolvă o sarcină standard într-un mod non-standard, nu are teste sau documentație, nu suportă cazurile limită care de mult sunt luate în considerare în bibliotecile gata făcute. Adesea un astfel de cod este scris având în vedere „cerințele unice” ale proiectului, deși în realitate aceste cerințe nu diferă cu nimic de cele tipice.

Diferența dintre bicicletă și soluția personalizată

Soluția personalizată este justificată atunci când biblioteca gata făcută nu se potrivește din cauza limitărilor arhitecturale sau de licență. Bicicleta este creată fără motive obiective — din dorința de a „se juca”, neîncrederea în codul altora sau necunoașterea instrumentelor existente. Diferența este fundamentală: personalizatul este o alegere conștientă, bicicleta este o greșeală.

De ce programatorii inventează bicicleta

Primul și cel mai răspândit motiv — necunoașterea soluțiilor existente. Un programator junior poate să nu știe că pentru parsarea JSON în biblioteca standard există o funcție încorporată. În schimb, el va scrie manual parserul. Această problemă este deosebit de relevantă pentru începătorii care abia intră în ecosistemul limbajului.

Al doilea motiv — iluzia controlului. Programatorii experimentați sunt uneori convinși că „vor scrie mai bine” decât autorii bibliotecii populare. Statisticile spun contrariul: probabilitatea unei erori într-o bibliotecă folosită de milioane de proiecte este semnificativ mai mică decât în codul proaspăt scris. Potrivit Synopsys (2024), codul Open Source conține în medie 0.1 erori la mie de linii, iar codul corporativ — 1–2.

Al treilea motiv — lipsa culturii de reutilizare. În companiile unde nu se obișnuiește să se cerceteze soluțiile gata făcute înainte de începerea lucrului, fiecare programator își creează „bicicleta sa”. Aceasta duce la fragmentarea codului: într-un singur proiect pot exista trei implementări diferite ale unui client HTTP scrise de angajați diferiți.

Aspecte psihologice

Efectul IKEA — un fenomen psihologic în care o persoană apreciază ceea ce a creat ea însăși mai presus de lucrurile gata făcute, obiectiv mai bune. În programare aceasta se manifestă ca mândrie pentru „bicicleta proprie” și refuzul de a o înlocui cu o bibliotecă gata făcută chiar și atunci când avantajele acesteia sunt evidente.

Consecințele creării bicicletelor în proiect

Consecințele economice sunt cele mai evidente. Potrivit estimării Stripe (2022), programatorii pierd până la 35% din timpul de lucru creând cod care există deja sub formă de soluții gata făcute. Calculând salariul unei echipe de 10 persoane, aceasta înseamnă aproximativ 200 de mii de dolari pe an pierduți pentru reinventarea roții.

Consecințele tehnice includ creșterea bazei de cod, scăderea acoperirii cu teste (codul propriu este de obicei testat mai prost), creșterea numărului de bug-uri și vulnerabilități. În plus, fiecare componentă proprie este un alt punct de defect care trebuie monitorizat și întreținut.

Google în cercetarea sa „Why Google Stores Billions of Lines of Code” (2023) a menționat că până și în cea mai mare companie tehnologică există un proces strict de luare a deciziilor privind adăugarea unei noi dependențe sau scrierea propriei implementări. Majoritatea echipelor interne caută mai întâi o soluție gata făcută în depozitul unic de cod.

Impactul asupra echipei

Bicicletele creează asincronie informațională: atunci când un programator pleacă, componenta sa proprie rămâne fără documentație și suport. Noii membri ai echipei trebuie să se descurce cu codul non-standard, pierzând timp care ar putea fi folosit pentru muncă productivă.

Exemple de biciclete frecvente în cod

Cel mai frecvent exemplu — parsarea manuală a JSON sau XML, deși aproape toate limbajele moderne au instrumente încorporate. Programatorii scriu funcții recursive de traversare a arborelui de obiecte, neștiind că JSON.parse() rezolvă sarcina într-o singură linie.

Al doilea exemplu — implementarea proprie a unui client HTTP. Bibliotecile standard (fetch, axios, OkHttp, URLSession) suportă cache, reconectare, timeout-uri și securitate. Clientul propriu de obicei nu ia în considerare cel puțin una dintre aceste cerințe, ceea ce duce la bug-uri în producție.

Al treilea exemplu — sistemul propriu de logare în loc să folosească SLF4J, Winston sau Log4j. Programatorul pierde săptămâni scriind ceea ce bibliotecile gata făcute fac imediat cu suport pentru rotație, niveluri de logare, scriere asincronă și integrare cu sistemele de monitorizare.

# bicicletă — parsare manuală CSV
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# folosirea bibliotecii standard în schimb
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

Antipattern propriul ORM

Scrierea propriului ORM (Object-Relational Mapping) — poate cea mai scumpă bicicletă. ORM-urile gata făcute precum Hibernate, Entity Framework sau SQLAlchemy au fost dezvoltate ani de zile, suportă cache, încărcare leneșă, migrații și zeci de SGBD-uri. ORM-ul propriu se limitează de obicei la o singură bază de date și conține erori critice în gestionarea conexiunilor.

Când bicicleta este justificată

Învățarea — singura situație în care bicicleta nu doar că este justificată, dar este și utilă. Scrierea propriului parser, server HTTP sau ORM în scopuri educaționale ajută la înțelegerea modului în care funcționează aceste instrumente sub capotă. Este important să nu confundăm proiectul educațional cu codul de producție: ceea ce este bun pentru un proiect personal este inacceptabil în dezvoltarea comercială.

Cerințele unice pot necesita într-adevăr o implementare proprie. Dacă nicio bibliotecă nu suportă un protocol specific, format de date sau platformă hardware — crearea unei soluții personalizate este justificată. Dar mai întâi trebuie să te asiguri că sarcina este într-adevăr unică, nu doar prost studiată.

Limitările de licență — un alt motiv legitim. Unele licențe Open Source (GPL, AGPL) pot fi incompatibile cu modelul de afaceri al companiei. În astfel de cazuri, dezvoltarea propriei implementări cu o licență mai permisivă este justificată.

Regula celor trei încercări

Există o regulă practică: înainte de a scrie propria implementare, încearcă să găsești și să testezi trei soluții gata făcute diferite. Dacă niciuna nu se potrivește — creează-o pe a ta, dar documentează de ce variantele existente au fost respinse. Aceasta protejează împotriva reinventării inconștiente a roții.

Cum să eviți crearea bicicletelor

Primul pas — formarea obiceiului de a căuta soluții gata făcute înainte de a începe lucrul la orice sarcină tipică. Folosește căutarea în managerii de pachete, GitHub, Stack Overflow. Timpul petrecut pentru cercetare se întoarce de multe ori prin renunțarea la scrierea propriului cod.

Al doilea pas — implementarea code review cu accent pe depistarea bicicletelor. La revizuire pune întrebarea: „De ce nu folosim o bibliotecă gata făcută pentru această sarcină?” Dacă răspunsul nu conține motive obiective — aceasta este o bicicletă. În companiile mari (Google, Meta) code review include un punct obligatoriu de verificare a reinventării roții.

Al treilea pas — crearea unui registru intern de cunoștințe. Documentează ce biblioteci și instrumente sunt folosite în proiect, ce sarcini rezolvă. Programatorii noi trebuie să aibă acces la aceste informații pentru a nu crea biciclete din necunoaștere. Ține o listă a deciziilor arhitecturale adoptate (ADR) cu justificarea alegerii.

• Cercetează managerul de pachete înainte de a începe o sarcină nouă
• Verifică biblioteca standard a limbajului — acoperă 80% din sarcinile tipice
• Folosește code review pentru depistarea bicicletelor
• Documentează deciziile luate privind alegerea bibliotecilor
• Actualizează cunoștințele despre ecosistem la conferințe și în bloguri

Sindromul Not Invented Here

Sindromul NIH (Not Invented Here — „neinventat aici”) — este o prejudecată organizațională împotriva utilizării soluțiilor externe. Companiile cu sindrom NIH preferă să dezvolte totul singure, respingând bibliotecile Open Source chiar și atunci când acestea depășesc propriile dezvoltări. Acest sindrom este versiunea corporativă a bicicletei.

Exemplul clasic — Netscape la sfârșitul anilor 1990, când compania a petrecut ani rescriind browserul de la zero în loc să dezvolte baza de cod existentă. Rezultatul — pierderea cotei de piață și preluarea de către AOL. Dimpotrivă, Android este construit pe nucleul Linux și folosește mii de componente Open Source — aceasta a permis lansarea produsului pe piață într-un timp record.

Cercetarea Harvard Business Review (2023) a arătat că companiile cu un nivel scăzut al sindromului NIH lansează produse pe piață cu 40% mai repede și cheltuiesc cu 30% mai puțin pe dezvoltare. Cultura reutilizării codului este un avantaj competitiv în dezvoltarea modernă de software.

// bicicletă — implementare proprie de sortare
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;
}

// sortare încorporată — soluție standard
arr.sort((a, b) => a - b);