اذهب إلى المحتوى

السؤال

نشر

قبل عدة أيام سئلت في ال Technical Interview لوظيفة ال Senior Full-stack Developer عن عملية ال Debugging...

ببساطة سألوني ما هي الخطوات الناجحة أو على الأقل التي أخطوها عندما ألاقي أي bug في ال System... في كل من ال Front-end و ال Server

أعطوني مثال: مثلا ال Request يأخذ وقت طويل من العادة...

السؤال كان: ما هو الخطوات الناجحة أو ال Methodologies التي خطوتها أو على الأقل التي سمعتها في هذه الحالة؟ 

لم أكن جاهزا للجواب... حكيت عن ال Logging... لكن كان واضحا أن الجواب كان ضعيفا...
سألوني بعدها: هل على الأقل سمعت عن ال Indexing في ال Data Base

ما هو الجواب المثالي المفروض كان علي إجابتها برأيكم؟

Recommended Posts

  • 0
نشر

أولاً السبب أنهم ذكروا الـ Indexing مباشرة هو أنها واحدة من أشهر الأسباب لبطء الاستعلامات، لكن الإجابة الشاملة يجب أن تكون أوسع من ذلك.

ولكن أولاً يجب أن نعرف هل المشكلة في الـ Frontend أم الـ Backend أم الـ Network أم قاعدة البيانات؟ هنا تستخدم الـ Browser DevTools لفحص الـ Network Tab ومعرفة هل الـ Request فعلاً يأخذ وقت طويل على السيرفر (انظر لـ Time to First Byte)، أم أن المشكلة في نقل البيانات، أم في معالجة الـ Response على الـ Frontend.

ثانياً إذا كانت المشكلة في الـ Backend نستخدم أدوات الـ Monitoring والـ APM (Application Performance Monitoring) مثل New Relic أو DataDog أو حتى الـ Logging المنظم لتتبع مسار الـ Request داخل السيرفر. فمثلاً تبحث عن الـ Slow Query Log أولاً. هذا يظهر لك الاستعلامات التي تأخذ وقتاً أطول من المتوقع. عندما تجد استعلام بطيء، تستخدم الـ EXPLAIN أو EXPLAIN ANALYZE لفهم خطة التنفيذ. هنا بالضبط يأتي دور الـ Indexing الذي ذكروه. إذا وجدت أن الاستعلام يقوم بـ Full Table Scan على جدول كبير، فهذا مؤشر واضح أنك بحاجة لـ Index على الأعمدة المستخدمة . وهنا أيضاً احتمالات أخرى للمشكلة.

ولكن إذا كانت المشكلة خارج  قاعدة البيانات قد تكون المشكلة في الـ Business Logic نفسها. ربما يوجد حلقة تكرارية معقدة، أو عمليات حسابية ثقيلة، أو استدعاءات لـ APIs خارجية بطيئة. هنا يأتي دور الـ Profiling Tools التي تظهر لك أي جزء من الكود يستهلك معظم الوقت.

وأخيراً  يمكن أن تكون المشكلة في الـ Frontend فقد يكون الـ Request سريع لكن معالجة البيانات في الـ Frontend تأخذ وقتاً. مثلاً، رسم آلاف العناصر في الـ DOM دفعة واحدة، أو عمليات حسابية معقدة في JavaScript. هنا تستخدم الـ Performance Tab في DevTools أو React DevTools Profiler لتحديد المشكلة.

ويمكن أيضاً أن تكون المشكلة في الـ Network

  • 0
نشر

الصحيح هو إجابة مباشرة في خطوات بدون تفصيل وفي حال سألك عن نقطة معينة فصلها له، وهي تحديد مكان المشكلة لمعرفة هل في الـ Network، الـ Client-side، الـ App Server، أو الـ Database.

ثم اذكر له نقاط بسيطة عن كل خطوة، مثلاً في  الـ Network و Client من خلال أدوات DevTools في المتصفح سأتفقد هل الـ TTFB مرتفع، في حال ذلك فالمشكلة في الـ Server، أما لو التحميل بطيئ بعد الاستجابة، فالمشكلة في حجم البيانات أو الـ Rendering.

