العكازات في البرمجة — ما هي، أسبابها ومتى تكون مبررة

ما هو «العكاز» في البرمجة

العكاز (crutch) هو حل برمجي يعمل لكنه مصنوع «على عجل»: يعالج مشكلة محددة لكنه لا يزيل سببها، ولا يتبع معمارية المشروع، ويمكن أن ينكسر مع أدنى تغييرات في البيئة. التشبيه دقيق — مثل العكاز الحقيقي، هذا الكود يساعد على «المشي» لكنه لا يعالج «الرجل».

المطورون «يدعمون بالعكازات» الأخطاء، عدم توافق الإصدارات، خصائص المنصة، والمتطلبات العاجلة للعميل. العكاز النموذجي هو عكاز شرطي: إذا كان iOS 15 أضف هامشاً، إذا كان Huawei أخفِ الزر. هذه الفحوصات تتكاثر وتحوّل الكود إلى «طبقات كعكة» من فروع المنصة والإصدار.

العكازات تأتي بمقاييس مختلفة: من سطر واحد بشرط عكازي إلى وحدة غلاف كاملة «تُصلح» سلوك مكتبة. من المهم أن نفهم أن العكاز ليس شراً دائماً: في الأيدي الصحيحة، هو أداة تتيح إطلاق المنتج في الوقت المحدد. المشكلة تبدأ عندما يبقى العكاز في الكود إلى الأبد.

لماذا تظهر العكازات: الأسباب والسياق

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

دعنا نلقي نظرة على أربعة أسباب رئيسية تجعل المطورين يلجأون بوعي إلى العكازات. فهم هذه الأسباب يساعد في التعامل مع العكازات ليس كخطأ بل كأداة عملية تحتاج إلى إدارة.

المواعيد النهائية

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

عدم توافق الإصدارات

المكتبة (أ) تتطلب Android 12، لكن تطبيقك يدعم Android 10. الحل هو كتابة غلاف يتحقق من إصدار نظام التشغيل ويختار مسار التنفيذ. هذا عكاز لأنه عند تحديث المكتبة، يجب إعادة كتابة الغلاف. لكن البديل — التخلي عن المكتبة أو دعم الأجهزة القديمة — قد يكون أسوأ.

// عكاز لتوافق API 29
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

التبعيات الخارجية ذات الأخطاء

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

الفهم غير الكامل للنظام

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

متى يكون العكاز مبرراً: نهج عملي

ليس كل عكاز شراً. في التطوير الواقعي، النقاء المطلق للكود غير قابل للتحقيق وغالباً غير عملي. النهج العملي يقر بأن الحلول المؤقتة جزء من العملية، لكنه يتطلب الوعي والتوثيق وخطة الإزالة. العكاز مبرر عندما يحل مشكلة تجارية أسرع من حل معماري نظيف.

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

مثال على عكاز مبرر

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

// TODO: IT-1234 — إزالة هذا العكاز بعد إعادة هيكلة AuthService
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

كيف تميّز بين العكاز المؤقت والمشكلة المعمارية

الحدود بين العكاز الواعي والمشكلة المعمارية (الديون التقنية) تمر عبر معلمتين: الوعي بالقرار ووجود خطة لإزالته. العكاز هو دائماً حل مؤقت بعمر معروف. الديون التقنية هي نتيجة العديد من العكازات المتروكة دون اهتمام.

متى يصبح العكاز مشكلة

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

علامات أزمة العكازات

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

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

إعادة هيكلة العكازات: استراتيجية وممارسة

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

استراتيجية الأولويات

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

عملية الإزالة خطوة بخطوة

الخطوة 1: الجرد — ابحث عن كل TODO و FIXME المتعلقة بالعكازات. الخطوة 2: التقييم — حدد أيها لا يزال ذا صلة. الخطوة 3: التخطيط — جدول إعادة هيكلة العكازات في سبيرنت، بدءاً من ذات الأولوية العالية. الخطوة 4: الاستبدال — نفذ الحل النظيف، أزل العكاز وتعليق TODO الخاص به. الخطوة 5: التحقق — تأكد من اجتياز الاختبارات وعدم وجود انتكاسات.

# العثور على جميع عكازات TODO في المشروع
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

منع العكازات الجديدة

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