Бицикл у програмирању: шта је то, разлози и како избегавати

Шта је бицикл у програмирању

Бицикл је термин из заједнице програмера који означава стварање сопствене имплементације функционалности већ доступне у облику готове библиотеке, оквира или услуге. У енглеском говорном подручју користи се израз reinventing the wheel — проналажење точка. У српском језику такође се срећу варијанте „бицикл”, „самостална имплементација”, „сопствени бицикл”.

Порекло метафоре је повезано са тим што је точак један од најстаријих проналазака човечанства. Покушавати да га створите поново у XXI веку је бесмислено. У програмирању аналогија је још прецизнија: готове библиотеке су „точкови” које су оптимизовале хиљаде инжењера годинама. Створити сопствени точак лошијег квалитета — губљење ресурса.

RedMonk у аналитичком извештају (2023) израчунао је да просечна комерцијална апликација користи око 500 спољних зависности. Када би програмери сваку од њих писали самостално, цена пројекта би порасла десетинама пута, а време изласка на тржиште — годинама. Екосистем менаџера пакета (npm, Maven, PyPI, NuGet) постоји управо да би се избегло проналажење точка.

Знаци бицикла

Код који је бицикл може се препознати по неколико знакова: решава стандардни задатак нестандардним начином, нема тестове или документацију, не подржава ивичне случајеве који су одавно узети у обзир у готовим библиотекама. Често је такав код написан у очекивању „јединствених захтева” пројекта, иако се у стварности ти захтеви ни по чему не разликују од типичних.

Разлика између бицикла и прилагођеног решења

Прилагођено решење је оправдано када готова библиотека не одговара због архитектонских или лиценцних ограничења. Бицикл се ствара без објективних разлога — из жеље да се „игра”, неповерења у туђи код или непознавања постојећих алата. Разлика је принципијелна: прилагођено је свестан избор, бицикл је грешка.

Зашто програмери измишљају бицикл

Први и најраспрострањенији разлог — непознавање постојећих решења. Јуниор програмер можда не зна да за парсирање JSON-а у стандардној библиотеци постоји уграђена функција. Уместо тога написаће парсер ручно. Овај проблем је посебно актуелан за почетнике који тек улазе у екосистем језика.

Други разлог — илузија контроле. Искусни програмери понекад су уверени да ће „сами написати боље” од аутора популарне библиотеке. Статистика говори супротно: вероватноћа грешке у библиотеци коју користе милиони пројеката значајно је мања него у свеже написаном коду. Према Synopsys (2024), Open Source код садржи у просеку 0.1 грешке на хиљаду редова, а корпоративни — 1–2.

Трећи разлог — недостатак културе поновног коришћења. У компанијама где није уобичајено истраживати готова решења пре почетка рада, сваки програмер ствара „свој бицикл”. То доводи до фрагментације кода: у једном пројекту могу постојати три различите имплементације HTTP клијента које су написали различити запослени.

Психолошки аспекти

Ефекат IKEA — психолошки феномен при којем особа цени оно што је сама створила више од објективно бољих готових ствари. У програмирању то се манифестује као понос на „свој бицикл” и неспремност да се замени готовом библиотеком чак и при очигледним предностима ове друге.

Последице стварања бицикала у пројекту

Економске последице су најочигледније. Према процени Stripe (2022), програмери троше до 35% радног времена на стварање кода који већ постоји у облику готових решења. Прерачунато на плату тима од 10 људи, то је око 200 хиљада долара годишње потрошених на проналажење точка.

Техничке последице укључују раст базе кода, смањење тест покривености (самостални код се обично лошије тестира), повећање броја грешака и рањивости. Поред тога, свака самостална компонента је још једна тачка отказа коју треба пратити и одржавати.

Google у свом истраживању „Why Google Stores Billions of Lines of Code” (2023) приметио је да чак и у највећој технолошкој компанији постоји строг процес доношења одлука о додавању нове зависности или писању сопствене имплементације. Већина интерних тимова прво тражи готово решење у јединственом код репозиторијуму.

Утицај на тим

Бицикли стварају информациону асинхроност: када један програмер оде, његова самостална компонента остаје без документације и подршке. Нови чланови тима морају да се сналазе у нестандардном коду, трошећи време које би могло да се искористи за продуктивни рад.

Примери честих бицикала у коду

Најчешћи пример — ручно парсирање JSON или XML, иако скоро сви савремени језици имају уграђене алате. Програмери пишу рекурзивне функције за обилазак стабла објеката, не знајући да JSON.parse() решава задатак у једном реду.

