الفصل الثالث عشر: الصيانة والتطوير المستمر Chapter 13: Maintenance & Continuous Improvement

كيف نحافظ على استقرار التطبيق ونضيف مميزات جديدة دون إزعاج المستخدم الحالي.

🚀 مرحلة ما بعد الإطلاق Post-Launch Phase

برمجة التطبيق هي مجرد البداية. الحياة الحقيقية للتطبيق بتبدأ لما ينزل للمستخدمين. في الفصل ده هنتعلم إزاي ندير "حياة التطبيق" (App Lifecycle) باحترافية.

1
Feedback Loop

استلام تقارير الأخطاء من المستخدمين ودمجها في التحديث القادم.

2
Sustainability

تحديث المكتبات (Packages) لمواجهة التغييرات في أنظمة أندرويد و iOS.

3
Evolution

إضافة مميزات جديدة بناءً على طلبات المستخدمين الحقيقية.

🔢 نظام الإصدارات (Semantic Versioning) SemVer Strategy

إحنا بنتبع نظام MAJOR.MINOR.PATCH في MRE CashBook عشان الفريق والمستخدمين يعرفوا حجم التغيير:

PartChange TypeExample
MAJORتغيير جذري أو إعادة تصميم كاملة (Breaking Changes).2.0.0
MINORإضافة مميزات جديدة بدون كسر المميزات القديمة.1.1.0
PATCHتصليح أخطاء (Bugs) أو تحسينات بسيطة.1.0.5
pubspec.yaml
version: 1.2.3+14 // 1.2.3 (Version) + 14 (Build Number)

تنبيه: الـ Build Number لازم يزيد مع كل رفعة على المتجر، حتى لو الـ Version ثابت.

📲 استراتيجية التحديثات (App Updates) Force vs. Optional Updates

مش كل التحديثات زي بعضها. إحنا بنقسمها لنوعين:

!
Force Update (إجباري)

لو في مشكلة أمنية أو تغيير في الداتابيز، بنمنع المستخدم يكمل غير لما يحدث.

!
Optional Update (اختياري)

لو مميزات جديدة، بنظهر له Banner لطيف "توجد نسخة جديدة متاحة".

graph TD Start[App Launch] --> Check[Remote Config/API Check] Check -- No Update --> Open[Open App] Check -- New Version --> Type{Is Force?} Type -- Yes --> Modal[Show Force Update Modal] Type -- No --> Banner[Show Update Banner] Modal --> Store[Go to App-Store]
🐦 شوربيرد: التحديث اللحظي (Code Push) Shorebird Integration

واحدة من أقوى الأدوات في مشروعنا هي Shorebird. بتسمح لنا نصلح الـ Bugs لحظياً بدون ما المستخدم يروح المتجر أو يحمل تحديث كبير.

shorebird patch android --release-version 1.2.3

ليش بنستخدم Shorebird؟ لأن مراجعة أبل وجوجل للتطبيقات ممكن تاخد أيام. مع Shorebird، بنصلح الكراش في 5 دقايق بس.

📜 نظام السجلات (AppLogger) Structured Logging Solution

إحنا مش بنستخدم print العادية. إحنا عندنا AppLogger خاص بينا بيسهل علينا تتبع المشاكل:

AppLogger.info("User opened Settings screen");
AppLogger.warning("Low storage detected");
AppLogger.error("Failed to save transaction", error: e, stack: stack);

الميزة: الـ Logger بيقدر يفرق بين وضع الـ Debug (بيظهر في الـ Console) ووضع الـ Release (بيبعت لـ Crashlytics).

⚡ مراقبة الأداء (Performance Auditing) Flutter DevTools & Performance

عشان نتأكد إن التطبيق سريع وسلس، بنستخدم الـ Flutter DevTools لمراقبة الـ CPU والـ Memory:

1
Frame Rendering

التأكد إن الـ Frames بتترسم في أقل من 16ms لضمان تجربة 60 FPS.

2
Memory Leaks

مراقبة الـ Heap لضمان إن التطبيق مبيستهلكش رام بمرور الوقت بسبب الـ Controllers اللي متقفلتش.

PRO TIP: استخدم debugPrintStack() لو عاوز تعرف مين اللي بينادي على Function معينة وبياخد وقت طويل.

📦 هجرة البيانات (Data Migration) Database Schema Evolution

لما بنحتاج نضيف Column جديد في الداتابيز، لازم نعمل Migration عشان بيانات المستخدمين القديمة ما تتمسحش:

// AppDatabase migration logic
MigrationStrategy get migration => MigrationStrategy(
  onUpgrade: (m, from, to) async {
    if (from < 2) {
      await m.addColumn(transactions, transactions.categoryEmoji);
    }
  },
);
onUpgrade
ليش مهمة؟Why?
بدونها، لو غيرت شكل الجداول، التطبيق هيرفض يفتح أو هيمسح كل بيانات المستخدم عشان يبني الداتابيز من جديد.Without it, schema changes will cause app crashes or data loss during reconstruction.
🗺️ خريطة الطريق (Future Roadmap) The Vision for MRE CashBook

