كيف تفكّر في الـ Backend كنظام وليس مجرد كود
كثير من المطورين يكتبون Backend نظيف ومنظم ويعمل بدون مشاكل ظاهرة.
لكن مع الوقت، ومع توسّع المشروع، تبدأ المشاكل بالظهور رغم أن الكود لم يتغير كثيرًا.
السبب في الغالب ليس خطأ برمجي مباشر،
بل طريقة التفكير في الـ Backend على أنه كود فقط، وليس نظامًا متكاملًا.
هذا المقال لا يشرح Backend من الصفر،
بل يركّز على طريقة التفكير التي تفرّق بين تطبيق يعمل،
وتطبيق يمكن الاعتماد عليه.
1) التفكير في الطلب بدل التفكير في التدفق
كثير من المطورين يفكّر هكذا:
- وصل الطلب
- نكتب الكود
- نرجع الاستجابة
لكن في الواقع الطلب يمر عبر:
- Middleware
- Validation
- Authorization
- Business Logic
- Database
- Cache
أي قرار صغير في مرحلة واحدة قد يسبب:
- بطء عام في النظام
- استهلاك موارد غير متوقع
- سلوك يصعب تتبعه لاحقًا
التفكير كنظام يبدأ من رؤية الرحلة كاملة، لا من نقطة التنفيذ فقط.
2) افتراض أن كل شيء سيعمل دائمًا
في مشاريع كثيرة يتم كتابة الكود وكأن:
- قاعدة البيانات دائمًا سريعة
- الكاش دائمًا متاح
- الطلبات دائمًا صحيحة
لكن الواقع مختلف:
- قاعدة البيانات قد تتأخر
- الكاش قد يتعطل
- المستخدم قد يرسل بيانات غير متوقعة
النظام الجيد يفترض الفشل،
ويتعامل معه بوضوح بدل تجاهله.
3) التركيز على صحة الكود وتجاهل سلوك النظام
كثير من الكود يكون:
- صحيح نحويًا
- يمر جميع الاختبارات
لكن عند التشغيل الحقيقي:
- الأداء غير ثابت
- الذاكرة ترتفع مع الوقت
- الاستجابة تتدهور تحت الضغط
السبب أن الكود كُتب ليعمل،
لا ليعيش داخل نظام حقيقي لفترة طويلة.
4) قاعدة البيانات تُعامل كمخزن فقط
في التفكير السطحي:
- نخزّن البيانات
- نسترجعها
في التفكير كنظام:
- ما أكثر استعلام يتكرر؟
- ما البيانات التي تتغير كثيرًا؟
- ما الذي يجب فهرسته؟
- ما الذي يجب كاشه؟
هذه القرارات إن لم تُؤخذ مبكرًا،
تتحول لاحقًا إلى مشاكل أداء حقيقية.
5) الاعتماد على الواجهة لضبط المنطق
من الأخطاء الشائعة:
- الواجهة تتحكم بتسلسل الطلبات
- الواجهة تمنع الأخطاء
- الواجهة تفرض القواعد
لكن النظام الجيد:
- لا يثق بالواجهة
- لا يفترض استخدامًا صحيحًا
- يتحقق من كل شيء
الـ Backend يجب أن يكون قادرًا على العمل
حتى لو تغيّرت الواجهة بالكامل.
6) تجاهل الـ Logs حتى تقع المشكلة
في كثير من المشاريع:
- لا يوجد logging واضح
- أو logs عامة بلا سياق
وعند حدوث مشكلة:
- لا يُعرف متى بدأت
- ولا ما الذي تسبب بها
الـ Logs ليست إضافة،
بل جزء أساسي من تصميم النظام.
7) ربط كل شيء مباشرة بدون عزل
في أنظمة كثيرة:
- الطلب يعتمد على أكثر من خدمة
- أي فشل بسيط يوقف العملية بالكامل
عدم وجود:
- Timeouts
- Retries
- Fallbacks
يجعل النظام هشًا،
حتى لو كان الكود ممتازًا.
8) عدم التفكير في المستقبل
كثير من القرارات تُتخذ بناءً على:
- حجم المشروع الحالي
- عدد المستخدمين الحالي
لكن النظام الحقيقي يجب أن يفترض:
- زيادة البيانات
- زيادة الضغط
- تغيّر طريقة الاستخدام
التفكير كنظام لا يعني التعقيد،
بل الاستعداد.
