پروگرامنگ میں سائیکل: یہ کیا ہے، وجوہات اور اس سے کیسے بچیں

پروگرامنگ میں سائیکل کیا ہے

سائیکل — ڈیولپرز کمیونٹی کی ایک اصطلاح ہے جو کسی ایسی فعالیت کے اپنے نفاذ کو ظاہر کرتی ہے جو پہلے سے کسی تیار لائبریری، فریم ورک یا سروس میں موجود ہو۔ انگریزی میں اظہار reinventing the wheel — پہیے کی ایجاد — استعمال ہوتا ہے۔ اردو میں بھی «سائیکل»، «خود ساختہ نفاذ» اور «اپنی سائیکل» جیسے الفاظ استعمال ہوتے ہیں۔

استعارے کی اصل اس حقیقت سے جڑی ہے کہ پہیہ انسانیت کی قدیم ترین ایجادات میں سے ایک ہے۔ 21ویں صدی میں اسے دوبارہ ایجاد کرنا بے معنی ہے۔ پروگرامنگ میں یہ تشبیہ اور بھی درست ہے: تیار لائبریریاں «پہیے» ہیں جو سالوں میں ہزاروں انجینئروں نے بہتر بنائے ہیں۔ کم معیار کا اپنا پہیہ بنانا وسائل کا ضیاع ہے۔

RedMonk نے اپنی تجزیاتی رپورٹ (2023) میں بتایا کہ اوسط تجارتی ایپلیکیشن تقریباً 500 بیرونی انحصار استعمال کرتی ہے۔ اگر ڈیولپرز ہر ایک کو خود لکھتے، تو پروجیکٹ کی لاگت کئی گنا بڑھ جاتی اور مارکیٹ تک پہنچنے کا وقت سالوں میں چلا جاتا۔ پیکیج مینیجرز (npm, Maven, PyPI, NuGet) کا ایکو سسٹم اسی لیے ہے تاکہ سائیکل ایجاد کرنے سے بچا جا سکے۔

سائیکل کی پہچان

وہ کوڈ جو سائیکل ہے، کئی علامتوں سے پہچانا جا سکتا ہے: وہ معیاری کام کو غیر معیاری طریقے سے حل کرتا ہے، اس میں ٹیسٹ یا دستاویزات نہیں ہوتیں، وہ edge cases کو سپورٹ نہیں کرتا جو تیار لائبریریوں میں طے شدہ ہیں۔ اکثر ایسا کوڈ «منفرد ضروریات» کے حساب سے لکھا جاتا ہے، جبکہ حقیقت میں یہ ضروریات عام سے مختلف نہیں ہوتیں۔

سائیکل اور کسٹم حل میں فرق

کسٹم حل اس وقت جائز ہے جب تیار لائبریری آرکیٹیکچرل یا لائسنس کی رکاوٹوں کی وجہ سے موزوں نہ ہو۔ سائیکل بغیر کسی معروضی وجہ کے بنایا جاتا ہے — «کھیلنے» کی خواہش، دوسروں کے کوڈ پر عدم اعتماد یا موجودہ ٹولز سے ناواقفیت کی وجہ سے۔ فرق اصولی ہے: کسٹم — ایک شعوری انتخاب، سائیکل — غلطی۔

ڈیولپر سائیکل کیوں ایجاد کرتے ہیں

پہلی اور سب سے عام وجہ — موجودہ حلوں سے ناواقفیت۔ جونیئر ڈیولپر کو معلوم نہیں ہو سکتا کہ JSON پارس کرنے کے لیے معیاری لائبریری میں پہلے سے فنکشن موجود ہے۔ اس کے بجائے وہ خود پارسر لکھے گا۔ یہ مسئلہ خاص طور پر beginners کے لیے اہم ہے جو زبان کے ایکو سسٹم میں نئے داخل ہوتے ہیں۔

دوسری وجہ — کنٹرول کا وہم۔ تجربہ کار ڈیولپر بعض اوقات یقین رکھتے ہیں کہ «وہ خود بہتر لکھیں گے» مقبول لائبریری کے مصنفین سے۔ اعداد و شمار اس کے برعکس بتاتے ہیں: لاکھوں پروجیکٹس میں استعمال ہونے والی لائبریری میں غلطی کا امکان نئے لکھے گئے کوڈ کے مقابلے میں بہت کم ہوتا ہے۔ Synopsys (2024) کے مطابق، Open Source کوڈ میں اوسطاً 0.1 خرابی فی ہزار لائنز ہوتی ہے، جبکہ کارپوریٹ کوڈ میں 1–2۔

