Велосипед у програмуванні: що це, причини та як уникати

Що таке велосипед у програмуванні

Велосипед — це термін зі спільноти розробників, який позначає створення власної реалізації функціональності, що вже доступна у вигляді готової бібліотеки, фреймворку або сервісу. В англомовному середовищі використовується вираз reinventing the wheel — винайдення колеса. В українському середовищі також трапляються варіанти «велосипед», «самописна реалізація», «власний велосипед».

Походження метафори пов'язане з тим, що колесо — один із найдавніших винаходів людства. Спроба створювати його заново в XXI столітті безглузда. У програмуванні аналогія ще точніша: готові бібліотеки — це «колеса», які оптимізувалися тисячами інженерів роками. Створити власне колесо гіршої якості — марна трата ресурсів.

RedMonk в аналітичному звіті (2023) підрахував, що середній комерційний застосунок використовує близько 500 зовнішніх залежностей. Якби кожну з них розробники писали самостійно, вартість проєкту зросла б у десятки разів, а час виходу на ринок — на роки. Екосистема менеджерів пакетів (npm, Maven, PyPI, NuGet) існує саме для того, щоб уникати винайдення велосипедів.

Ознаки велосипеда

Код, який є велосипедом, можна розпізнати за кількома ознаками: він розв'язує стандартну задачу нестандартним способом, не має тестів або документації, не підтримує edge cases, які давно враховані в готових бібліотеках. Часто такий код написаний у розрахунку на «унікальні вимоги» проєкту, хоча насправді ці вимоги нічим не відрізняються від типових.

Різниця між велосипедом і кастомним рішенням

Кастомне рішення виправдане, коли готова бібліотека не підходить через архітектурні або ліцензійні обмеження. Велосипед створюється без об'єктивних причин — із бажання «погратися», недовіри до чужого коду або незнання наявних інструментів. Різниця принципова: кастом — це усвідомлений вибір, велосипед — помилка.

Чому розробники вигадують велосипед

Перша і найпоширеніша причина — незнання наявних рішень. Junior-розробник може не знати, що для парсингу 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 у навчальних цілях допомагає зрозуміти, як ці інструменти працюють під капотом. Важливо при цьому не плутати навчальний проєкт і продакшн-код: те, що добре для pet-проєкту, неприйнятне в комерційній розробці.

Унікальні вимоги справді можуть потребувати власної реалізації. Якщо жодна бібліотека не підтримує специфічний протокол, формат даних або апаратну платформу — створення кастомного рішення виправдане. Але перед цим потрібно переконатися, що задача справді унікальна, а не просто погано вивчена.

Ліцензійні обмеження — ще одна легітимна причина. Деякі Open Source-ліцензії (GPL, AGPL) можуть бути несумісні з бізнес-моделлю компанії. У таких випадках розробка власної реалізації з дозвільнішою ліцензією виправдана.

Правило трьох спроб

Існує практичне правило: перш ніж писати власну реалізацію, спробуйте знайти та протестувати три різні готові рішення. Якщо жодне не підходить — створюйте своє, але документуйте, чому наявні варіанти були відхилені. Це захищає від неусвідомленого винайдення велосипеда.

Як уникати створення велосипедів

Перший крок — формування звички шукати готові рішення перед початком роботи над будь-якою типовою задачею. Використовуйте пошук по менеджерах пакетів, GitHub, Stack Overflow. Час, витрачений на дослідження, окупається багаторазово за рахунок відмови від написання власного коду.

Другий крок — впровадження код-рев'ю з фокусом на виявлення велосипедів. На рев'ю ставте запитання: «Чому ми не використовуємо готову бібліотеку для цієї задачі?» Якщо відповідь не містить об'єктивних причин — це велосипед. У великих компаніях (Google, Meta) код-рев'ю включає обов'язковий пункт перевірки на винайдення велосипедів.

Третій крок — створення внутрішнього реєстру знань. Документуйте, які бібліотеки та інструменти використовуються в проєкті, які задачі вони розв'язують. Нові розробники повинні мати доступ до цієї інформації, щоб не створювати велосипеди через незнання. Ведіть список ухвалених архітектурних рішень (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);