ڈیولپمنٹ میں مردہ کوڈ اور زومبی کوڈ: یہ کیا ہے، وجوہات اور تلاش

مردہ کوڈ کیا ہے؟

مردہ کوڈ (dead code) وہ سورس کوڈ ہے جو پروگرام میں شامل ہے لیکن استعمال کے کسی بھی منظر نامے میں کبھی عمل میں نہیں آتا۔ کمپائلر یا انٹرپریٹر اسے پروسیس کرتا ہے، لیکن رن ٹائم میں کنٹرول کبھی ان حصوں تک نہیں پہنچتا۔

مردہ کوڈ کی کلاسک مثالیں: متغیرات جنہیں قیمت دی گئی ہے لیکن کبھی پڑھا نہیں جاتا؛ فنکشنز یا طریقے جو کہیں کال نہیں کیے جاتے؛ شرطی شاخیں جو کبھی سچ نہیں ہوتیں (if(false))؛ لوپس جن کا باڈی ایک بار بھی عمل میں نہیں آتا۔

SonarQube State of Code Quality (2025) رپورٹ کے مطابق، تجارتی Java پروجیکٹس میں تقریباً 15 فیصد انتباہات غیر استعمال شدہ پرائیویٹ طریقوں اور فیلڈز سے متعلق ہیں۔ JavaScript پروجیکٹس میں، زبان کی متحرک نوعیت اور تیسری پارٹی لائبریریوں کی کثرت کی وجہ سے غیر استعمال شدہ کوڈ کا تناسب 30 فیصد تک پہنچ سکتا ہے۔

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

مردہ کوڈ اور زومبی کوڈ میں فرق

زومبی کوڈ (zombie code) مردہ کوڈ کی ایک خاص صورت ہے جو تاریخی سیاق و سباق سے ممتاز ہوتی ہے۔ زومبی کوڈ کبھی کام کرتا تھا، لیکن سسٹم میں تبدیلیوں کے بعد ناقابل رسائی ہو گیا، پھر بھی اسے حذف نہیں کیا گیا، بلکہ «احتیاطاً» چھوڑ دیا گیا۔

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

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

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

مردہ کوڈ کے ظاہر ہونے کی وجوہات

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

دوسری وجہ — A/B ٹیسٹنگ اور فیچر ٹوگل۔ نئی خصوصیت کو فعال کرنے کی شرائط وقت کے ساتھ مستحکم ہو سکتی ہیں (مثال کے طور پر، ہمیشہ true)، لیکن متبادل منطق کے ساتھ else شاخ کوڈ میں رہتی ہے۔ ڈیولپرز اسے حذف کرنے سے ڈرتے ہیں تاکہ اگر ٹوگل واپس کیا جائے تو غلطی سے سسٹم نہ ٹوٹے۔

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

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

مردہ کوڈ کے خطرات

مردہ کوڈ براہ راست پروجیکٹ کے معیار کے چار پہلوؤں کو متاثر کرتا ہے: بلڈ کارکردگی، نوادرات کا سائز، ٹیم کا علمی بوجھ اور ری فیکٹرنگ کی بھروسے مندی۔

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

تبدیلی پر خرابی کا خطرہ: ڈیولپر کوڈ تبدیل کرتا ہے اور شک نہیں کرتا کہ فنکشن صرف مردہ شاخ میں استعمال ہوتا ہے۔ ری فیکٹرنگ کے بعد مردہ کوڈ کمپائل ہونا بند کر دیتا ہے یا خرابیاں پیدا کرتا ہے — ٹیم ایک ایسے مسئلے کی تشخیص میں وقت ضائع کرتی ہے جو ایپلیکیشن کے کام کو متاثر نہیں کرتا۔

علمی بوجھ — سب سے مہنگا عنصر۔ ہر غیر استعمال شدہ فنکشن کوڈ پڑھتے وقت توجہ کا تقاضا کرتا ہے۔ ڈیولپر ذہنی توانائی خرچ کرتا ہے یہ سمجھنے کے لیے کہ یہ کوڈ کیوں موجود ہے اور اسے کہاں کال کیا جاتا ہے۔ Developer Productivity Lab (2025) کی تحقیق نے دکھایا: مردہ کوڈ کا 20 فیصد حذف کرنے سے آن بورڈنگ کا وقت اوسطاً 18 فیصد کم ہو جاتا ہے۔

مردہ کوڈ کو دریافت کرتے ہی فوری حذف کریں۔ ہر دن کی تاخیر اس امکان کو بڑھاتی ہے کہ ٹیم کا کوئی فرد ایک نوادرات کے مطالعے میں گھنٹے ضائع کرے گا جسے کل ہی حذف کر دینا چاہیے تھا۔

مردہ کوڈ کی تلاش کے اوزار

