الكود الميت وكود الزومبي في التطوير: ما هي، أسبابها والبحث عنها

ما هو الكود الميت؟

الكود الميت (dead code) — هو كود مصدر مضمن في البرنامج، لكنه لا يتم تنفيذه أبداً تحت أي سيناريو استخدام. يقوم المترجم أو المفسر بمعالجته، لكن في وقت التشغيل لا يصل التحكم أبداً إلى هذه الأجزاء.

أمثلة تقليدية على الكود الميت: متغيرات يتم تعيين قيمة لها لكنها لا تُقرأ أبداً؛ دوال أو طرق لا يتم استدعاؤها في أي مكان؛ فروع شرطية لا تصبح صحيحة أبداً (if(false))؛ حلقات تكرار لا يتم تنفيذ جسمها ولو مرة واحدة.

وفقاً لتقرير SonarQube State of Code Quality (2025)، حوالي 15 بالمائة من جميع التحذيرات في مشاريع Java التجارية مرتبطة بطرق وحقول خاصة غير مستخدمة. في مشاريع JavaScript، قد تصل نسبة الكود غير المستخدم إلى 30 بالمائة بسبب الطبيعة الديناميكية للغة وكثرة المكتبات الخارجية.

افحص مشروعك بانتظام للتأكد من عدم وجود كود ميت — خاصة بعد إعادة الهيكلة الكبيرة وحذف الميزات. استيراد منسي واحد أو دالة غير مستخدمة اليوم قد تتحول غداً إلى كود زومبي يضلل أعضاء الفريق الجدد.

الفرق بين الكود الميت وكود الزومبي

كود الزومبي (zombie code) — هو حالة خاصة من الكود الميت يتميز بسياق تاريخي. كان كود الزومبي يعمل في وقت ما، لكنه بعد التغييرات في النظام توقف عن أن يكون قابلاً للوصول، ومع ذلك لم يتم حذفه، بل تُرك «احتياطاً».

الفرق بين الكود الميت وكود الزومبي — في المنشأ. الكود الميت قد يكون كُتب بشكل خاطئ (لم يعمل أبداً)، بينما كود الزومبي — هو كود حي سابق فقد أهميته بعد إعادة الهيكلة. على سبيل المثال، دالة حساب الخصم وفق منطق تجاري قديم تم استبداله بآخر جديد، لكن الطريقة القديمة لم تُحذف — احتياطاً في حالة الحاجة للعودة إليها.

الخطر الرئيسي لكود الزومبي — وهم الوظائف العاملة. يرى مطور جديد دالة، يقرأ توثيقها، يفترض أنها تُستدعى في مكان ما — ويضيع وقتاً في دراسة أثرية. عند محاولة استدعائها مباشرة قد يتبين أنها تعتمد على كيانات محذوفة أو واجهات برمجية قديمة.

تتبع كود الزومبي عبر تاريخ git: إذا لم يتم تعديل دالة لمدة عامين ولا تُستخدم — فهي زومبي. احذفها دون تردد، لأن git يحتفظ بالسجل، ويمكن دائماً استعادة الكود عند الحاجة.

أسباب ظهور الكود الميت

السبب الأول والأكثر شيوعاً — التطوير التكراري مع إعادة هيكلة غير كاملة. يضيف الفريق وظائف جديدة تحل محل القديمة، لكنه لا يحذف الوحدات المستبدلة. تتراكم هذه «الذيول» عبر السباقات، وبعد عام يكتسي المشروع بطبقة من الكود الميت.

السبب الثاني — الاختبار A/B ومفاتيح الميزات. قد تثبت شروط تفعيل الميزة الجديدة مع الوقت (على سبيل المثال، true دائماً)، لكن فرع else مع المنطق البديل يبقى في الكود. يخشى المطورون حذفه خوفاً من كسر النظام عن طريق الخطأ إذا تم تبديل المفتاح للخلف.

السبب الثالث — التوليد التلقائي والنسخ واللصق. مولدات الكود (IDE، قوالب) تنشئ قوالباً بطرق لا يملؤها المطور أو لا يستخدمها. الكود المنسوخ من مشروع آخر غالباً ما يحتوي على أقسام كاملة غير ذات صلة بالسياق الجديد.

السبب الرابع — الخوف من الحذف. في المشاريع الكبيرة، يخشى المطورون حذف الكود لأنهم غير متأكدين من أنه لا يُستخدم في أي مكان. يزداد هذا الخوف مع ضعف نظام الاختبارات: إذا لم يكن هناك فحص تلقائي، قد يؤدي الحذف إلى أخطاء تُكتشف فقط في بيئة الإنتاج.