Други пример — сопствена имплементација HTTP клијента. Стандардне библиотеке (fetch, axios, OkHttp, URLSession) подржавају кеширање, поновно повезивање, тајмауте и безбедност. Самостални клијент обично не узима у обзир бар један од ових захтева, што доводи до грешака у продукцији.

Трећи пример — самостални систем логовања уместо коришћења SLF4J, Winston или Log4j. Програмер троши недеље на писање онога што готове библиотеке раде одмах са подршком за ротацију, нивое логовања, асинхроно писање и интеграцију са системима за надзор.

# бицикл — ручно парсирање CSV
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# коришћење стандардне библиотеке уместо
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

Антишаблон сопственог ORM-а

Писање сопственог ORM-а (Object-Relational Mapping) — вероватно најскупљи бицикл. Готови ORM-ови попут Hibernate, Entity Framework или SQLAlchemy развијани су годинама, подржавају кеширање, лењо учитавање, миграције и десетине СУБП-ова. Сопствени ORM се обично ограничава на једну базу података и садржи критичне грешке у управљању везама.

Када је бицикл оправдан

Учење — једина ситуација када бицикл није само оправдан, већ и користан. Писање сопственог парсера, HTTP сервера или ORM-а у образовне сврхе помаже да се разуме како ови алати раде испод хаубе. Важно је при томе не мешати образовни пројекат и продукциони код: оно што је добро за лични пројекат неприхватљиво је у комерцијалном развоју.

Јединствени захтеви заиста могу захтевати сопствену имплементацију. Ако ниједна библиотека не подржава специфичан протокол, формат података или хардверску платформу — стварање прилагођеног решења је оправдано. Али пре тога треба се уверити да је задатак заиста јединствен, а не само лоше проучен.

Лиценцна ограничења — још један легитиман разлог. Неке Open Source лиценце (GPL, AGPL) могу бити некомпатибилне са пословним моделом компаније. У таквим случајевима развој сопствене имплементације са дозвољавајућом лиценцом је оправдан.

Правило три покушаја

Постоји практично правило: пре него што напишете сопствену имплементацију, покушајте да пронађете и тестирате три различита готова решења. Ако ниједно не одговара — направите своје, али документујте зашто су постојеће варијанте одбачене. Ово штити од несвесног проналажења точка.

Како избегавати стварање бицикала

Први корак — формирање навике тражења готових решења пре почетка рада на било ком типичном задатку. Користите претрагу по менаџерима пакета, GitHub, Stack Overflow. Време потрошено на истраживање враћа се вишеструко захваљујући одрицању од писања сопственог кода.

Други корак — увођење code review-а са фокусом на откривање бицикала. На прегледу постављајте питање: „Зашто не користимо готову библиотеку за овај задатак?” Ако одговор не садржи објективне разлоге — то је бицикл. У великим компанијама (Google, Meta) code review укључује обавезну проверу проналажења точка.

Трећи корак — стварање интерног регистра знања. Документујте које библиотеке и алати се користе у пројекту, које задатке решавају. Нови програмери треба да имају приступ овим информацијама како не би стварали бицикле из непознавања. Водите листу донетих архитектонских одлука (ADR) са образложењем избора.

• Истражујте менаџер пакета пре почетка новог задатка
• Проверавајте стандардну библиотеку језика — покрива 80% типичних задатака
• Користите code review за откривање бицикала
• Документујте донете одлуке о избору библиотека
• Ажурирајте знање о екосистему на конференцијама и у блоговима

Синдром Not Invented Here

NIH синдром (Not Invented Here — „није изумљено код нас”) — организациона предрасуда против коришћења спољних решења. Компаније са NIH синдромом преферирају да развијају све самостално, одбацујући Open Source библиотеке чак и када превазилазе сопствене развоје. Овај синдром је корпоративна верзија бицикла.

Класичан пример — Netscape крајем 1990-их, када је компанија потрошила године на преписивање прегледача од нуле уместо на развој постојеће базе кода. Резултат — губитак тржишног удела и преузимање од стране AOL. Насупрот томе, Android је изграђен на језгру Linux-а и користи хиљаде Open Source компонената — то је омогућило да се производ пласира на тржиште у рекордном року.

Истраживање Harvard Business Review (2023) показало је да компаније са ниским нивоом NIH синдрома пласирају производе на тржиште 40% брже и троше 30% мање на развој. Култура поновног коришћења кода је конкурентска предност у савременом развоју софтвера.

// бицикл — самостална имплементација сортирања
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;
}

// уграђено сортирање — стандардно решење
arr.sort((a, b) => a - b);