قيادة فريق من 5 أشخاص لبناء 53 شاشة في 24 يومًا

بقلم

مقال أصلي

كيف بنى فريقنا في DEPI تطبيق «أُسطى»، سوق خدمات السيارات بين العملاء والمراكز، في 24 يومًا: الأساس أولًا، وقواعد واضحة للفريق، والأخطاء التي مرّت رغم نجاح الاختبارات.

تطبيق أُسطى للعميل: البحث على الخريطة عن مراكز الخدمة القريبة مع فلاتر الزيت والفرامل والتكييف والإطاراتشاشة الحجز في أُسطى: اختيار اليوم والموعد بالساعة، مع الإجمالي وزر الدفع في المركزلوحة مركز الخدمة في أُسطى بالعربية والوضع الداكن: دخل اليوم وأعداد الحجوزات

المشروع

كان «أُسطى» مشروع تخرجنا في DEPI: سوق لخدمات السيارات في مصر. يجد العميل مركز الخدمة على الخريطة، ويحجز موعدًا، ويتابع الإصلاح لحظة بلحظة. وتدير مراكز الخدمة حجوزاتها وخدماتها وعروضها وفريقها من نفس التطبيق. قدت فريقًا من خمسة أشخاص، وبنيت الخادم بـ Laravel وحدي بدءًا من منتصف يونيو، ووضعت أساس تطبيق Flutter الذي بُني عليه الباقي.

الأساس قبل الشاشات

لا يمكن لخمسة أشخاص بناء شاشات بالتوازي بدون أساس. لذلك خُصصت الأيام الأولى للهيكل: مجلدات ميزات للعميل والمركز والكود المشترك، وBLoC لإدارة الحالة، وget_it للاعتماديات، وعميل Dio واحد يفهم شكل استجابات الـ API ورموز تسجيل الدخول.

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

خمسة أشخاص وكود واحد

كانت القواعد بسيطة ومكتوبة. العمل على فروع ميزات باسم الـ issue على GitHub، ثم الدمج في فرع develop، ولا يستقبل main إلا الإصدارات الموسومة. الـ commits تتبع Conventional Commits، ووصف كل pull request بالعربية والإنجليزية، وتحديث التوثيق جزء من إنهاء المهمة.

بين 1 و25 يوليو استقبل مستودع التطبيق 336 commit و79 pull request مدمجًا وثمانية إصدارات، من v0.1.0 إلى v0.8.0.

أخطاء لم تكشفها الاختبارات

في منتصف يوليو كانت مجموعتا الاختبارات ناجحتين، ومع ذلك وصلت خمسة أخطاء، كلها عند الحد بين التطبيق والـ API. كان رمز التجديد يُرسل بصيغة خاطئة، فيخرج المستخدم كلما انتهت جلسته. وتحديث شعار المركز كان يتجاهل باقي بيانات الملف بصمت، لأن الخادم لا يقرأ الملفات المرفوعة إلا في طلبات POST. ورقم لوحة السيارة وعداد الكيلومترات كانا يضيعان في الطريق إلى الخادم.

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

النتيجة

في 24 يومًا سلّم الفريق 53 شاشة عبر تطبيقي العميل والمركز، بالعربية والإنجليزية مع وضعين فاتح وداكن. وتحتها الخادم الذي بنيته: API بـ Laravel 12 فيه 78 مسارًا، وPostGIS للبحث عن الأقرب، وReverb لتحديثات الحجز اللحظية، وإشعارات فورية، ولوحة إدارة Filament، و414 اختبارًا آليًا. وكان الدفع الإلكتروني عبر Paymob المرحلة الوحيدة المفتوحة عند التسليم، لذلك يتم الدفع في المركز.

ما سأحتفظ به في أي مشروع جماعي: ابنِ الأساس قبل الشاشات، واكتب القرارات، واختبر الاتفاق بين التطبيق والخادم، لا كل طرف وحده فقط.

اقرأ دراسة الحالة: أُسطى — سوق خدمات السيارات ←