الكود غير المفيد في التطوير — ما هو، ولماذا هو ضار، وكيف تزيله

ما هو الكود غير المفيد؟

الكود غير المفيد (junk code) هو مصطلح جماعي للكود والتكوينات والتبعيات الموجودة في المشروع لكنها لا تقدم قيمة وظيفية. الكود غير المفيد ليس بالضرورة معطلاً أو غير مستخدم — المشكلة أن وجوده يزيد من سوء مقاييس المشروع دون مبرر كافٍ.

ينقسم الكود غير المفيد إلى أربع فئات. الأولى — التبعيات الزائدة: مكتبات أُضيفت لميزة واحدة كان يمكن تنفيذها بأدوات قياسية. الثانية — الوزن الميت: كتل معلقة، TODO بدون تذاكر، دوال فارغة وفئات هيكلية. الثالثة — الحلول المكررة: مكتبتان تفعلان الشيء نفسه (مثل Gson و Kotlin Serialization في مشروع واحد). الرابعة — الهندسة المفرطة: طبقات معمارية لا تُستخدم لكنها تُصان “احتياطاً.”

وفقاً لبحث Stripe Engineering Productivity (2025)، فإن إزالة 10 بالمائة من الكود غير المفيد من مشروع نموذجي تقلل وقت البناء الكامل بمتوسط 22 بالمائة. السبب: كل تبعية إضافية تزيد من رسم البناء، كل تجريد فارغ يتطلب وقتاً للفهم، كل كتلة معلقة تشتت الانتباه.

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

التبعيات غير المفيدة وكيفية اكتشافها

التبعيات غير المفيدة هي المكتبات والحزم المضافة إلى مشروع لا تُستخدم مباشرة في الكود، أو تُستخدم فقط لميزة واحدة يمكن تنفيذها ببساطة باستخدام APIs قياسية.

أمثلة نموذجية: مكتبة لمعالجة JSON عندما يستخدم المشروع بالفعل Kotlin Serialization (محللان هذا غير مفيد)؛ مكتبة Apache Commons Lang لاستدعاء StringUtils.isEmpty واحد يمكن استبداله بامتداد Kotlin isNullOrBlank؛ مكتبة DI تُستخدم في وحدة واحدة من عشر بينما تتلقى الوحدات الأخرى التبعيات يدوياً عبر المنشئ.

كل تبعية إضافية ليست مجرد كود إضافي في الملف الثنائي. إنها تزيد مساحة الهجوم للثغرات: وفقاً لقاعدة بيانات GitHub Advisory (2025)، 40 بالمائة من CVEs الحرجة في المشاريع المحمولة تأتي من تبعيات انتقالية لا يتحكم فيها المطورون. كلما قلّت التبعيات، صغرت مساحة الهجوم.

تحليل تبعيات مشروع 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 بالمائة.

بيئات التطوير الحديثة تبرز الاستيرادات غير المستخدمة تلقائياً باللون الرمادي. قم بإعداد التنظيف التلقائي عند حفظ الملف: في IntelliJ IDEA — Optimize Imports on the fly، في Xcode — Editor > Remove Unused Imports. أضف فحصاً في CI: يجب أن يمنع المدقق (linter) الالتزامات ذات الاستيرادات غير المستخدمة.

الكود المعلق هو نوع آخر من الكود غير المفيد. يعلق المطورون كتل الكود لـ “عدم فقدان” الوظائف أثناء إعادة الهيكلة. لكن git يحتفظ بالسجل الكامل للتغييرات: أي كود تمت إزالته يمكن استعادته بأمر واحد git revert أو git log -S . الكود المعلق في master هو عدم احترام للفريق: كل مطور يصرف طاقة ذهنية على السؤال “لماذا هذا معلق ومتى يجب إلغاء تعليقه؟”

القاعدة: لا يوجد كود معلق في المستودع. إذا لم يكن الكود مطلوباً، احذفه نهائياً. إذا كان الكود مطلوباً لكنه معطل مؤقتاً، استخدم feature toggle مع تذكرة وتاريخ انتهاء. تعليقات مثل // 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 بالمائة من سعة كل سباق للتنظيف التقني، بما في ذلك تدقيق الكود غير المفيد.

تتكون العملية من أربع خطوات. الأولى — التشخيص: تشغيل الأدوات، الحصول على تقرير، تحديد الأولويات. أولوية عالية: تبعيات ذات CVEs معروفة ومكتبات مكررة. أولوية متوسطة: استيرادات ميتة وكود معلق. أولوية منخفضة: تجريدات زائدة (تتطلب تحليلاً يدوياً).

الثانية — التنظيف: إزالة التبعيات الميتة، استبدال المكتبات المكررة بواحدة، حذف الكود المعلق. كل تغيير يجب أن يكون التزاماً منفصلاً برسالة واضحة: “remove unused dependency: gson (replaced by kotlinx.serialization)”، “delete commented code in LoginViewModel.”

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

الرابعة — الوقاية: تحديث قائمة مراجعة الكود، إضافة قاعدة “لا تبعية جديدة بدون تبرير” إلى تعريف الإنجاز (Definition of Done)، إعداد فحوصات تلقائية في CI. الوقاية هي الطريقة الوحيدة لمنع تراكم الكود غير المفيد مرة أخرى.