ما خطورة الكود الميت

الكود الميت يؤثر مباشرة على أربعة جوانب من جودة المشروع: أداء البناء، حجم الأرتيفكت، العبء المعرفي للفريق وموثوقية إعادة الهيكلة.

زيادة وقت الترجمة: يعالج المترجم الملفات غير المستخدمة، يحلل التبعيات ويولد البايت كود أو الكود الآلي لأجزاء لن تُشغل أبداً. في المشاريع الكبيرة، هذا يضيف دقائق لكل بناء. بالنسبة للغات المفسرة (JavaScript، Python)، يزداد وقت تحميل الوحدة واستهلاك الذاكرة.

خطر الأخطاء عند التعديل: مطور يعدل الكود ولا يشك في أن الدالة تُستخدم فقط في فرع ميت. بعد إعادة الهيكلة، يتوقف الكود الميت عن الترجمة أو ينتج أخطاء — يضيع الفريق وقتاً في تشخيص مشكلة لا تؤثر على عمل التطبيق.

العبء المعرفي — أغلى عامل. كل دالة غير مستخدمة تتطلب انتباهاً عند قراءة الكود. يبذل المطور طاقة ذهنية لفهم سبب وجود هذا الكود وأين يُستدعى. أظهرت دراسة Developer Productivity Lab (2025): حذف 20 بالمائة من الكود الميت يقلل وقت التعرف على الكود (onboarding time) بمعدل 18 بالمائة.

احذف الكود الميت فور اكتشافه. كل يوم تأخير يزيد احتمال أن يضيع أحد أعضاء الفريق ساعات في دراسة أثرية كان يجب حذفها أمس.

أدوات البحث عن الكود الميت

يتم البحث عن الكود الميت بطريقتين رئيسيتين: التحليل الثابت (بدون تشغيل البرنامج) والتحليل الديناميكي (قياس التغطية في وقت التشغيل). كل نهج فعال لأنواع مختلفة من الكود الميت.

المحللات الثابتة تدعم جميع لغات البرمجة الشائعة. لـ Java و Kotlin — SonarQube، IntelliJ IDEA Inspections، SpotBugs. لـ JavaScript و TypeScript — ESLint مع قواعد no-unused-vars و no-unused-modules. لـ Swift — SwiftLint مع قاعدة unused_declaration. لـ Python — pylint مع خيار unused-import و vulture للبحث العميق.

مثال للبحث في Kotlin عبر ProGuard

// build.gradle.kts - تكوين ProGuard لنظام Android
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 يُدرج كل الكود المحذوف.

التحليل الديناميكي عبر تغطية الاختبارات

أدوات تغطية الكود (JaCoCo لـ Java، XCTest coverage لـ Swift، Istanbul لـ JavaScript) تظهر أي الأسطر والفروع يتم تنفيذها أثناء الاختبارات. الطرق ذات التغطية الصفرية — مرشحة لتكون كوداً ميتاً. لكن غياب التغطية لا يضمن عدم استدعاء الكود في الإنتاج — للتأكد الكامل استخدم مزيجاً من التحليل الثابت والديناميكي.

اضبط خط CI الخاص بك بحيث يفشل البناء عند تجاوز حد التصريحات غير المستخدمة. بوابة جودة SonarQube بقاعدة «نسبة الكود الخاص غير المستخدم لا تتجاوز 3%» تمنع تراكم الكود الميت على مستوى عملية التطوير.

كيفية حذف الكود الميت بأمان

عملية حذف الكود الميت تتكون من أربع خطوات: ابحث، تحقق، احذف، تحقق مرة أخرى. تخطي أي خطوة يزيد خطر الانحدار.

الخطوة الأولى — البحث عن المرشحين عبر محلل ثابت. احصل على تقرير عن التصريحات غير المستخدمة: الدوال، الفئات، المتغيرات، الاستيرادات. صفّ التنبيهات الخاطئة — أحياناً تخطئ المحللات في حالة الانعكاس (reflection)، التحميل الديناميكي للفئات أو الاستدعاءات المخفية عبر التسلسل.

الخطوة الثانية — التحقق عبر 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.

طبّق قاعدة: لا يجب أن يحتوي أي طلب سحب على كود ميت جديد. أضف مدققاً في خطافات ما قبل الالتزام يمنع الالتزام في حالة وجود متغيرات أو استيرادات غير مستخدمة. الوقاية دائماً أرخص من التنظيف.