وفي الـ App Server لو المشكلة كانت في السيرفر، أراقب الـ Logs وأدوات الـ Profiling لمعرفة هل التأخير بسبب عمليات حسابية ثقيلة أم انتظار خارجي.

ولو في الـ Database أراجع الـ Slow Query Logs وهنا أتأكد من أمرين هل الـ Query مكتوب بشكل جيد؟ وهل الجداول تملك الـ Indexing المناسب لمنع المسح الكامل للجدول؟

وفي حال الكود والـ Database بحالة جيدة، أفكر في حلول مثل الـ Caching أو تحويل العملية لـ Background Job.

  • 0
نشر

عندما أواجه Bug مثل “الـ Request يأخذ وقت أطول من المعتاد”، فإن خطواتي المنهجية تكون كالآتي:

1. تحديد نطاق المشكلة (Isolate)

هل المشكلة من Front-end؟

أم في Network layer؟

أم في Back-end؟

أم في Database؟

أول شيء أفعله هو تحديد مكان عنق الزجاجة.

2. استخدام أدوات الـ Front-end

أفتح DevTools → Network وأتحقق من:

حجم الـ Payload

وقت الـ Request/Response

هل هناك إعادة إرسال؟

هل هناك ملفات كبيرة يتم تحميلها؟

هل هناك Blocking / Queueing؟

هذا يحدد إن كانت المشكلة قبل الوصول إلى السيرفر.

3. فحص الـ API من خارج الواجهة

أستخدم:

Postman

cURL

للتأكد أن المشكلة ليست من الواجهة الأمامية.

إذا الـ API بطيئة حتى من Postman → المشكلة Back-end.

4. فحص الـ Server Logs

أتحقق من latency

نقاط التوقف (slow operations)

Exceptions

Memory usage

CPU spikes

أستخدم مثلاً:

ELK / Grafana / Kibana / CloudWatch

Debug Logging بمستويات مثل Info – Warn – Error – Trace

5. Profiling الكود في السيرفر

أتحقق من:

أي function تستغرق أطول وقت

هل هناك عمليات غير ضرورية؟

هل هناك Loop مكثف؟

هل هناك مشاكل في الـ ORM؟

هذه خطوة مهمة لتمييز Senior.

6. المرور للـ Database

أهم خطوة كانوا ينتظروها منك:

هل الاستعلام يحتاج Index؟

أتحقق من:

EXPLAIN / EXPLAIN ANALYZE

هل هناك Full Table Scan؟

هل الاستعلام يستخدم Index فعليًا؟

هل الفلترة تتم على أعمدة غير مفهرسة؟

هل هناك joins غير ضرورية؟

إذا كان الاستعلام بطيئًا → أضيف Index مناسب (BTREE، HASH حسب نوع DB).

7. مراقبة الموارد (Resource Bottlenecks)

CPU

RAM

Disk I/O

Network Latency

عدد الـ Connections

أحيانًا المشكلة ليست كودًا بل موارد.

8. التحقق من الـ Caching Layer

هل هناك Caching مفقود؟

هل يتم عمل Cache invalidation خاطئ؟

هل Redis أو Memory Cache غير مفعّل؟

9. التحقق من الـ Deployment / Environment

هل إصدار الـ Node/PHP/Server مختلف؟

هل هنالك Nginx misconfiguration؟

هل هناك Load Balancer بطيء؟

10. وضع Fix ثم إعادة الاختبار (Regression Testing)

بعد تحديد المشكلة:

أصلح

أختبر

أتأكد أن النظام كله يعمل

أضيف logging + tests preventively

انضم إلى النقاش

يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.

زائر
أجب على هذا السؤال...

×   لقد أضفت محتوى بخط أو تنسيق مختلف.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   جرى استعادة المحتوى السابق..   امسح المحرر

×   You cannot paste images directly. Upload or insert images from URL.

  • إعلانات

  • تابعنا على



×
×
  • أضف...