سپاگیٹی کوڈ کیا ہے

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

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

IEEE (2022) کے مطابق، بڑے منصوبوں میں تمام خرابیوں کا تقریباً 35% الجھی ہوئی کوڈ ساخت کی وجہ سے ہوتا ہے، نہ کہ ڈویلپر کی منطقی غلطیوں کی وجہ سے۔ ڈویلپر غلطی اس لیے نہیں کرتا کہ اس نے کام غلط سمجھا، بلکہ اس لیے کہ وہ سپاگیٹی کوڈ میں عملدرآمد کے بہاؤ کو ٹریس نہیں کر سکا۔

دیگر اینٹی پیٹرن سے کلیدی فرق

اگر خراب کوڈ ایک فنکشن یا فائل کے پیمانے پر خراب کوڈ ہے، تو سپاگیٹی کوڈ پوری ایپلیکیشن کے پیمانے پر خراب آرکیٹیکچر ہے۔ نوڈل انفرادی طور پر اچھی طرح لکھے گئے فنکشنز پر مشتمل ہو سکتا ہے، لیکن ان کا تعامل بے ترتیب اور غیر متوقع ہوتا ہے۔

اصطلاح کی تاریخ اور goto کا دور

اصطلاح “سپاگیٹی کوڈ” 1970 کی دہائی میں goto اسٹیٹمنٹ کی تنقید کے ساتھ ظاہر ہوئی۔ ابتدائی پروگرامنگ زبانوں (BASIC، FORTRAN، COBOL) میں، goto عملدرآمد کے بہاؤ کو کنٹرول کرنے کا بنیادی طریقہ تھا۔ ایک پروگرام نمبر والی لائنوں کا ایک سلسلہ تھا، اور goto ان میں سے کسی پر بھی چھلانگ لگانے کی اجازت دیتا تھا۔ اس نے چھلانگوں کا ایک “الجھاو” پیدا کیا جسے سلجھانا ناممکن تھا۔

1968 میں، ایڈسگر ڈجکسٹرا نے اپنا مشہور خط “Go To Statement Considered Harmful” شائع کیا، جس نے ساختی پروگرامنگ کے دور کا آغاز کیا۔ ڈجکسٹرا نے ثابت کیا کہ کسی بھی الگورتھم کو goto کے بغیر، صرف تین تعمیرات کا استعمال کرتے ہوئے لاگو کیا جا سکتا ہے: ترتیب، شاخ (if) اور لوپ (while)۔ یہ جدید پروگرامنگ کی بنیاد بن گیا۔

ساختی پروگرامنگ نے مسئلہ کو مکمل طور پر ختم نہیں کیا۔ سپاگیٹی کوڈ ایک نئی سطح پر منتقل ہو گیا — جسمانی gotos کے بجائے، ڈویلپرز نے منطقی “goto” بنانا شروع کر دیے: عالمی متغیرات، JavaScript میں کال بیک ہیل، پیچیدہ کال زنجیریں اور اجزاء کے درمیان مضمر انحصار۔ مسئلہ باقی رہا، صرف شکل بدل گئی۔

goto کی جدید شکلیں

کال بیک ہیل، گہرائی سے نیسٹڈ Promises، غلطی سے نمٹنے کے بغیر async/await، ایسے واقعات جنہیں کوئی نہیں سمجھتا کہ کون یا کب متحرک کرتا ہے — یہ سب سپاگیٹی کوڈ کی جدید اقسام ہیں۔ اینٹی پیٹرن زندہ ہے اور پھل پھول رہا ہے، بس اب یہ goto اسٹیٹمنٹ استعمال نہیں کرتا۔

منصوبے میں سپاگیٹی کوڈ کی علامات

پرتوں کی کمی — پہلی اور اہم علامت۔ سپاگیٹی کوڈ میں، کاروباری منطق، ڈیٹا بیس آپریشنز، HTML مارک اپ اور نیٹ ورک کمیونیکیشن سب ایک فائل یا ایک طریقہ میں ملے ہوتے ہیں۔ ڈیٹا بیس کیوری کو تبدیل کرنا UI ڈسپلے کو توڑ سکتا ہے کیونکہ ان پرتوں کا کوڈ الگ نہیں ہے۔

عالمی متغیرات اور سنگلٹن — دوسری واضح علامت۔ جب ایپلیکیشن کی حالت عالمی اشیاء میں محفوظ ہوتی ہے، عملدرآمد کا بہاؤ غیر متوقع ہو جاتا ہے۔ کوئی بھی فنکشن عالمی حالت کو تبدیل کر سکتا ہے، اور یہ ٹریس کرنا کہ یہ کہاں اور کب ہوا عملی طور پر ناممکن ہے۔

گاڈ کلاسز اور گاڈ فنکشنز — تیسری علامت۔ 2000+ لائنوں والی کلاس جو کاروباری منطق، ڈسپلے اور ڈیٹا آپریشنز کو سنبھالتی ہے — یہ عام سپاگیٹی کوڈ ہے۔ ایک فنکشن جو 10 پیرامیٹر لیتا ہے اور 5 مختلف کام کرتا ہے — وہ بھی سپاگیٹی۔

