مشروعك البرمجي متعثر؟ متى تصلحه ومتى تعيد بناءه من الصفر؟
إنقاذ مشروع قائم عندما يصبح كل تعديل مخاطرة، وتتراكم الأخطاء، ويغادر الفريق السابق أو تتوقف الإصدارات، يكون أسوأ قرار هو القفز مباشرة إلى «نرمي الكود ونبدأ من جديد». القرار الصحيح يبدأ بتشخيص ما الذي تعطّل فعلًا: المنتج، الكود، البنية، البيانات،…
إنقاذ مشروع قائم
عندما يصبح كل تعديل مخاطرة، وتتراكم الأخطاء، ويغادر الفريق السابق أو تتوقف الإصدارات، يكون أسوأ قرار هو القفز مباشرة إلى «نرمي الكود ونبدأ من جديد». القرار الصحيح يبدأ بتشخيص ما الذي تعطّل فعلًا: المنتج، الكود، البنية، البيانات، عملية النشر، أم طريقة إدارة المشروع.
ماذا ستخرج به
- كيف تفرّق بين خمسة أنواع من التعثر قبل أن تدفع مقابل أي إصلاح.
- تسعة محاور يفحصها الـTechnical Audit، وما الذي يجب أن يخرج به فعلًا.
- ثمانية مسارات بين الإصلاح وإعادة البناء، ومصفوفة لمقارنتها.
- متى يكون Full Rewrite مبررًا، ومتى يكون قرارًا خطيرًا.
الإجابة المختصرة · الـTechnical Audit · خيارات الإنقاذ · مصفوفة القرار · متى يُبرَّر Full Rewrite · نقل البيانات · إطار القرار · الأسئلة الشائعة
الإجابة المختصرة: هل أصلح المشروع أم أعيد بناءه؟
لا يمكن تحديد ذلك من عمر الكود، ولا من عدد الأخطاء، ولا من انطباع فريق جديد وحده. أطر التحديث الرسمية لدى Microsoft تبدأ بتقييم التطبيق ومشكلاته واعتماداته قبل اختيار استراتيجية التحديث، وتعرض عدة خيارات تشمل Refactor وRearchitect وRebuild وReplace بدل اعتبار إعادة البناء الحل الافتراضي.[1][2]
قد ينتهي التشخيص إلى إصلاح محدد، أو Refactoring تدريجي، أو إعادة بناء جزء واحد، أو استبدال مكوّن خارجي، أو Full Rebuild. النتيجة تُستخرج من حالة المشروع؛ لا تُفترض قبل فحصه.
متى نقول إن المشروع «متعثر»؟
التعثر هنا ليس حكمًا بأن المشروع فاشل. هو وصف لحالة أصبح فيها التسليم أو التشغيل أو التطوير غير قادر على الاستمرار بالمستوى المطلوب دون معالجة جذر المشكلة.
مشاكل تشغيلية متكررة
أعطال Production أو أخطاء حرجة تتكرر ولا توجد طريقة مستقرة لمنع عودتها أو اكتشافها مبكرًا.
التغيير أصبح خطرًا
Feature صغيرة تحتاج تعديلات واسعة أو تُنتج Regression في أجزاء غير متوقعة.
النشر غير موثوق
لا توجد Pipeline أو خطوات نشر قابلة للتكرار، أو أصبح إصدار نسخة جديدة يعتمد على معرفة شخص واحد.
الاستلام ناقص
Repository أو Cloud أو حسابات أو Documentation أو مفاتيح تشغيل أساسية غير متاحة للفريق الحالي.
النطاق غير محسوم
الفريق يبني Features لكن لا توجد صورة واضحة لما يجب إطلاقه أو ما الذي يُعتبر Done.
قيود تقنية تمنع التقدم
Dependencies أو Architecture أو منصة تشغيل أصبحت عائقًا حقيقيًا أمام المتطلبات الحالية.
هذه إشارات تستحق الفحص، وليست قواعد تشخيص منفردة. وجود واحدة منها لا يعني تلقائيًا أن النظام يحتاج Rewrite.
قبل تعديل Architecture: تأكد أن المشكلة تقنية أصلًا
بعض المشاريع تبدو «مشكلة كود» بينما المشكلة الرئيسية في مكان آخر. قبل أن تدفع مقابل إعادة كتابة كبيرة، افصل بين خمسة أنواع من التعثر:
| نوع المشكلة | مثال | لماذا قد يخدعك؟ | السؤال الأول |
|---|---|---|---|
| Product / Scope | متطلبات تتغير باستمرار | الفريق يبدو بطيئًا بينما الهدف نفسه يتحرك | ما النسخة التي نحاول إطلاقها فعلًا؟ |
| Delivery / Process | غياب Definition of Done أو QA واضح | الأخطاء تُنسب للكود بينما عملية التسليم نفسها ضعيفة | كيف تنتقل المهمة من Requirement إلى Production؟ |
| Technical | Coupling شديد أو Dependencies غير مدعومة | كل تغيير يجر تغييرات واسعة | ما المكوّن الذي يسبب القيود؟ |
| Operational | Logs ومراقبة ونشر غير منظم | الفريق لا يستطيع تشخيص الحوادث بسرعة | هل نرى حالة النظام ونعرف ماذا تغيّر؟ |
| Handover | حسابات أو Secrets أو Repo ناقصة | يبدو النظام معقدًا بينما جزء من المعرفة لم يُسلَّم | هل نملك الوصول والمعلومات اللازمة؟ |
لا تسمح بأن يتحول الخلاف مع Vendor سابق إلى مبرر هندسي تلقائي لإعادة البناء. جودة العلاقة السابقة وجودة Architecture سؤالان مختلفان.
Technical Audit: ما الذي يجب فحصه قبل القرار؟
إرشادات Microsoft لتقييم Workloads توصي بفحص الكود والتوافق وفرص التحديث، بينما AWS تضع ضمن تقييم التحديث الحالة الحالية للتطبيق والـTechnical Debt وCI/CD وMonitoring والمهارات وطريقة التشغيل.[1][3]
في مشروع تطبيق أو منصة رقمية، يتحول ذلك إلى تسعة محاور عملية:
Product & Scope
الرحلات الحرجة، الأدوار، المتطلبات غير المكتملة، وما يجب الحفاظ عليه.
Repository & Build
الفروع، Dependencies، Runtime versions، وقدرة فريق جديد على بناء نسخة من الصفر.
Architecture
حدود المكونات، Coupling، Integrations، نقاط الاختناق والاعتماد على خدمات أخرى.
Data
Schema، Migrations، Backups، جودة البيانات، وخطة النقل عند تغيير البنية.
Quality & Tests
الاختبارات الموجودة، المناطق غير المغطاة، Bugs المعروفة، وسيناريوهات القبول.
Security
Dependencies المعرضة للمشكلات، Secrets، الصلاحيات، ومسارات البيانات الحساسة.
Delivery & Operations
CI/CD، Environments، Monitoring، Alerts، Rollback، ومسار إصدار النسخ.
Ownership & Handover
Repo، Cloud، Stores، DNS، Documentation، والخدمات الخارجية.
Business Constraints
أهمية النظام للعمل، مواعيد حرجة، قدرة الشركة على التوقف، الميزانية، مهارات الفريق، وما الذي لا يمكن المخاطرة به أثناء الانتقال.
إذا كان Production غير مستقر: ثبّت أولًا
عندما يكون المنتج المستخدم حاليًا معرضًا لأعطال متكررة، يكون الهدف الأول استعادة القدرة على تشغيله وتغييره بأمان نسبي، لا البدء مباشرة في إعادة تصميم Architecture كاملة.
- حصر الأعطال الحرجة الحالية.
- تأكيد وجود Backup وآلية استعادة مناسبة للحالة.
- تفعيل Logging وMonitoring الضروريين للتشخيص.
- معرفة آخر Release مستقرة.
- توثيق خطوات النشر الحالية.
- تحديد مسار Rollback أو Recovery المناسب.
- إيقاف التغييرات غير الضرورية التي تزيد عدم الاستقرار أثناء التشخيص.
- إضافة اختبارات أو Checks حول الرحلات الأكثر حساسية قبل التغييرات الكبيرة.
توصي Azure Well-Architected في ممارسات النشر الآمن بإصدارات صغيرة تدريجية، وHealth Checks، وإيقاف النشر وبدء التعافي عند اكتشاف مشكلة.[4] الفكرة ليست فرض أداة بعينها، بل إعادة بناء قدرة الفريق على تغيير Production مع إدارة المخاطر.
الخيارات ليست Fix أو Rewrite فقط
بين أقل تدخل وأكبره ثمانية مسارات، وأغلب المشاريع تقع في المنتصف:
Fix
أقل تدخل. إصلاح Bugs أو مشكلات محددة عندما تكون المشكلة محصورة وباقي النظام مقبولًا.
Refactor
تحسين تدريجي. إعادة تنظيم الكود أو بعض حدوده لتحسين قابليته للصيانة مع الحفاظ على السلوك المطلوب.
Replatform
تغيير المنصة. تغيير جزء من Platform أو Infrastructure عندما تكون المشكلة في بيئة التشغيل أكثر من منطق المنتج.
Partial Rewrite
استبدال مستهدف. إعادة بناء مكوّن أو Capability محددة مع إبقاء بقية النظام قيد التشغيل.
Rearchitect
تغيير معماري كبير. إعادة تصميم أجزاء جوهرية عندما تكون القيود بنيوية لا مجرد جودة كود محلية.
Full Rebuild
بناء جديد. إعادة تنفيذ النظام عندما يكون الاحتفاظ بالبنية الحالية غير مبرر بعد مقارنة الخيارات.
Replace
حل جاهز. استبدال النظام بمنتج آخر عندما تكون قيمة بناء Custom جديد أقل من استخدام بديل مناسب.
Retain / Retire
الخيار المنسي. الاحتفاظ بالنظام مؤقتًا أو إيقافه عندما لا تبرر قيمة العمل تكلفة التحديث.
تصف Microsoft استراتيجيات التحديث كسلسلة خيارات لا قرارًا ثنائيًا، وتذكر أن Rebuild يصبح منطقيًا عندما تتجاوز تكلفة أو قيود Replatform/Refactor الفوائد المتوقعة.[2]
مصفوفة القرار: كيف تقارن الخيارات دون قواعد زائفة؟
الجدول التالي إطار تقييم مقترح، وليس آلة تصدر القرار تلقائيًا. استخدمه لتوضيح النقاش بين Business وEngineering، ثم اربطه بنتائج الـAudit.
| الحالة | Fix | Refactor | Partial Rewrite | Full Rebuild |
|---|---|---|---|---|
| Bugs محدودة ومكونات مستقرة | مرشح قوي | عند وجود Debt محلية | غالبًا مبالغ فيه | غالبًا مبالغ فيه |
| Coupling يمنع تعديل Module بعينه | حل مؤقت | يُفحص | مرشح | يعتمد على بقية النظام |
| Platform قديمة لكن Business Logic مستقرة | يعالج أعراضًا فقط | محتمل | محتمل | لا يُحسم بالعمر وحده |
| لا توجد Tests كافية | أضف حواجز حول التغيير | بحذر | بحاجة لاختبار التكافؤ | ليست مبررًا منفردًا |
| النظام عليه مستخدمون وعمليات يومية | ممكن تدريجيًا | ممكن تدريجيًا | مع خطة انتقال | مخاطر Cutover أعلى |
| المنطق تغيّر جذريًا والنظام لم يعد يعكس المنتج | قد لا يكفي | قد لا يكفي | حسب حدود التغيير | مرشح يستحق الدراسة |
Partial Rewrite: استبدال جزء دون Big-Bang
عندما تكون المشكلة مركزة في Capability أو Module محددة، يمكن بناء البديل تدريجيًا وتحويل أجزاء من الاستخدام إليه، بدل انتظار نظام جديد كامل ثم إجراء Cutover واحد.
هذا قريب من نمط Strangler Fig الذي وصفه Martin Fowler كطريقة لاستبدال نظام قديم تدريجيًا بدل Cutover شامل، بهدف تقليل مخاطر الانتقال وإتاحة التعلم أثناء الاستبدال.[5]
لو كانت الحدود بين الأجزاء غير قابلة للفصل، أو كان النظام القديم لا يسمح بالتشغيل المتوازي بشكل معقول، فقد تكون تكلفة إنشاء طبقات الانتقال نفسها مرتفعة. لذلك يُقرَّر النمط بعد فهم Dependencies الفعلية.
متى يصبح Full Rewrite قرارًا يمكن الدفاع عنه؟
«Framework قديم» أو «الكود شكله سيئ» ليسا سببًا كافيًا. Full Rebuild يحتاج Business Case وهندسة انتقال، لا تفضيلًا تقنيًا. يستحق الدراسة عندما تتجمع أسباب مثل:
- النظام الحالي لا يستطيع تلبية المتطلبات الجوهرية دون تغييرات واسعة جدًا.
- القيود المعمارية موزعة على Core المنتج وليست Module واحدة.
- Platform أو Components المطلوبة لا يمكن الاستمرار عليها وفق احتياجات المشروع.
- تكلفة ومخاطر Refactor أصبحت أعلى من قيمة الاحتفاظ بالبنية الحالية وفق التقييم.
- المنتج المطلوب اليوم يختلف جذريًا عن افتراضات النظام القديم.
- توجد خطة واضحة لنقل البيانات والمستخدمين والتكاملات.
- الفريق يستطيع تعريف السلوك الذي يجب الحفاظ عليه واختباره.
- توجد خطة Cutover أو تشغيل متوازٍ وRollback مناسبة لحساسية المنتج.
تضع Microsoft الـRebuild ضمن خيارات التحديث عندما لا تعود الاستراتيجيات الأقل تغييرًا تحقق الهدف، لكنها كذلك تطلب موازنة Business Value مع Technical Risk بدل تحديث كل Workload تلقائيًا.[2][6]
ومتى يكون قرارًا خطيرًا؟
توقف قبل البدء من الصفر إذا كانت الصورة التالية موجودة:
- لا أحد يعرف كل Business Rules الموجودة في النظام الحالي.
- لا توجد Acceptance Criteria للرحلات الحرجة.
- لا توجد خطة Data Migration أو Reconciliation.
- المشروع الجديد سيُبنى بينما يتوقف كل التطوير على القديم لفترة طويلة.
- لا توجد خطة واضحة للمستخدمين أثناء الانتقال.
- قرار الـRewrite مبني على تفضيل Framework جديد فقط.
- المشروع لم يحسم Scope لكنه يريد إعادة البناء فورًا.
- لا توجد آلية تقارن سلوك الجديد بالقديم قبل Cutover.
إذا حذفت النظام القديم اليوم، ما المعرفة والسلوكيات والاستثناءات التي ستحتاج إلى إعادة اكتشافها أثناء بناء الجديد؟
الاختبارات: كيف تعرف أن التحديث لم يغيّر سلوكًا مهمًا؟
في Refactor أو Rewrite، لا يكفي أن تعمل الشاشات الجديدة بصريًا. يجب تعريف الرحلات والقواعد التي يجب أن تبقى صحيحة، ثم بناء اختبارات تناسب مستوى المخاطر.
Characterization tests
حول السلوك الموجود الذي يجب الحفاظ عليه كما هو.
Unit Tests
للأجزاء التي يمكن عزلها عن بقية النظام.
Integration Tests
للتكاملات وقواعد البيانات والخدمات الخارجية.
End-to-End
للرحلات الحرجة عندما تكون مناسبة ومبررة التكلفة.
Data reconciliation
عند نقل البيانات أو تحويلها بين نموذجين.
Performance
عندما تكون السعة أو زمن الاستجابة جزءًا من المشكلة أصلًا.
Security validation
وفق طبيعة التغيير وحساسية البيانات.
User Acceptance
للوظائف التي يعتمد عليها العمل يوميًا.
في مسارات تحديث الأنظمة القائمة، توثّق Google Cloud مرحلة Validation باستخدام Functional Equivalence Testing عندما يكون المطلوب التأكد أن البيئة المحدثة تحافظ على Business Logic المتوقعة.[7] المبدأ الأوسع: حدد ما يجب أن يبقى متكافئًا واختبره، بدل الاعتماد على الانطباع.
Data Migration: الجزء الذي يجعل Rewrite ناجحًا تقنيًا وفاشلًا تشغيليًا
النظام الجديد لا يبدأ دائمًا بقاعدة بيانات فارغة. لذلك يجب التعامل مع البيانات كمشروع داخل مشروع التحديث.
Mapping
كيف تتحول Entities والحقول والقيم من النموذج القديم إلى الجديد؟
Validation
كيف تتأكد أن السجلات لم تُفقد أو تتغير بطريقة غير مقصودة؟
Cutover
هل ستوقف الكتابة مؤقتًا، أم تعمل Sync، أم تشغّل النظامين بالتوازي؟
- حدد Source of Truth خلال فترة الانتقال.
- اختبر Migration على نسخة غير Production قبل التنفيذ النهائي.
- حدد ما يحدث للبيانات التي تتغير أثناء عملية الانتقال.
- عرّف Reconciliation checks بعد النقل.
- اعرف شروط Rollback قبل بدء Cutover.
المستخدمون وProduction: كيف تقلل مخاطرة الانتقال؟
عندما يكون النظام مستخدمًا بالفعل، القرار لا يتعلق بالكود فقط. يجب تصميم الانتقال بحيث يراعي الخدمة الحالية والبيانات والدعم وتوقيت التغيير.
تصف Azure Well-Architected الـProgressive Exposure وHealth Checks وإيقاف النشر عند اكتشاف مشكلة كعناصر من Safe Deployment Practices.[4] ليس مطلوبًا استخدام الأدوات نفسها؛ المطلوب أن تكون لديك طريقة معلومة لزيادة التعرض ومراقبة الأثر والتعافي.
Technical Debt: لا تحوّلها إلى رقم وهمي
بدل اختزال الدين التقني في Score واحد غير موثوق، استخدم سجلًا يربط كل بند بأثر فعلي.
| المشكلة | الدليل | الأثر | خيار المعالجة |
|---|---|---|---|
| Module شديد الترابط | تغييرات متكررة تمس عدة أجزاء | بطء وتكرار Regression | Refactor / isolate |
| Dependency غير مدعومة | توثيق المزوّد ونتائج الـBuild | مخاطر أمنية أو توافق | Upgrade / replace |
| Deployment يدوي | لا توجد Pipeline قابلة للتكرار | أخطاء إصدار واعتماد على أفراد | Automate / document |
بهذا يصبح الـTechnical Debt Backlog قابلًا للنقاش التجاري: ما الذي يمنع Feature مهمة؟ ما الذي يرفع خطر الحوادث؟ وما الذي يمكن تأجيله دون ضرر جوهري؟
لا تفترض أن Rewrite سيجعل النظام آمنًا
إعادة كتابة الكود لا تلغي تلقائيًا أخطاء الصلاحيات أو إدارة Secrets أو مخاطر Dependencies أو تصميم تدفق البيانات. التحديث فرصة لإعادة تقييم هذه العناصر، لكنه يحتاج Security Review فعليًا.
- Authentication وAuthorization.
- الأدوار والصلاحيات الحساسة.
- Secrets وCredentials.
- Dependency vulnerabilities.
- Input validation ومسارات البيانات.
- Logging دون كشف بيانات حساسة.
- Third-party integrations.
- Backup وRecovery access.
يوفّر GitHub مثلًا Code Scanning كوسيلة لاكتشاف ثغرات في المصدر قبل وصولها إلى Production،[8] لكنه أداة ضمن برنامج مراجعة أوسع، لا بديل عن فهم Threat Model وسياق التطبيق.
لا تجعل Microservices مرادفًا للإنقاذ
التحول من Monolith إلى Microservices قد يكون مناسبًا لبعض الأنظمة، لكنه يضيف حدود خدمات وNetwork calls وObservability وDeployment وData ownership أكثر تعقيدًا.
لذلك «سنحوّل النظام إلى Microservices» ليست خطة إنقاذ بحد ذاتها. توصي Microsoft بتقييم جاهزية التطبيق والبنية وDevOps ونموذج التطوير قبل الانتقال، وتذكر أن التحول يستغرق وقتًا وأن الفصل التدريجي قد يكون مناسبًا في بعض الحالات.[9]
ما المشكلة التي سيحلها هذا التعقيد الإضافي، وكيف سنعرف بعد التنفيذ أنه حلّها فعلًا؟
ما الذي يجب أن تستلمه من Technical Audit؟
لو دفعت مقابل مراجعة مشروع متعثر، لا ينبغي أن يكون الناتج اجتماعًا يقول فيه الفريق «الأفضل نعيد البناء». اطلب Deliverables قابلة للمراجعة.
- Current-state architecture map.
- Inventory للـRepositories والخدمات والتكاملات.
- قائمة Blockers ومخاطر مصنفة بالدليل.
- Known Issues وTechnical Debt register.
- تقييم Build وDeploy وTest وMonitoring.
- تقييم Handover والأصول الناقصة.
- خيارات Fix / Refactor / Partial Rewrite / Rebuild مع Trade-offs لكل خيار.
- Target architecture عند الحاجة، وMigration strategy.
- Acceptance criteria وPhased roadmap مرتبة حسب الخطر والقيمة.
إطار القرار النهائي: ستة أسئلة قبل الموافقة
هل عرفنا Root Cause؟
أم أن قرار إعادة البناء مجرد رد فعل على Bugs أو تجربة سيئة مع الفريق السابق؟
هل نعرف ما يجب الحفاظ عليه؟
Business Rules، والبيانات، والتكاملات، ورحلات المستخدم، والقيود التشغيلية.
هل قارنّا البدائل؟
Fix وRefactor وReplatform وPartial Rewrite وRearchitect وReplace، لا Rewrite وحده.
هل نملك خطة انتقال؟
Data migration، وCutover، والمستخدمون، والدعم، وRollback.
هل يمكن اختبار النتيجة؟
Acceptance Criteria واختبارات سلوك وتكامل ومقاييس تشغيل مناسبة.
هل Business Case واضح؟
ما القيمة أو الخطر الذي يبرر حجم الاستثمار والتغيير؟
عرّف النجاح قبل أن تبدأ
لا تستخدم كلمة «تحسين» وحدها. اختر Baseline وAcceptance Criteria مرتبطة بالمشكلة الفعلية. قد تشمل بحسب المشروع: انخفاض أخطاء رحلة حرجة، أو نجاح Build وDeployment بصورة قابلة للتكرار، أو زمن استجابة مستهدف، أو إزالة Dependency محددة، أو قدرة الفريق على إصدار Feature دون تعديل مناطق غير مرتبطة.
احسب تكلفة الانتقال، لا تكلفة الكود الجديد فقط
عند مقارنة Refactor وRewrite، أدخل في القرار الأعمال التي غالبًا تُنسى:
- استمرار صيانة النظام القديم أثناء التحديث.
- Data migration وReconciliation.
- تشغيل قديم وجديد بالتوازي عند الحاجة.
- إعادة بناء Integrations.
- QA وRegression testing.
- Monitoring وOperational readiness.
- تدريب الفريق أو سد فجوات المهارات.
- دعم المستخدمين أثناء Cutover.
هل الفريق قادر على تشغيل Architecture الجديدة؟
Architecture أحدث ليست مكسبًا إذا احتاجت مهارات أو عمليات تشغيل لا يملكها الفريق ولا توجد خطة لبنائها. تضع AWS المهارات وOperating Model وCI/CD وMonitoring ضمن أسئلة تقييم التحديث،[3] بينما توصي Microsoft بموازنة Business Value مع Technical Risk واستعداد الفريق قبل تحديد ما يجب تحديثه أولًا.[10]
قائمة تحقق قبل نقل المشروع إلى شركة جديدة
- Repositories كاملة وصلاحيات الوصول.
- آخر Production release معروفة.
- Cloud وHosting access.
- Database وBackups.
- App Store وGoogle Play access عند وجود تطبيقات.
- Domain وDNS.
- Third-party services وتكاملات الدفع والرسائل والخرائط.
- Secrets inventory دون مشاركة غير آمنة.
- CI/CD وEnvironments.
- Documentation المتاحة وDesign files حسب Scope.
- Known Bugs وOpen Issues وقائمة Features غير المكتملة.
- العقد والـScope وAcceptance records.
- أي قيود ترخيص أو ملكية يجب على الفريق الجديد معرفتها.
أسئلة اسألها قبل أن يقول لك أحد «نعيد البناء»
- ما المشكلة المحددة التي لا يمكن إصلاحها داخل النظام الحالي؟
- ما الأدلة التي بنيتم عليها هذا الاستنتاج؟
- ما البدائل الأقل تدخلًا التي قارنتم بها الـRewrite؟
- ما الذي سنعيد استخدامه من النظام الحالي؟
- كيف سنحافظ على Business Rules غير الموثقة؟
- كيف ستنتقل البيانات، وكيف سيتم التحقق منها؟
- هل سيعمل النظام القديم والجديد بالتوازي، وما حدود ذلك؟
- ما خطة Rollback إذا فشل Cutover؟
- كيف ستُختبر الوظائف الحرجة قبل النقل؟
- ما الذي سيظل يعمل ويتطور في النظام الحالي أثناء بناء البديل؟
- ما Acceptance Criteria التي تحدد أن المشروع أصبح قابلًا للتسليم؟
علامات تحذير في عرض إنقاذ المشروع
- القرار بـFull Rewrite قبل الوصول إلى Repository أو فهم النظام.
- استخدام عدد أسطر الكود أو عمر المشروع وحدهما كدليل على ضرورة إعادة البناء.
- وعد بتخفيض التكلفة أو الزمن بنسب محددة بلا Baseline أو تحليل.
- اقتراح Microservices أو Framework جديد دون ربطه بمشكلة واضحة.
- تجاهل Data Migration وCutover أثناء تقدير المشروع الجديد.
- عدم وجود خطة للحفاظ على Production أثناء فترة الإنقاذ.
- عدم تحديد ما الذي سيُعتبر نجاحًا في نهاية المرحلة.
- عدم سؤال الفريق عن الحسابات والـRepositories والتكاملات والتوثيق.
أسئلة متكررة
هل الكود القديم يعني أن إعادة البناء أفضل؟
لا. العمر عامل واحد فقط. القرار يعتمد على قدرة النظام على تلبية المتطلبات، وحالة Dependencies، وArchitecture، والاختبارات، ومخاطر التغيير، وتكلفة البدائل، وخطة المنتج.
ما الفرق بين Refactor وRewrite؟
Refactoring يغيّر بنية الكود أو تصميمه الداخلي مع محاولة الحفاظ على السلوك المطلوب، بينما Rewrite يعيد تنفيذ جزء أو نظام من جديد. وبينهما درجات كثيرة، منها Partial Rewrite وRearchitect.
هل يمكن إنقاذ مشروع بدون توثيق جيد؟
ممكن في بعض الحالات، لكن تكلفة الاكتشاف وعدم اليقين ترتفع. يحتاج الفريق إلى إعادة بناء المعرفة من الكود والبنية والبيانات والـLogs والمنتج الحالي وأصحاب المصلحة، ثم توثيق ما تم اكتشافه.
هل غياب الاختبارات سبب كافٍ لإعادة البناء؟
لا. غياب Tests يرفع مخاطر التغيير، لكنه لا يثبت أن Rewrite هو الحل. يمكن أولًا إضافة اختبارات حول الرحلات والسلوكيات الحرجة، ثم تقييم قدرة النظام على التغيير.
هل إعادة البناء من الصفر أرخص من إصلاح مشروع سيئ؟
لا توجد قاعدة عامة. المقارنة تحتاج Scope، وحالة الكود، ومتطلبات الجديد، وData Migration، والتشغيل المتوازي، والاختبار، ووقت الفريق. أي إجابة رقمية قبل هذا التحليل ستكون تخمينًا.
ما أول شيء يجب فعله عند استلام مشروع متعثر؟
تأكد من الوصول إلى الأصول الأساسية، ثم اعمل Inventory وTechnical Assessment قبل الالتزام بتغييرات كبيرة: Repository، وBuild، وProduction، والبيانات، والحسابات، والتكاملات، والتوثيق، والمشكلات الحالية.
الخلاصة: لا تهدم قبل أن تعرف ما الذي تحاول إصلاحه
المشروع المتعثر لا يحتاج دائمًا مزيدًا من الكود. يحتاج أولًا إلى قرار مبني على أدلة.
أحيانًا ستكون النتيجة Refactor. أحيانًا إعادة بناء جزء محدد. وفي حالات أخرى سيكون Full Rebuild مبررًا. قيمة الـTechnical Audit أنه يجعل هذه النتيجة نتيجةً للتحليل، لا افتراضًا سابقًا عليه.
لديك تطبيق أو منصة متعثرة وتحتاج معرفة ما الذي يمكن إنقاذه؟
قبل الالتزام بإعادة بناء كاملة، يمكن البدء بمراجعة الـRepository وArchitecture والبيانات والـCI/CD والحسابات والتكاملات، لتحديد المشكلات الفعلية والخيارات المتاحة ونطاق المرحلة التالية. تعرّف على خدماتنا أو ابدأ بجلسة استكشاف.
المصادر
- Microsoft — Assess workloads for migration and modernization، Cloud Adoption Framework.
- Microsoft — The 6 Rs of application modernization.
- AWS Prescriptive Guidance — Modernization process.
- Microsoft — Safe deployment practices، Azure Well-Architected Framework.
- Martin Fowler — Strangler Fig Application.
- Microsoft — Plan cloud modernization.
- Google Cloud — Modernization overview: validation and functional equivalence.
- GitHub Docs — Secure use and code scanning.
- Microsoft — Microservices assessment and readiness.
- Microsoft — Prepare your organization for cloud modernization.
القوائم ومصفوفة القرار في هذا المقال إطار تحليلي عملي وليست معايير مطلقة. يجب تكييفها وفق Architecture والمنتج والبيانات والمخاطر التشغيلية الخاصة بكل مشروع.
