Bisikleta sa programming: ano ito, mga dahilan at paano iwasan

Ano ang bisikleta sa programming

Bisikleta — ito ay isang terminong mula sa komunidad ng mga developer na nangangahulugang paggawa ng sariling implementation ng functionality na magagamit na sa anyo ng handa nang library, framework o serbisyo. Sa kapaligirang nagsasalita ng Ingles, ginagamit ang ekspresyong reinventing the wheel — muling pag-imbento ng gulong. Sa komunidad ng mga programmer, mayroon ding mga variant na "bisikleta", "sariling implementation", "sariling bisikleta".

Ang pinagmulan ng metapora ay nauugnay sa katotohanan na ang gulong ay isa sa pinakamatandang imbensyon ng sangkatauhan. Ang pagsubok na likhain itong muli sa ika-21 siglo ay walang kabuluhan. Sa programming, mas tumpak pa ang pagkakatulad: ang mga handa nang library ay "mga gulong" na inoptimisa ng libu-libong inhinyero sa loob ng mga taon. Ang paggawa ng sariling gulong na mas mababa ang kalidad — ay sayang na paggamit ng mga resources.

RedMonk sa analytical report (2023) ay kinuwenta na ang karaniwang komersyal na aplikasyon ay gumagamit ng humigit-kumulang 500 external dependencies. Kung ang bawat isa sa mga ito ay isinusulat ng mga developer nang mag-isa, ang gastos ng proyekto ay tataas ng sampung beses, at ang oras ng paglabas sa merkado — ng mga taon. Ang ecosystem ng mga package manager (npm, Maven, PyPI, NuGet) ay umiiral nang eksakto upang maiwasan ang pag-imbento ng mga bisikleta.

Mga palatandaan ng bisikleta

Code na isang bisikleta ay makikilala sa ilang mga palatandaan: nalulutas nito ang karaniwang problema sa hindi karaniwang paraan, walang mga test o documentation, hindi sinusuportahan ang mga edge case na matagal nang isinasaalang-alang sa mga handa nang library. Madalas, ang ganitong code ay isinusulat na inaasahan ang "kakaibang mga kinakailangan" ng proyekto, kahit na sa katotohanan ang mga kinakailangang ito ay walang pinagkaiba sa mga tipikal.

Ang pagkakaiba sa pagitan ng bisikleta at custom na solusyon

Custom na solusyon ay nabibigyang-katwiran kapag ang handa nang library ay hindi akma dahil sa architectural o licensing na mga limitasyon. Ang bisikleta ay ginagawa nang walang mga obhetibong dahilan — dahil sa pagnanais na "maglaro", kawalan ng tiwala sa code ng iba o hindi kaalaman sa mga umiiral na tool. Ang pagkakaiba ay pundamental: ang custom ay isang mulat na pagpili, ang bisikleta ay isang pagkakamali.

Bakit nag-iimbento ng bisikleta ang mga developer

Unang at pinakakaraniwang dahilan — ang hindi kaalaman sa mga umiiral na solusyon. Ang isang Junior developer ay maaaring hindi alam na para sa pag-parse ng JSON sa standard library ay may built-in na function. Sa halip, isusulat niya ang parser nang mano-mano. Ang problemang ito ay lalong mahalaga para sa mga baguhan na kakapasok pa lang sa ecosystem ng wika.

Pangalawang dahilan — ang ilusyon ng kontrol. Ang mga eksperyensadong developer ay minsan kumbinsido na "mas mahusay nilang isusulat ito mismo" kaysa sa mga may-akda ng sikat na library. Sinasabi ng statistics ang kabaligtaran: ang posibilidad ng pagkakamali sa isang library na ginagamit ng milyun-milyong proyekto ay mas mababa kaysa sa bagong isinulat na code. Ayon sa Synopsys (2024), ang Open Source na code ay naglalaman ng average na 0.1 pagkakamali sa bawat libong linya, habang ang corporate — 1–2.

Pangatlong dahilan — ang kawalan ng kultura ng muling paggamit. Sa mga kompanya kung saan hindi kaugalian na magsaliksik ng mga handa nang solusyon bago simulan ang trabaho, ang bawat developer ay gumagawa ng "sariling bisikleta". Ito ay humahantong sa fragmentation ng code: sa isang proyekto ay maaaring may tatlong magkakaibang implementation ng HTTP client na isinulat ng iba't ibang empleyado.

Mga sikolohikal na aspeto