التطوير مش بيوقف. دي خطتنا للمستقبل:

v2.0
Multi-Device Sync

مزامنة البيانات بين الموبايل والتابلت والويب بشكل لحظي.

v2.5
AI Financial Advisor

مساعد ذكي يحلل مصاريفك ويديك نصائح لتقليل الإنفاق.

✅ قائمة صيانة المشروع Maintenance Checklist
TaskFrequencyImportance
تحديث الـ SDK والـ PackagesشهرياًHigh
مراجعة الكراشات في CrashlyticsأسبوعياًCritical
تنظيف الكود (Refactoring)كل 3 شهورMedium
نسخ احتياطي للداتابيز التجريبيةيومياً (تلقائي)High
❓ أسئلة صيانة هندسية Maintenance FAQ
إمتى أحدث النسخة لـ 2.0؟
لما تعمل تغيير كبير في الـ Architecture أو تغير شكل الـ UI بالكامل.
هل الـ Shorebird بيغني عن التحديث في المتجر؟
لا، الـ Shorebird للتغييرات في كود الـ Dart بس. لو أضفت Package جديدة أو عدلت في الـ Native Code لازم تعمل تحديث كامل.
📖 قاموس الفصل Maintenance Glossary
TermMeaning (AR)
Cold Bootتشغيل التطبيق من الصفر (أول مرة بعد ما اتقفل).
UI Jitterتقطيع في الـ UI بسبب سقوط الـ Frames.
Regressionخلل ظهر في ميزة قديمة بسبب تعديل جديد.
📦 تدقيق التبعيات (Dependency Auditing) Keeping Packages Up-to-Date

المكتبات (Packages) بتتحدث بسرعة. عشان نعرف إيه اللي محتاج تحديث، بنستخدم الكوماند ده:

flutter pub outdated
StatusMeaningAction
Currentالنسخة اللي إنت شغال بيها دلوقتي.-
Upgradableأحدث نسخة متوافقة مع الـ pubspec بتاعك.flutter pub upgrade
Resolvableأحدث نسخة موجودة (ممكن تحتاج تعديل كود يدوي).Update manually

تنبيه: بلاش تستخدم any في إصدارات المكتبات. دايماً ثبت النسخة بـ ^ عشان تتجنب الـ Breaking Changes المفاجئة.

📝 أتمتة سجل التغييرات (Changelog) Automated Release Notes

في MRE CashBook، إحنا بنهتم إن المستخدم يعرف إيه الجديد. بدل ما نكتب يدوي، بنستخدم الـ Git Commits:

feat: add backup to Google Drive
fix: resolve crash in reports screen
perf: optimize database queries

باستخدام Conventional Commits، بنقدر نولد ملف CHANGELOG.md تلقائياً بضغطة زرار.

📊 مؤشرات صحة الصيانة (Metrics) Key Maintenance Metrics

إزاي نعرف إن مجهود الصيانة بتاعنا ناجح؟ بنبص على الـ KPIs دي:

graph TD KPI[Maintenance KPIs] --> CR[Crash-Free Users > 99.9%] KPI --> MTTR[Mean Time To Repair < 24h] KPI --> AR[App Rating > 4.5] KPI --> DS[Database Success Rate > 99%]

PRO TIP: لو الـ Crash-Free Users نزل عن 98%، دي حالة طوارئ (Severity 1) ولازم نوقف التطوير ونركز في التصليح.

🔄 تدفق التصحيح (Patch Flow) The Lifecycle of a Hotfix

إزاي بنتعامل مع Bug طارئ في الـ Prod؟

1
Detection

اكتشاف الـ Bug عن طريق Crashlytics Alert.

2
Reproduction

كتابة Test Case بتفشل (Red) عشان نتأكد إننا فهمنا المشكلة.

3
Fix & Deploy

تصليح الكود وعمل shorebird patch للتحديث اللحظي.

📦 توزيع النسخ التجريبية (App Distribution) Beta Testing with Firebase

قبل ما نرفع النسخة لكل الناس على المتجر، لازم نجربها داخلياً. بنستخدم Firebase App Distribution:

1
Build APK/IPA

بنعمل نسخة Release من التطبيق.

2
Upload to Firebase

بنرفع الملف وبنضيف إيميلات المختارين (Testers).

3
Instant Feedback

المختبرين بيقدروا يبعتوا سكرين شوت ووصف للمشكلة لو لقوا Bug.

🧠 تحديث الستيت (State Refresher) State Management during Maintenance

الصيانة غالباً بتضمن تعديل في الـ Cubit أو الـ Bloc. لازم نضمن إن الـ UI بيفضل مستقر:

// AppSettingsCubit example
void toggleDarkMode() {
  final newState = state.copyWith(isDarkMode: !state.isDarkMode);
  emit(newState);
  _saveToPrefs(newState.isDarkMode);
}

PRO TIP: دايماً استخدم copyWith عشان تحافظ على باقي الـ Variables في الـ State وما تضيعش معلومات تانية بالصدفة.

📝 ملخص الفصل Chapter Summary

سنقوم ببناء هذا الفصل لنغطي كل جوانب استدامة المشروع.