ڈیولپمنٹ میں جنک — یہ کیا ہے، جنک کوڈ نقصان دہ کیوں ہے اور اسے کیسے ہٹائیں

جنک کوڈ کیا ہے؟

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

جنک چار زمروں میں تقسیم ہے۔ پہلا — اضافی انحصار: ایک ہی فیچر کے لیے شامل کردہ لائبریریاں جنہیں معیاری ٹولز سے لاگو کیا جا سکتا تھا۔ دوسرا — مردہ بوجھ: تبصرہ شدہ بلاکس، بغیر ٹکٹ کے TODO، خالی طریقے اور سٹب کلاسز۔ تیسرا — ڈپلیکیٹ حل: دو لائبریریاں ایک ہی کام کرتی ہیں (مثلاً ایک پروجیکٹ میں Gson اور Kotlin Serialization)۔ چوتھا — اوور انجینئرنگ: آرکیٹیکچرل پرتیں جو استعمال نہیں ہوتیں لیکن “صرف صورت میں” برقرار رکھی جاتی ہیں۔

Stripe Engineering Productivity (2025) تحقیق کے مطابق، ایک عام پروجیکٹ سے 10 فیصد جنک ہٹانے سے مکمل بلڈ وقت اوسطاً 22 فیصد کم ہو جاتا ہے۔ وجہ: ہر اضافی انحصار بلڈ گراف بڑھاتا ہے، ہر خالی تجرید سمجھنے میں وقت لیتی ہے، ہر تبصرہ شدہ بلاک توجہ بھٹکاتا ہے۔

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

جنک انحصار اور ان کی شناخت کیسے کریں

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

عام مثالیں: JSON پروسیسنگ کے لیے لائبریری جب پروجیکٹ پہلے سے Kotlin Serialization استعمال کرتا ہے (دو پارسر جنک ہے)؛ ایک StringUtils.isEmpty کال کے لیے Apache Commons Lang لائبریری جسے Kotlin extension isNullOrBlank سے بدلا جا سکتا ہے؛ دس میں سے ایک ماڈیول میں استعمال ہونے والی DI لائبریری جبکہ دیگر دستی طور پر کنسٹرکٹر کے ذریعے انحصار حاصل کرتے ہیں۔

ہر اضافی انحصار صرف بائنری میں اضافی کوڈ نہیں ہے۔ یہ کمزوریوں کے لیے حملے کی سطح بڑھاتا ہے: GitHub Advisory Database (2025) کے مطابق، موبائل پروجیکٹس میں 40 فیصد سنگین CVE عبوری انحصار سے آتے ہیں جنہیں ڈویلپر کنٹرول نہیں کرتے۔ جتنے کم انحصار، اتنی ہی چھوٹی حملے کی سطح۔

Android پروجیکٹ انحصار تجزیہ

// View Gradle dependency tree
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// Find unused dependencies (Gradle plugin)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Generate unused library report
./gradlew buildHealth

iOS کے لیے، swift package show-dependencies کمانڈ استعمال کریں جو مکمل انحصار درخت دکھاتا ہے۔ Xcode Build Timeline ٹول دکھاتا ہے کہ ہر لائبریری بلڈ میں کتنا وقت شامل کرتی ہے۔ اگر کوئی لائبریری 30 فیصد کمپائلیشن وقت لیتی ہے لیکن ایک اسکرین پر استعمال ہوتی ہے، تو وہ ہٹانے یا تبدیل کرنے کے لیے امیدوار ہے۔

Node.js (React Native) کے لیے، depcheck استعمال کریں — ایک یوٹیلیٹی جو package.json میں غیر استعمال شدہ انحصار ڈھونڈتی ہے، اور npm-check جو اضافی طور پر پرانے ورژن دکھاتا ہے۔ ایک اصول نافذ کریں: ہر نیا انحصار “معیاری ٹولز کیوں استعمال نہیں کیے جا سکتے” کے جواز کے ساتھ کوڈ جائزے سے گزرنا چاہیے۔

مردہ امپورٹ اور تبصرہ شدہ کوڈ

مردہ امپورٹ سب سے عام قسم کا جنک ہے۔ وہ رن ٹائم کو متاثر نہیں کرتے لیکن کمپائلیشن وقت بڑھاتے ہیں: کمپائلر ہر امپورٹ کو پروسیس کرتا ہے، خواہ وہ غیر استعمال شدہ ہو۔ بڑے پروجیکٹس میں، غیر استعمال شدہ امپورٹ ہٹانے سے بلڈ وقت 5–10 فیصد کم ہوتا ہے۔

جدید IDE خود بخود غیر استعمال شدہ امپورٹ کو سرمئی رنگ میں نمایاں کرتے ہیں۔ فائل محفوظ کرنے پر آٹو صفائی مرتب کریں: IntelliJ IDEA میں — Optimize Imports on the fly، Xcode میں — Editor > Remove Unused Imports۔ CI میں ایک جانچ شامل کریں: لنٹر کو غیر استعمال شدہ امپورٹ والے کمٹ بلاک کرنے چاہئیں۔