ٹیسٹ کے ذریعے تشخیص

اگر آپ 15 موک آبجیکٹ بنائے بغیر کسی فنکشن کے لیے یونٹ ٹیسٹ نہیں لکھ سکتے — یہ سپاگیٹی کوڈ ہے۔ اگر ایک ماڈیول کی جانچ کے لیے پوری ایپلیکیشن انفراسٹرکچر شروع کرنے کی ضرورت ہے — یہ سپاگیٹی کوڈ ہے۔ ناقابل جانچی الجھے ہوئے آرکیٹیکچر کا ایک معروضی اشارہ ہے۔

نوڈل کوڈ کیوں ظاہر ہوتا ہے

آرکیٹیکچرل ڈیزائن کی کمی — سب سے عام وجہ۔ جب کوئی ٹیم بغیر منصوبہ کے کوڈ لکھنا شروع کرتی ہے، “چلتے چلتے” آرکیٹیکچر کا انتخاب کرتی ہے، تو نتیجہ لازمی طور پر سپاگیٹی میں بدل جاتا ہے۔ ہر نئی خصوصیت وہاں شامل کی جاتی ہے جہاں “ابھی آسان ہے”، نہ کہ جہاں اس کا منطقی تعلق ہے۔

ارتقائی ترقی — دوسری وجہ۔ ایک منصوبہ ایک چھوٹی اسکرپٹ کے طور پر شروع ہوتا ہے، پھر خصوصیات کے ساتھ بڑھتا ہے، پھر ایک ایپلیکیشن اور پھر ایک یک سنگی بن جاتا ہے۔ اس دوران آرکیٹیکچر پر نظر ثانی نہیں کی جاتی۔ جو 100 لائنوں کے کوڈ کے لیے کام کرتا تھا، وہ 100,000 لائنوں کے لیے تباہی بن جاتا ہے۔

SOLID اصولوں کی خلاف ورزی — تیسری وجہ۔ خاص طور پر واحد ذمہ داری کا اصول (S) اور انحصار الٹاؤ کا اصول (D)۔ جب ایک کلاس ہر چیز کے لیے ذمہ دار ہوتی ہے، انحصار سخت ہوتے ہیں اور ماڈیول مضبوطی سے جڑے ہوتے ہیں — آپ کو سپاگیٹی کوڈ ملتا ہے۔

وقت کا عنصر

آخری تاریخ اور ہاٹ فکس ثقافت — سپاگیٹی کوڈ کے عمل انگیز۔ جب “کل ضرورت تھی”، ڈویلپرز آرکیٹیکچر کے بارے میں سوچے بغیر پہلی دستیاب جگہ پر کوڈ داخل کر دیتے ہیں۔ اس طرح کے دس ہاٹ فکس — اور ایپلیکیشن کا آرکیٹیکچر تباہ ہو جاتا ہے۔

سپاگیٹی کوڈ کے نتائج

بنیادی نتیجہ — کوڈ بیس پر کنٹرول کا کھو جانا۔ ڈویلپرز یہ سمجھنا چھوڑ دیتے ہیں کہ ایپلیکیشن مجموعی طور پر کیسے کام کرتی ہے۔ ایک جگہ تبدیلی دوسری، بظاہر غیر متعلقہ جگہ کو توڑ دیتی ہے۔ ہر پیچ دو نئے بگ پیدا کرتا ہے۔ ٹیم “تبدیلیوں کے خوف” کی حالت میں داخل ہو جاتی ہے۔

ٹیم کی پیداواری صلاحیت تیزی سے گرتی ہے۔ Microsoft Research (2023) نے دکھایا کہ سپاگیٹی کوڈ میں نئی خصوصیت شامل کرنے کا وقت کوڈ بیس کے سائز کے مقابلے میں مربع طور پر بڑھتا ہے۔ صاف آرکیٹیکچر کے لیے، یہ اضافہ لکیری ہے۔ فرق 50,000+ لائنوں کے کوڈ پر اہم ہو جاتا ہے۔

سیکورٹی — ایک اور شکار۔ سپاگیٹی کوڈ میں، غیر ہینڈل شدہ استثناء، غلط ان پٹ توثیق، یا ڈیٹا کے رساو کو نظر انداز کرنا آسان ہے۔ الجھے ہوئے آرکیٹیکچر والے منصوبے میں سیکورٹی آڈٹ عملی طور پر ناممکن ہے — وہ تمام مقامات تلاش کرنا جہاں صارف کا ان پٹ استعمال ہوتا ہے، ناقابل عمل ہے۔

ٹیم پر اثر

ملازمین کی تبدیلی کی شرح سپاگیٹی کوڈ والے منصوبوں میں اوسط سے زیادہ ہے۔ تجربہ کار ڈویلپرز چلے جاتے ہیں کیونکہ وہ “نوڈل” کے ساتھ کام نہیں کرنا چاہتے۔ نئے ملازمین کوڈ کو نہیں سمجھ سکتے اور پہلے مہینوں میں چلے جاتے ہیں۔ منصوبہ مہارت کھو دیتا ہے، جو کوڈ کے معیار کو مزید خراب کرتا ہے — ایک شیطانی چکر۔

