جمال الدين صمدوف نشر 1 ديسمبر 2025 أرسل تقرير نشر 1 ديسمبر 2025 قبل عدة أيام سئلت في ال Technical Interview لوظيفة ال Senior Full-stack Developer عن عملية ال Debugging... ببساطة سألوني ما هي الخطوات الناجحة أو على الأقل التي أخطوها عندما ألاقي أي bug في ال System... في كل من ال Front-end و ال Server أعطوني مثال: مثلا ال Request يأخذ وقت طويل من العادة... السؤال كان: ما هو الخطوات الناجحة أو ال Methodologies التي خطوتها أو على الأقل التي سمعتها في هذه الحالة؟ لم أكن جاهزا للجواب... حكيت عن ال Logging... لكن كان واضحا أن الجواب كان ضعيفا... سألوني بعدها: هل على الأقل سمعت عن ال Indexing في ال Data Base ما هو الجواب المثالي المفروض كان علي إجابتها برأيكم؟ 1 اقتباس
0 عبدالباسط ابراهيم نشر 1 ديسمبر 2025 أرسل تقرير نشر 1 ديسمبر 2025 أولاً السبب أنهم ذكروا الـ 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 1 اقتباس
0 Mustafa Suleiman نشر 3 ديسمبر 2025 أرسل تقرير نشر 3 ديسمبر 2025 الصحيح هو إجابة مباشرة في خطوات بدون تفصيل وفي حال سألك عن نقطة معينة فصلها له، وهي تحديد مكان المشكلة لمعرفة هل في الـ 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 Sherif Aboghazala نشر 13 ديسمبر 2025 أرسل تقرير نشر 13 ديسمبر 2025 عندما أواجه 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 اقتباس
السؤال
جمال الدين صمدوف
قبل عدة أيام سئلت في ال Technical Interview لوظيفة ال Senior Full-stack Developer عن عملية ال Debugging...
ببساطة سألوني ما هي الخطوات الناجحة أو على الأقل التي أخطوها عندما ألاقي أي bug في ال System... في كل من ال Front-end و ال Server
أعطوني مثال: مثلا ال Request يأخذ وقت طويل من العادة...
السؤال كان: ما هو الخطوات الناجحة أو ال Methodologies التي خطوتها أو على الأقل التي سمعتها في هذه الحالة؟
لم أكن جاهزا للجواب... حكيت عن ال Logging... لكن كان واضحا أن الجواب كان ضعيفا...
سألوني بعدها: هل على الأقل سمعت عن ال Indexing في ال Data Base
ما هو الجواب المثالي المفروض كان علي إجابتها برأيكم؟
3 أجوبة على هذا السؤال
Recommended Posts
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.