Epekto ng IKEA — isang sikolohikal na penomenon kung saan mas pinahahalagahan ng tao ang nilikha niya mismo kaysa sa obhetibong mas mahusay na mga handa nang bagay. Sa programming, ito ay nagpapakita bilang pagmamalaki sa "sariling bisikleta" at ayaw na palitan ito ng handa nang library kahit na may malinaw na mga kalamangan ang huli.

Mga bunga ng paggawa ng mga bisikleta sa proyekto

Ekonomiko na mga bunga ang pinaka-malinaw. Ayon sa pagtatasa ng Stripe (2022), ang mga developer ay gumugugol ng hanggang 35% ng oras ng trabaho sa paggawa ng code na umiiral na sa anyo ng mga handa nang solusyon. Sa pagsasalin sa suweldo ng isang team na may 10 tao, ito ay humigit-kumulang 200 libong dolyar bawat taon na ginagastos sa pag-imbento ng mga bisikleta.

Teknikal na mga bunga ay kinabibilangan ng paglaki ng codebase, pagbaba ng test coverage (ang sariling code ay kadalasang mas mahina ang pagka-test), pagdami ng mga bug at vulnerabilities. Bukod pa rito, ang bawat sariling component ay isa pang point of failure na kailangang i-monitor at i-maintain.

Google sa kanyang pag-aaral na "Why Google Stores Billions of Lines of Code" (2023) ay binanggit na kahit sa pinakamalaking teknolohiyang kompanya ay mayroong mahigpit na proseso ng paggawa ng desisyon tungkol sa pagdaragdag ng bagong dependency o pagsusulat ng sariling implementation. Karamihan sa mga panloob na team ay unang naghahanap ng handa nang solusyon sa isang repositoryo ng code.

Epekto sa team

Mga bisikleta ay lumilikha ng impormasyonal na asynchrony: kapag umalis ang isang developer, ang kanyang sariling component ay nananatiling walang dokumentasyon at suporta. Ang mga bagong miyembro ng team ay napipilitang unawain ang hindi karaniwang code, gumugugol ng oras na maaaring gamitin sa produktibong trabaho.

Mga halimbawa ng karaniwang bisikleta sa code

Pinakakaraniwang halimbawa — ang mano-manong pag-parse ng JSON o XML, bagaman halos sa lahat ng modernong wika ay mayroong mga built-in na paraan. Ang mga developer ay nagsusulat ng mga recursive function para sa pagtawid sa tree ng mga object, hindi alam na ang JSON.parse() ay nalulutas ang problema sa isang linya.

Pangalawang halimbawa — ang sariling implementation ng HTTP client. Ang mga standard na library (fetch, axios, OkHttp, URLSession) ay sumusuporta sa caching, reconnection, timeouts at seguridad. Ang sariling client ay kadalasang hindi isinasaalang-alang ang kahit isa sa mga kinakailangang ito, na humahantong sa mga bug sa production.

Pangatlong halimbawa — ang sariling logging system sa halip na gumamit ng SLF4J, Winston o Log4j. Ang developer ay gumugugol ng mga linggo sa pagsusulat ng ginagawa na ng mga handa nang library nang diretso na may suporta sa rotation, mga antas ng logging, asynchronous na pagsusulat at integration sa mga monitoring system.

# bisikleta — mano-manong pag-parse ng CSV
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# paggamit ng standard library sa halip
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

Ang antipattern ng sariling ORM

Pagsusulat ng sariling ORM (Object-Relational Mapping) — marahil ang pinakamahal na bisikleta. Ang mga handa nang ORM tulad ng Hibernate, Entity Framework o SQLAlchemy ay binuo sa loob ng mga taon, sumusuporta sa caching, lazy loading, migrations at dose-dosenang DBMS. Ang sariling ORM ay kadalasang limitado sa isang database at naglalaman ng mga kritikal na pagkakamali sa pamamahala ng mga koneksyon.

Kailan nabibigyang-katwiran ang bisikleta

Pag-aaral — ang tanging sitwasyon kung saan ang bisikleta ay hindi lamang nabibigyang-katwiran, kundi kapaki-pakinabang din. Ang pagsusulat ng sariling parser, HTTP server o ORM para sa mga layuning pang-edukasyon ay nakakatulong upang maunawaan kung paano gumagana ang mga tool na ito sa ilalim ng hood. Mahalagang huwag malito ang proyektong pang-edukasyon at production code: ang mabuti para sa pet-proyekto ay hindi katanggap-tanggap sa komersyal na development.