تیسری وجہ — دوبارہ استعمال کی ثقافت کا فقدان۔ کمپنیوں میں جہاں کام شروع کرنے سے پہلے تیار حلوں کی تحقیق کرنا معمول نہیں، ہر ڈیولپر «اپنی سائیکل» بناتا ہے۔ یہ کوڈ کی fragmentation کا باعث بنتا ہے: ایک ہی پروجیکٹ میں HTTP-کلائنٹ کی تین مختلف implementations ہو سکتی ہیں جو مختلف ملازمین نے لکھی ہوں۔

نفسیاتی پہلو

IKEA اثر — ایک نفسیاتی رجحان جس میں انسان اپنی بنائی ہوئی چیز کو معروضی طور پر بہتر تیار چیز سے زیادہ اہمیت دیتا ہے۔ پروگرامنگ میں یہ «اپنی سائیکل» پر فخر اور اسے تیار لائبریری سے تبدیل کرنے کی خواہش نہ ہونے کے طور پر ظاہر ہوتا ہے، چاہے بعد والے کے واضح فوائد ہوں۔

پروجیکٹ میں سائیکل بنانے کے نتائج

معاشی نتائج سب سے زیادہ واضح ہیں۔ Stripe (2022) کے مطابق، ڈیولپرز اپنے 35% کام کا وقت ایسا کوڈ لکھنے میں صرف کرتے ہیں جو پہلے سے موجود ہے۔ 10 افراد کی ٹیم کی تنخواہوں کے حساب سے یہ تقریباً 200 ہزار ڈالر سالانہ ہے جو سائیکل ایجاد کرنے پر خرچ ہوتا ہے۔

تکنیکی نتائج میں کوڈ بیس کا بڑھنا، ٹیسٹ کوریج کا کم ہونا (خود ساختہ کوڈ عام طور پر کم ٹیسٹ کیا جاتا ہے)، بگز اور کمزوریوں میں اضافہ شامل ہے۔ اس کے علاوہ، ہر خود ساختہ جزو ایک اور ناکامی کا نقطہ ہے جس کی نگرانی اور دیکھ بھال ضروری ہے۔

Google نے اپنی تحقیق «Why Google Stores Billions of Lines of Code» (2023) میں نوٹ کیا کہ سب سے بڑی ٹیکنالوجی کمپنی میں بھی نئے انحصار شامل کرنے یا اپنا نفاذ لکھنے کا سخت عمل ہے۔ زیادہ تر اندرونی ٹیمیں پہلے کوڈ کے مشترکہ ذخیرے میں تیار حل تلاش کرتی ہیں۔

ٹیم پر اثر

سائیکل معلوماتی غیر ہم آہنگی پیدا کرتے ہیں: جب ایک ڈیولپر جاتا ہے، اس کا خود ساختہ جزو بغیر دستاویزات اور سپورٹ کے رہ جاتا ہے۔ ٹیم کے نئے اراکین کو غیر معیاری کوڈ سمجھنے میں وقت لگانا پڑتا ہے جو پیداواری کام پر صرف کیا جا سکتا تھا۔

کوڈ میں عام سائیکل کی مثالیں

سب سے عام مثال — JSON یا XML کا دستی پارسنگ، جبکہ تقریباً تمام جدید زبانوں میں اس کے لیے بلٹ ان ٹولز موجود ہیں۔ ڈیولپرز آبجیکٹ ٹری کے recursive traversal کے فنکشن لکھتے ہیں، یہ نہ جانتے ہوئے کہ JSON.parse() کام ایک لائن میں حل کرتا ہے۔

دوسری مثال — HTTP-کلائنٹ کا اپنا نفاذ۔ معیاری لائبریریاں (fetch, axios, OkHttp, URLSession) کیشنگ، دوبارہ کنکشن، ٹائم آؤٹ اور سیکیورٹی کو سپورٹ کرتی ہیں۔ خود ساختہ کلائنٹ عام طور پر ان میں سے کم از کم ایک ضرورت کو نظرانداز کرتا ہے، جو پروڈکشن میں بگز کا باعث بنتا ہے۔

تیسری مثال — SLF4J، Winston یا Log4j استعمال کرنے کے بجائے اپنا لاگنگ سسٹم۔ ڈیولپر ہفتے صرف کرتا ہے وہ لکھنے میں جو تیار لائبریریاں باکس سے باہر کرتی ہیں، جس میں rotation، لاگنگ لیولز، async رائٹنگ اور monitoring سسٹمز کے ساتھ انضمام شامل ہے۔

# سائیکل — دستی 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 سالوں میں تیار ہوئے ہیں، کیشنگ، lazy loading، migrations اور درجنوں DBMS کو سپورٹ کرتے ہیں۔ خود ساختہ 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);