مردہ کوڈ کی تلاش دو اہم طریقوں سے کی جاتی ہے: جامد تجزیہ (پروگرام چلائے بغیر) اور متحرک تجزیہ (رن ٹائم میں کوریج پروفائلنگ)۔ ہر طریقہ مختلف اقسام کے مردہ کوڈ کے لیے مؤثر ہے۔

جامد تجزیہ کار تمام مقبول پروگرامنگ زبانوں کو سپورٹ کرتے ہیں۔ Java اور Kotlin کے لیے — SonarQube, IntelliJ IDEA Inspections, SpotBugs۔ JavaScript اور TypeScript کے لیے — no-unused-vars اور no-unused-modules قواعد کے ساتھ ESLint۔ Swift کے لیے — unused_declaration قاعدے کے ساتھ SwiftLint۔ Python کے لیے — unused-import آپشن کے ساتھ pylint اور گہری تلاش کے لیے vulture۔

ProGuard کے ذریعے Kotlin میں تلاش کی مثال

// build.gradle.kts - Android کے لیے ProGuard ترتیب
android {
    buildTypes {
        release {
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

// proguard-rules.pro - صرف ضروری کلاسز رکھیں
-keep class com.example.app.** { *; }
-assumenosideeffects class Timber {
    static <methods>;
}

ProGuard نہ صرف غیر استعمال شدہ کلاسز اور طریقوں کو حذف کرتا ہے بلکہ ریلیز بلڈ میں ناموں کو بھی چھوٹا کرتا ہے۔ ProGuard کے فعال ہونے کے ساتھ بلڈ خود بخود دکھاتا ہے کہ کون سی کلاسیں اور طریقے غیر استعمال شدہ سمجھے جاتے ہیں — usage.txt رپورٹ میں تمام حذف شدہ کوڈ درج ہوتا ہے۔

ٹیسٹ کوریج کے ذریعے متحرک تجزیہ

کوڈ کوریج کے اوزار (Java کے لیے JaCoCo، Swift کے لیے XCTest coverage، JavaScript کے لیے Istanbul) دکھاتے ہیں کہ ٹیسٹ کے دوران کون سی لائنیں اور شاخیں عمل میں آتی ہیں۔ صفر کوریج والے طریقے — مردہ کوڈ کے امیدوار۔ تاہم کوریج کی کمی اس بات کی ضمانت نہیں دیتی کہ کوڈ پروڈکشن میں کال نہیں ہوتا — مکمل یقین کے لیے جامد اور متحرک تجزیہ کا مجموعہ استعمال کریں۔

اپنی CI پائپ لائن کو اس طرح ترتیب دیں کہ غیر استعمال شدہ اعلانات کی حد عبور ہونے پر بلڈ ناکام ہو جائے۔ قاعدہ «غیر استعمال شدہ پرائیویٹ کوڈ کا تناسب 3% سے زیادہ نہ ہو» کے ساتھ SonarQube Quality Gate ترقی کے عمل کی سطح پر مردہ کوڈ کے جمع ہونے کو روکتا ہے۔

مردہ کوڈ محفوظ طریقے سے کیسے ہٹائیں

مردہ کوڈ ہٹانے کا عمل چار مراحل پر مشتمل ہے: تلاش کریں، جانچیں، ہٹائیں، دوبارہ جانچیں۔ کسی بھی مرحلے کو چھوڑنا رجعت کا خطرہ بڑھاتا ہے۔

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

دوسرا مرحلہ — git blame اور تبدیلیوں کی تاریخ کے ذریعے جانچ۔ دیکھیں کہ کوڈ کب اور کیوں لکھا گیا تھا۔ اگر کوڈ کسی ایسی خصوصیت کا حصہ تھا جو فیچر ٹوگل سے غیر فعال ہے — یقینی بنائیں کہ ٹوگل مستحکم ہے اور دوبارہ آن نہیں کیا جائے گا۔ جس کوڈ کو ہٹانے میں تردد ہو اسے کمنٹ کریں اور ایک ماہ بعد دوبارہ جانچ کے لیے TODO ٹکٹ چھوڑ دیں۔

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

// before - ایک ہی فائل میں مردہ کوڈ اور زومبی کوڈ
int calculateV1(int price) { // کہیں کال نہیں کیا گیا
    int tax = price * 0.18;
    return price + tax;
}

int calculateV2(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

// after - مردہ کوڈ ہٹا دیا گیا، زومبی کوڈ صاف کر دیا گیا
int calculatePrice(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

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

قاعدہ نافذ کریں: کوئی بھی پل ریکویسٹ نیا مردہ کوڈ پر مشتمل نہیں ہونا چاہیے۔ پری کمٹ ہکس میں لنٹر شامل کریں جو غیر استعمال شدہ متغیرات یا امپورٹس کی صورت میں کمٹ کو روکتا ہے۔ روک تھام ہمیشہ صفائی سے سستی ہوتی ہے۔