Kakaibang mga kinakailangan ay talagang maaaring mangailangan ng sariling implementation. Kung walang library na sumusuporta sa partikular na protocol, format ng data o hardware platform — ang paggawa ng custom na solusyon ay nabibigyang-katwiran. Ngunit bago ito, kailangang tiyakin na ang problema ay talagang kakaiba, at hindi lamang hindi gaanong pinag-aralan.

Mga lisensya na limitasyon — isa pang lehitimong dahilan. Ang ilang Open Source na lisensya (GPL, AGPL) ay maaaring hindi tugma sa business model ng kompanya. Sa ganitong mga kaso, ang pag-develop ng sariling implementation na may mas permissive na lisensya ay nabibigyang-katwiran.

Ang panuntunan ng tatlong pagsubok

Mayroong praktikal na panuntunan: bago isulat ang sariling implementation, subukang maghanap at mag-test ng tatlong magkakaibang handa nang solusyon. Kung walang akma — gumawa ng sarili, ngunit i-dokumento kung bakit tinanggihan ang mga umiiral na variant. Ito ay nagpoprotekta laban sa hindi mulat na pag-imbento ng bisikleta.

Paano maiiwasan ang paggawa ng mga bisikleta

Unang hakbang — ang pagbuo ng ugali na maghanap ng mga handa nang solusyon bago simulan ang trabaho sa anumang tipikal na problema. Gamitin ang paghahanap sa mga package manager, GitHub, Stack Overflow. Ang oras na ginugol sa pagsasaliksik ay mas malaki ang pabalik na halaga dahil sa pagtanggi sa pagsusulat ng sariling code.

Pangalawang hakbang — ang pagpapatupad ng code review na may pokus sa pagtukoy ng mga bisikleta. Sa review, itanong ang tanong: "Bakit hindi natin ginagamit ang handa nang library para sa problemang ito?" Kung ang sagot ay hindi naglalaman ng mga obhetibong dahilan — ito ay bisikleta. Sa malalaking kompanya (Google, Meta), ang code review ay may kasamang obligadong item ng pag-check para sa pag-imbento ng mga bisikleta.

Pangatlong hakbang — ang paggawa ng panloob na registry ng kaalaman. Idokumento kung aling mga library at tool ang ginagamit sa proyekto, kung aling mga problema ang kanilang nilulutas. Ang mga bagong developer ay dapat magkaroon ng access sa impormasyong ito upang hindi gumawa ng mga bisikleta dahil sa hindi kaalaman. Panatilihin ang listahan ng mga pinagtibay na architectural decisions (ADR) na may katwiran ng pagpili.

• Magsaliksik ng package manager bago simulan ang bagong problema
• Suriin ang standard library ng wika — sinasaklaw nito ang 80% ng mga tipikal na problema
• Gamitin ang code review para sa pagtukoy ng mga bisikleta
• Idokumento ang mga pinagtibay na desisyon tungkol sa pagpili ng mga library
• I-update ang kaalaman tungkol sa ecosystem sa mga conference at blog

Ang sindrom na Not Invented Here

NIH syndrome (Not Invented Here — "hindi naimbento sa amin") — ito ay isang organisasyonal na bias laban sa paggamit ng mga panlabas na solusyon. Ang mga kompanya na may NIH syndrome ay mas pinipiling i-develop ang lahat nang mag-isa, tinatanggihan ang mga Open Source na library, kahit na mas mahusay ang mga ito kaysa sa sariling mga development. Ang sindrom na ito ay isang corporate na bersyon ng bisikleta.

Ang klasikong halimbawa — ang Netscape sa huling bahagi ng 1990s, nang gumastos ang kompanya ng mga taon sa muling pagsusulat ng browser mula sa simula sa halip na i-develop ang umiiral nang codebase. Ang resulta — ang pagkawala ng market share at ang pagtanggap sa AOL. Sa kabaligtaran, ang Android ay binuo sa Linux kernel at gumagamit ng libu-libong Open Source na component — ito ang nagbigay-daan upang mailabas ang produkto sa merkado sa record na oras.

Pag-aaral ng Harvard Business Review (2023) ay nagpakita na ang mga kompanya na may mababang antas ng NIH syndrome ay naglalabas ng mga produkto sa merkado nang 40% mas mabilis at gumagastos ng 30% mas mababa sa development. Ang kultura ng muling paggamit ng code — ay isang competitive advantage sa modernong development.

// bisikleta — custom na implementation ng pag-uuri
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;
}

// built-in na sort — standard na solusyon
arr.sort((a, b) => a - b);