الوضع
كانت المنصة تعمل فعليًا ويستخدمها نحو 2,000 طالب يوميًا. نمت بسرعة، وظهر ذلك بوضوح: إحدى أكثر الصفحات استخدامًا كانت تستغرق من 10 إلى 15 ثانية للتحميل، ونتائج البحث لم تكن كما يتوقع المستخدمون، والإشعارات لم تكن تصل دائمًا إلى الأشخاص الصحيحين. وفي الوقت نفسه، استمرت طلبات الخصائص الجديدة بالوصول.
إعادة بناء النظام لم تكن خيارًا، فالطلاب يستخدمونه كل يوم.
ما قمت به
- بدأت بأبطأ صفحة. تتبّعت أين يضيع وقت التحميل وحسّنت تلك الصفحة أولًا، لأنها تؤثر على أكبر عدد من المستخدمين.
- حسّنت سلوك البحث لتطابق النتائج ما يبحث عنه الطلاب فعلًا.
- أصلحت مسار الإشعارات بالكامل، من الخادم حتى ما يراه المستخدم.
- أضفت تحسينات وخصائص جديدة للواجهة بالتوازي مع الإصلاحات، ضمن بنية Flask/FastAPI القائمة.
- شخّصت أخطاء بيئة الإنتاج فور الإبلاغ عنها.
- نسّقت اختبارات القبول (UAT) ليتحقق مستخدمون حقيقيون من كل إصدار قبل إطلاقه.
النتيجة
- انخفض زمن تحميل الصفحة الرئيسية من 10–15 ثانية إلى نحو 5 ثوانٍ.
- استمرت الإصدارات بشكل منتظم، دون إعادة بناء ودون توقف للطلاب.
ماذا يعني هذا لك
إذا كان تطبيقك بطيئًا أو غير مستقر لكن الناس يعتمدون عليه يوميًا، فإعادة البناء نادرًا ما تكون الحل. قياس أين يضيع الوقت وإصلاح المشاكل الأكثر تأثيرًا أولًا يعطي نتائج خلال أسابيع، لا أشهر.