تبصرہ شدہ کوڈ ایک اور قسم کا جنک ہے۔ ڈویلپر ری فیکٹرنگ کے دوران فعالیت کو “khone سے بچنے” کے لیے بلاکس تبصرہ کرتے ہیں۔ تاہم، git تبدیلیوں کی مکمل تاریخ ذخیرہ کرتا ہے: کسی بھی ہٹائے گئے کوڈ کو ایک git revert یا git log -S کمانڈ سے بحال کیا جا سکتا ہے۔ master میں تبصرہ شدہ کوڈ ٹیم کے ساتھ بے عزتی ہے: ہر ڈویلپر ذہنی توانائی اس سوال پر خرچ کرتا ہے “یہ کیوں تبصرہ کیا گیا ہے اور کب اسے غیر تبصرہ کرنا چاہیے؟”

اصول: ذخیرہ میں کوئی تبصرہ شدہ کوڈ نہیں ہے۔ اگر کوڈ کی ضرورت نہیں ہے تو اسے مستقل طور پر حذف کریں۔ اگر کوڈ ضروری ہے لیکن عارضی طور پر غیر فعال ہے تو ٹکٹ اور میعاد ختم ہونے کی تاریخ کے ساتھ فیچر ٹوگل استعمال کریں۔ // TODO: remove after migration جیسے تبصرے — بغیر آخری تاریخ کے نہ چھوڑیں۔ ایک تاریخ مقرر کریں اور کیلنڈر سے خود کو یاد دہانی کروائیں۔

اضافی تجرید اور اوور انجینئرنگ

اوور انجینئرنگ آرکیٹیکچرل پرتیں بنانا ہے جو موجودہ مسائل حل نہیں کرتیں لیکن دیکھ بھال کی متقاضی ہیں۔ یہ جنک کی سب سے مشکل اقسام میں سے ایک ہے کیونکہ باضابطہ طور پر کوڈ “صحیح” ہے: یہ SOLID کی پیروی کرتا ہے، ٹیسٹوں سے ڈھکا ہوا ہے اور آرکیٹیکچر کے مطابق ہے۔ مسئلہ یہ ہے کہ یہ ضروری نہیں ہے۔

ایک کلاسک مثال ایک تجریدی UseCase کلاس ہے جس میں ایک ہی invoke طریقہ ہے جو صرف ایک ذخیرہ کو کال کرتا ہے۔ اگر UseCase کوئی منطق (کیشنگ، دوبارہ کوشش، تبدیلی) شامل نہیں کرتا اور صرف کال کو آگے بڑھاتا ہے، تو یہ ایک اضافی ہستی ہے۔ یہ پروجیکٹ میں نیویگیشن بڑھاتا ہے: ایک ڈویلپر UseCase کھولتا ہے، invoke → ذخیرہ دیکھتا ہے، اور بند کر دیتا ہے۔ وقت ضائع، فائدہ صفر۔

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

کٹ آف معیار: اگر کوئی تجرید تین مختلف سیاق و سباق میں دوبارہ استعمال نہیں ہوتا، تو اسے ہٹا دیں۔ تجرید اس وقت جائز ہے جب یہ واقعی تکرار کے مسئلے کو حل کرتا ہے، فرضی مستقبل کے منظرناموں کی پیشگوئی نہیں کرتا۔ YAGNI (You Ain’t Gonna Need It) اوور انجینئرنگ کو روکنے کا بہترین اصول ہے۔

جنک آڈٹ ٹولز

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

مکمل آڈٹ کے لیے، فی سپرنٹ buildHealth (Android) یا depcheck (Node.js) چلائیں۔ CI میں ایک ڈیش بورڈ بنائیں جو سپرنٹ کے لحاظ سے انحصار کی تعداد کا رجحان دکھائے۔ اگر تعداد بڑھ رہی ہے لیکن فعالیت متناسب طور پر نہیں بڑھ رہی، تو ٹیم جنک جمع کر رہی ہے۔

ڈپلیکیٹ کلاسز پر توجہ دیں — ایک غلطی جب دو لائبریریوں میں ایک ہی کلاس ہو۔ یہ نہ صرف جنک ہے بلکہ بلڈ تنازعات کا براہ راست ذریعہ بھی ہے۔ Gradle میں، یہ تنازعات force یا exclude کے ذریعے حل کیے جاتے ہیں، لیکن ہر ایسا حل اشارہ ہے کہ لائبریریوں میں سے ایک اضافی ہے۔

باقاعدہ پروجیکٹ صفائی کا عمل

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

اس عمل میں چار مراحل ہیں۔ پہلا — تشخیص: ٹولز چلائیں، رپورٹ حاصل کریں، ترجیح دیں۔ اعلی ترجیح: معلوم CVE والے انحصار اور ڈپلیکیٹ لائبریریاں۔ درمیانی ترجیح: مردہ امپورٹ اور تبصرہ شدہ کوڈ۔ کم ترجیح: اضافی تجرید (دستی تجزیہ درکار)۔

دوسرا — صفائی: مردہ انحصار ہٹائیں، ڈپلیکیٹ لائبریریوں کو ایک سے بدلیں، تبصرہ شدہ کوڈ حذف کریں۔ ہر تبدیلی واضح پیغام کے ساتھ علیحدہ کمٹ ہونی چاہیے: “remove unused dependency: gson (replaced by kotlinx.serialization)”، “delete commented code in LoginViewModel.”

تیسرا — تصدیق: پروجیکٹ بنائیں، ٹیسٹ چلائیں، UI چیک کریں۔ اگر انحصار ہٹانے کے بعد ٹیسٹ پاس ہو جائیں تو انحصار واقعی غیر ضروری تھا۔ اگر ٹیسٹ ناکام ہو جائیں تو کہیں چھپا ہوا حوالہ ہے جسے جامد تجزیہ کار نے نہیں پکڑا۔

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