سپاگیٹی کوڈ کو کیسے ری فیکٹر کریں

پہلا — پرتوں کو الگ کرکے شروع کریں۔ کوڈ کو تین سطحوں میں تقسیم کریں: پیشکش (UI، کنٹرولرز)، کاروباری منطق (خدمات، استعمال کے معاملات) اور ڈیٹا تک رسائی (ذخیرے، DAO)۔ جزوی علیحدگی بھی فوری طور پر ساخت کو بہتر بناتی ہے اور کوڈ کو قابل جانچ بناتی ہے۔

دوسرا — ڈیپنڈنسی انجیکشن لاگو کریں۔ کنسٹرکٹرز یا پیرامیٹرز کے ذریعے انحصار منتقل کرکے براہ راست انحصار کی تخلیق کو تبدیل کریں۔ یہ اجزاء کے درمیان سخت روابط توڑ دیتا ہے اور ہر ماڈیول کو الگ تھلگ جانچنے کی اجازت دیتا ہے۔

تیسرا — گاڈ کلاسز اور گاڈ فنکشنز نکالیں۔ انہیں ایک ذمہ داری والی چھوٹی کلاسز اور طریقوں میں توڑیں۔ پیچیدہ ذیلی نظاموں کو آسان بنانے کے لیے Facade پیٹرن استعمال کریں۔ یاد رکھیں: 20 لائنوں والی کلاس 2000 لائنوں والی کلاس سے زیادہ واضح ہے۔

// سپاگیٹی — سب کچھ ایک طریقہ میں
function handleRequest(req, res) {
  const db = new Database("mysql://...");
  const user = db.query("SELECT * FROM users WHERE id =" + req.params.id);
  let html = "";
  html += "
" + user.name + "
";
  html += "
Balance: " + user.balance + "
";
  html += "";
  res.send(html);
}

// صاف آرکیٹیکچر — علیحدہ پرتیں
class UserController {
  constructor(userService) {
    this.userService = userService;
  }

  async getUser(req, res) {
    const user = await this.userService.findById(req.params.id);
    res.json(new UserResponse(user));
  }
}

class UserService {
  constructor(userRepository) {
    this.userRepository = userRepository;
  }

  async findById(id) {
    return await this.userRepository.findById(id);
  }
}

ری فیکٹرنگ حکمت عملی: جراحی کا طریقہ

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

نوڈل کوڈ کی روک تھام

آرکیٹیکچرل منصوبہ بندی — روک تھام کی بنیاد۔ ترقی شروع کرنے سے پہلے، ایک آرکیٹیکچرل انداز منظور کریں: MVC، MVVM، Clean Architecture، VIPER یا کوئی اور۔ انتخاب کو جواز بخشنے والا ADR (Architecture Decision Record) لکھیں۔ کوڈ کے جائزے میں آرکیٹیکچر کی پابندی کا مطالبہ کریں۔

انحصار الٹاؤ کا اصول (DIP) — سپاگیٹی کوڈ کے خلاف ایک طاقتور آلہ۔ اعلی سطحی ماڈیولز کو نچلی سطح کے ماڈیولز پر انحصار نہیں کرنا چاہیے۔ دونوں کو تجریدوں پر انحصار کرنا چاہیے۔ ڈیپنڈنسی انجیکشن اس اصول کا عملی نفاذ ہے۔

ٹیسٹ — بہترین روک تھام۔ اگر آپ کوڈ سے پہلے ٹیسٹ لکھتے ہیں (TDD)، تو آپ لازمی طور پر ڈھیلے جڑے ہوئے اجزاء ڈیزائن کرتے ہیں۔ قابل جانچ کوڈ اچھی ساختہ کوڈ ہے۔ ناقابل جانچ کوڈ تقریباً ہمیشہ سپاگیٹی کوڈ ہوتا ہے۔

• آرکیٹیکچر کوڈ سے پہلے: پرت اور انحصار کے منصوبوں کو منظور کریں
• ڈیپنڈنسی انجیکشن بطور اہم بائنڈنگ پیٹرن
• TDD یا کم از کم زیادہ ٹیسٹ کوریج
• کوڈ کا جائزہ صرف انداز نہیں بلکہ آرکیٹیکچر کی جانچ کے ساتھ
• باقاعدہ ری فیکٹرنگ ترقی کے عمل کے حصے کے طور پر

سپاگیٹی کوڈ سے لڑنے کے اوزار

SonarQube — چکراتی پیچیدگی، وراثت کی گہرائی، طریقہ کار کے سائز کو ٹریک کرتا ہے۔ JDepend (Java) — پیکیج کے درمیان انحصار کی پیمائش کرتا ہے۔ PhpMetrics — PHP منصوبوں کے لیے بحالی کی صلاحیت کا اشاریہ فراہم کرتا ہے۔ CI/CD میں میٹرکس کی نگرانی کریں — نوڈل کو بعد میں لڑنے کے بجائے ظاہر ہونے سے روکیں۔