دوچرخه در برنامه‌نویسی: چیست، دلایل و چگونه اجتناب کنیم

دوچرخه در برنامه‌نویسی چیست

دوچرخه اصطلاحی از جامعه برنامه‌نویسان است که به ایجاد پیاده‌سازی شخصی از قابلیتی اشاره دارد که قبلاً به صورت کتابخانه، فریم‌ورک یا سرویس آماده وجود دارد. در محیط انگلیسی‌زبان از عبارت reinventing the wheel — اختراع دوباره چرخ استفاده می‌شود. در فارسی نیز گزینه‌های «دوچرخه»، «پیاده‌سازی دست‌نویس» و «دوچرخه شخصی» به کار می‌روند.

خاستگاه این استعاره به این موضوع برمی‌گردد که چرخ یکی از قدیمی‌ترین اختراعات بشریت است. تلاش برای ایجاد دوباره آن در قرن بیست‌ویکم بی‌معناست. در برنامه‌نویسی قیاس دقیق‌تر است: کتابخانه‌های آماده «چرخ‌هایی» هستند که توسط هزاران مهندس در طول سال‌ها بهینه شده‌اند. ایجاد چرخ شخصی با کیفیت پایین‌تر — هدر دادن منابع است.

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 سال‌ها توسعه یافته‌اند، از کش، بارگیری تنبل، مهاجرت‌ها و ده‌ها DBMS پشتیبانی می‌کنند. ORM شخصی معمولاً به یک پایگاه داده محدود می‌شود و شامل خطاهای بحرانی در مدیریت اتصالات است.

چه زمانی دوچرخه موجه است

یادگیری — تنها موقعیتی است که دوچرخه نه تنها موجه، بلکه مفید است. نوشتن تجزیه‌گر، سرور HTTP یا ORM شخصی برای اهداف آموزشی به درک نحوه کار این ابزارها در زیرساخت کمک می‌کند. مهم است که پروژه آموزشی را با کد تولید اشتباه نگیریم: آنچه برای پروژه شخصی خوب است در توسعه تجاری غیرقابل قبول است.

نیازهای منحصربه‌فرد واقعاً ممکن است به پیاده‌سازی شخصی نیاز داشته باشند. اگر هیچ کتابخانه‌ای از پروتکل، فرمت داده یا پلتفرم سخت‌افزاری خاص پشتیبانی نمی‌کند — ایجاد راه‌حل سفارشی موجه است. اما ابتدا باید مطمئن شوید که کار واقعاً منحصربه‌فرد است، نه صرفاً ضعیف بررسی شده.

محدودیت‌های مجوز — دلیل مشروع دیگری است. برخی مجوزهای Open Source (GPL, AGPL) ممکن است با مدل کسب‌وکار شرکت ناسازگار باشند. در چنین مواردی توسعه پیاده‌سازی شخصی با مجوز مجازتر موجه است.

قانون سه تلاش

یک قانون عملی وجود دارد: قبل از نوشتن پیاده‌سازی شخصی، سه راه‌حل آماده مختلف پیدا کرده و آزمایش کنید. اگر هیچ‌کدام مناسب نیست — خودتان بسازید، اما مستند کنید که چرا گزینه‌های موجود رد شده‌اند. این از اختراع ناآگاهانه دوچرخه جلوگیری می‌کند.

چگونه از ایجاد دوچرخه جلوگیری کنیم

اولین گام — ایجاد عادت جستجوی راه‌حل‌های آماده قبل از شروع کار روی هر کار معمولی. از جستجو در مدیران بسته، GitHub، Stack Overflow استفاده کنید. زمان صرف شده برای تحقیق چندین برابر با صرف‌نظر از نوشتن کد شخصی باز می‌گردد.

دومین گام — اجرای بازبینی کد با تمرکز بر شناسایی دوچرخه‌ها. در بازبینی سوال بپرسید: «چرا از کتابخانه آماده برای این کار استفاده نمی‌کنیم؟» اگر پاسخ شامل دلایل عینی نباشد — این دوچرخه است. در شرکت‌های بزرگ (Google, Meta) بازبینی کد شامل بررسی اجباری اختراع دوباره چرخ است.

سومین گام — ایجاد فهرست داخلی دانش. مستند کنید که چه کتابخانه‌ها و ابزارهایی در پروژه استفاده می‌شوند، چه کارهایی را حل می‌کنند. برنامه‌نویسان جدید باید به این اطلاعات دسترسی داشته باشند تا از روی ناآگاهی دوچرخه نسازند. فهرستی از تصمیمات معماری گرفته شده (ADR) با توجیه انتخاب تهیه کنید.

• بررسی کنید مدیر بسته را قبل از شروع کار جدید
• بررسی کنید کتابخانه استاندارد زبان را — 80% کارهای معمولی را پوشش می‌دهد
• استفاده کنید از بازبینی کد برای شناسایی دوچرخه‌ها
• مستند کنید تصمیمات گرفته شده درباره انتخاب کتابخانه‌ها
• به‌روز کنید دانش اکوسیستم را در کنفرانس‌ها و وبلاگ‌ها

سندرم 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);