تدقيق الشيفرة
تحليل ثابت للشيفرة، وخريطة للاعتماديات، وفحص أمني، وتقدير للدين التقني، موثّقة جميعها مع المخاطر والأولويات.
تحديث الأنظمة القديمة · استبدال على مراحل
استبدلوا النظام القديم دون أن يتوقف العمل.
تحديث الأنظمة القديمة يعني إعادة بناء تطبيق متقادم على مراحل مخططة بينما يواصل النظام الحالي عمله، بدلاً من إيقاف كل شيء في يوم واحد. ندقق الشيفرة والبيانات الحالية، ونتفق معكم كتابةً على ترتيب الاستبدال، ولا ننقل أي وحدة إلا بعد مطابقة بياناتها مع النظام القديم.
- النظامان القديم والجديد يعملان جنباً إلى جنب
- التحقق من البيانات قبل كل انتقال
- خطة تراجع لكل عملية تحويل
المشكلة
نادراً ما يتعطل النظام القديم دفعة واحدة. بل يُبطئ كل شيء أولاً.
لا تزال معظم الأنظمة القديمة تؤدي عملها. لكن المشكلة تظهر في مواضع أخرى: مكتبات لم تعد تتلقى تحديثات أمنية، وتعديلات صغيرة تستغرق أشهراً لأن لا أحد متأكد مما قد تعطّله، وعدد أقل من المطورين المستعدين للعمل على الشيفرة أصلاً.
إعادة الكتابة الكاملة التي تُسلَّم في يوم إطلاق واحد تبدو مرتبة على الورق، لكنها تعرّض جميع العمليات للخطر في وقت واحد. لذلك نفضّل استبدال النظام جزءاً بعد جزء، لتكون كل خطوة صغيرة بما يكفي لاختبارها جيداً والتراجع عنها عند الحاجة.
نهجنايبقى النظام الحالي قيد التشغيل، وتُبنى الأجزاء الجديدة إلى جانبه، وتُنقل البيانات والمستخدمون وحدةً بعد وحدة، ولا تُوقَف الشيفرة القديمة إلا حين لا يعتمد عليها أي شيء.
- الأولويات تحددها مخاطر العمل، لا سهولة البرمجة
- تعتمدون كل مرحلة قبل أن تبدأ المرحلة التالية
- الجدول الزمني مكتوب في العقد على شكل مراحل
ماذا نقدم
ستة أجزاء لعملية التحديث، تُحدَّد حسب نظامكم.
لا يحتاج كل مشروع إلى الأجزاء الستة. يحدد التدقيق ما ينطبق منها، ولا يذكر عرض السعر المكتوب إلا هذه الأجزاء.
نقل البيانات
قواعد تحويل لكل حقل، وتنظيف السجلات غير المتسقة، وفحوص آلية قبل كل عملية نقل وبعدها.
الاستبدال على مراحل
نمط strangler fig: تتولى الوحدات الجديدة وظيفة واحدة في كل مرة، بينما يتولى النظام القديم بقية الوظائف.
طبقة API
طبقة REST أو GraphQL أمام النظام القديم، لتتصل بها التطبيقات الجديدة والشركاء دون المساس بالشيفرة القديمة.
تخطيط الانتقال
تنتقل الوحدات منخفضة المخاطر أولاً والعمليات الحرجة لاحقاً، ولكل منها خطة تراجع جاهزة يوم الانتقال.
التوثيق
توثيق تقني ومرجع API للنظام الجديد، يُحدَّث مع كل تغيير فيه.
كيف يسير العمل
أربع مراحل، تُعتمد كل منها كتابةً.
يتابع العملاء خارج تركيا العمل عبر اجتماعات الفيديو وبيئة معاينة خاصة، بتوقيت UTC+3 نفسه المعتمد في الرياض ومدينة الكويت والدوحة.
- مراجعة النظام الحاليالشيفرة المصدرية والاعتماديات والأداء وعمليات العمل التي يخدمها النظام. وتتسلمون تقريراً عن الدين التقني وترتيباً مقترحاً للعمل.
- الاتفاق على الخطةالهيكل المستهدف، واختيار التقنية، ومصفوفة المخاطر، والمراحل. ويُحدَّد ترتيب نقل الوحدات قبل كتابة أي شيفرة.
- البناء بالتوازيتُطوَّر الوحدات الجديدة بينما يبقى النظام القديم قيد التشغيل. وتجتاز كل وحدة اختبارات الوحدة واختبارات التكامل، ثم فحوص البيانات في بيئة الاختبار (staging).
- الانتقال خطوة بخطوةتُطلَق الوحدات واحدة تلو الأخرى مع خطة تراجع جاهزة. ويُوقَف النظام القديم تدريجياً حين لا يعتمد عليه أي شيء.
هل حان الوقت؟
علامات تدل على حاجة النظام إلى التحديث، وعلامات تدل على عكس ذلك.
يستحق التحديث أن يُناقش إذا
- لم تعد المكتبات الأساسية أو إصدار لغة البرمجة يتلقى تحديثات أمنية
- كانت التعديلات البسيطة تستغرق وقتاً أطول بكثير مما ينبغي، أو يُتجنَّب إجراؤها تماماً
- كانت البيانات محفوظة في جداول بيانات أو دفاتر إلى جانب النظام لأنه لا يستوعبها
قد لا تحتاجون إليه بعد إذا
- كان النظام مستقراً ومدعوماً ونادراً ما يتغير
- كانت المشكلة الحقيقية تقريراً واحداً ناقصاً أو تكاملاً واحداً ناقصاً، ويمكن حلها بمشروع أصغر
تطوّر Kodem برمجياتكم، وتستضيفها على خوادم في تركيا، وتحافظ على تحديثها. تبقى الشيفرة المصدرية لدى Kodem. ويُسجَّل اسم النطاق باسمكم، ويبقى محتواكم وبياناتكم ملكاً لكم دائماً.
أعمال ذات صلة
أنظمة نقلناها من القديم إلى الجديد.
دفتر ورقي حلّ محله نظام أعمال، وموقع نُقل دون خسارة أي عنوان، وخادم مخترق أُعيد بناؤه بشكل نظيف.
مشغّل مستودعات تبريدنظام أعمال · من الدفتر إلى النظام652 فحصاً شاملاً آلياً
من دفتر ورقي إلى نظام أعمال بصلاحيات حسب الدور وقابل للتدقيق
حسابات العملاء، وحركة الدخول والخروج من المستودع، ومحفظة الشيكات، والعمولات، ودفتر اليومية في نظام واحد، مع تحرير داخل الخلايا كي يحتفظ الفريق بعادات الجداول.
- 3 أدوار للمستخدمين مع فحص الصلاحيات من جهة الخادم
- سجل تغييرات على مستوى الحقل: من غيّر ماذا ومتى
- تطبيق قابل للتثبيت ويمكن أن يعمل دون اتصال
- 12 حزمة اختبار شاملة، ونسخ احتياطي يومي تلقائي
استشارات صناعيةموقع شركة · نقل من منصة جاهزة355/355 رابطاً قديماً تم التحقق منه
جميع روابط الموقع القديم الـ 355 انتقلت دون خسارة رابط واحد
نُقل موقع يجذب زيارات البحث منذ سنوات إلى بنية جديدة بشيفرة مخصصة. فُحص كل عنوان قديم على حدة، فحُفظت مكانته في محركات البحث.
- التحقق من جميع الروابط القديمة الـ 355، دون أي خطأ
- نقل جميع الصور (161/161)
- Lighthouse: الجوال 90–100، الحاسوب 100
- تدقيق آلي وفق WCAG 2.2 AA: صفر مخالفات
متجر مستلزمات تربية النحلكتالوج · استعادة الأمان وSEOمن 12 إلى 0 ملاحظة حرجة
من موقع استولت عليه شيفرة خبيثة إلى كتالوج نظيف وسريع
زُرعت شيفرة خبيثة في الخادم القديم. نُقل 101 منتج، لكل منها نص استخدام أصلي، إلى بنية نظيفة مع حاسبات لتربية النحل ومسرد للمصطلحات.
- ملاحظات SEO الحرجة: من 12 إلى 0، والتحذيرات: من 389 إلى 30
- 101 صفحة منتج بنص أصلي لكل منها
- 413/413 اختباراً آلياً
- Lighthouse على الحاسوب 100 (10/10 صفحات)، والجوال 92–98
طريقة القياس: قيست الملاحظات بسكربت تدقيق SEO للموقع كاملاً، والصفحات بحزمة اختبار آلية، والسرعة بأداة Lighthouse.
المشاريع مجهّلة: لا ننشر أسماء العملاء دون موافقة مكتوبة. الأرقام من اختبارات يوم التسليم، وقد تتغير القيم الحية مع الوقت.
كيف نحدّ من المخاطر
خطوات صغيرة، يمكن التراجع عن كل منها.
نسخة احتياطية كاملة أولاً
تُؤخذ نسخة كاملة من بيانات المصدر قبل بدء أي تحويل.
فحوص آلية للبيانات
تُقارن أعداد السجلات والمجاميع والحقول الرئيسية بين النظامين القديم والجديد، وتُبلَّغون بأي فروق.
القبول في بيئة الاختبار
تُعتمد كل وحدة في بيئة الاختبار قبل أن تصل إلى المستخدمين الفعليين.
التراجع جاهز
لكل عملية انتقال طريق عودة مكتوب، يُعَدّ ويُختبر قبل موعدها.
أسئلة شائعة
أسئلة عن تحديث الأنظمة القديمة
هل يمكن أن يستمر النظام القديم في العمل أثناء التنفيذ؟
نعم. تُبنى الوحدات الجديدة بالتوازي، ويواصل المستخدمون العمل على النظام الحالي حتى تصبح كل وحدة جاهزة لتولي مهامها. وتُجدوَل عمليات الانتقال في الأوقات الأقل تأثيراً على عملياتكم.
كيف تتعاملون مع خطر فقدان البيانات؟
نأخذ نسخة احتياطية كاملة من النظام المصدر، ونطبق قواعد التحويل على مراحل، ونجري فحوصاً آلية لسلامة البيانات قبل إطلاق أي شيء. ولكل عملية انتقال إجراء تراجع جاهز. نخطط لإبقاء المخاطر منخفضة، لكننا لا نَعِد بألا تحدث أي مشكلة إطلاقاً.
هل يجب أن نستبدل كل شيء دفعة واحدة؟
لا. باستخدام نمط strangler fig تُستبدل أجزاء النظام بترتيب مختار. ويمكن ترك الأجزاء عالية المخاطر أو منخفضة الأولوية إلى النهاية، مما يُبقي الميزانية والمخاطر التشغيلية تحت السيطرة.
كم يستغرق المشروع؟
يعتمد ذلك على حجم النظام وحالته، لذلك لا نحدد مدة قبل المراجعة. وبعد المراجعة تُقسَّم الخطة إلى مراحل وتُكتب في العقد.
إلى أي تقنيات تنقلون الأنظمة؟
تُختار التقنيات المستهدفة بعد المراجعة، بناءً على النظام الحالي واحتياجات العمل. ومن الخيارات الشائعة PHP مع Laravel، وNode.js، وReact أو Vue للواجهة الأمامية، وPostgreSQL أو MySQL للبيانات.
هل يمكن أن يكون النظام بالإنجليزية والعربية؟
نعم. يمكن بناء الواجهات الجديدة بلغتين، مع تصميم النسخة العربية من اليمين إلى اليسار بدلاً من الاكتفاء بترجمتها.
ابدؤوا بمراجعة، لا بإعادة كتابة.
أخبرونا بما يقوم به النظام الحالي وأين مواضع الخلل فيه. وبعد اجتماع تعريفي مجاني عبر الفيديو، نقترح ما يجب مراجعته ونرسل إليكم عرض سعر مكتوباً ومفصّلاً بنداً بنداً.