استبدل النظام القديم من دون أن توقف العمل.
النظام لا يزال يعمل. لكنه مكلف في كل تغيير، وصعب في التوظيف له، ولا يفهمه إلا شخص واحد. هذا قابل للإصلاح، على مراحل، وكل شيء يعمل أثناء ذلك.
نحدّث الأنظمة القديمة قطعةً قطعة بدل استبدالها دفعة واحدة. يعمل القديم والجديد جنباً إلى جنب، وتنتقل الحركة إلى الجديد تدريجياً كلما أثبت نفسه، وتستطيع التوقف عند نهاية أي مرحلة محتفظاً بما أُنجز. نبدأ بقراءة الكود وتقرير مكتوب عن حالته، ونتفق على ترتيب المراحل ومواعيدها كتابةً قبل البدء.
آخر تحديث نوفمبر 2026
الخيار الذي يبدو أنظف يفشل أكثر.
إعادة الكتابة الكاملة لا تسلّم شيئاً حتى النهاية. أما الاستبدال على مراحل فيسلّم باستمرار.
إعادة الكتابة التي تستبدل كل شيء دفعة واحدة هي الطريقة التي تفشل بها هذه المشاريع.
الإغراء حاضر دائماً: نبدأ من الصفر، ننجزها كما ينبغي هذه المرة، ونحوّل كل شيء في عطلة نهاية أسبوع. في الواقع يستغرق ذلك ضعف المخطط، ويظل النظام القديم يحتاج تعديلات طوال البناء، وتكون ليلة التحويل خطرة فعلاً.
البديل أقل إثارة وأكثر أماناً بكثير: انقل قطعة واحدة في كل مرة. الكود الجديد يتولى جزءاً من الحركة، والقديم يتولى الباقي، وتتغير النسبة كلما أثبتت قطعة جديدة نفسها.
يستغرق ذلك وقتاً أطول في المجموع، لكنك تستطيع التوقف متى شئت، حتى في منتصف الطريق إذا تبيّن أن ما تبقى من القديم لا بأس به. هذا الخيار وحده يستحق الوقت الإضافي في معظم الحالات.
كيف ننجزه.
تقييم صادق أولاً
في أي حال الكود، ما الخطِر، وما السليم. أحياناً يكون الجواب أن النظام يحتاج أقل مما كنت تخشى.
القطعة الأخطر أولاً
لا الأسهل. الجزء الذي يصبح رحيل شخص واحد عنه مشكلة حقيقية.
الجديد بجانب القديم
الاثنان يعملان، والحركة مقسومة بينهما، وتنتقل تدريجياً كلما أثبتت قطعة نفسها.
بيانات متّسقة بين النظامين
ما دام النظامان يعملان، يجب أن يتفقا. هذا أصعب جزء تقنياً، وهنا تهم العناية.
اختبارات قبل التغيير
الأنظمة القديمة نادراً ما تملكها. نضيف اختبارات حول القطعة قبل أن نلمسها، فتعرف إن انكسر شيء.
توثيق ونحن نتقدم
غالباً أول توثيق حقيقي يحصل عليه النظام. له قيمة حتى لو توقفت مبكراً.
فريقك جزء من العمل
لتنتقل المعرفة إليه، بدل أن تنتقل من نقطة ضعف واحدة إلى نقطة ضعف أخرى.
نقطة توقف في كل مرحلة
كل قطعة مكتملة بذاتها. لن تكون أبداً في منتصف انتقال ولا شيء يعمل.
إعادة كتابة كاملة، أم استبدال على مراحل؟
كلاهما مشروع. أحدهما يفشل أكثر بكثير، وهو الذي يبدو أنظف على الورق.
| إعادة كتابة كاملة | استبدال على مراحل | |
|---|---|---|
| متى ترى أي فائدة | كلها، في النهاية | مع أول مرحلة، ثم باستمرار |
| المخاطرة عند التحويل | كل شيء، في ليلة واحدة | قطعة واحدة في كل مرة |
| التعديلات على القديم أثناء البناء | تصون نظامين معاً | أمر عادي، فهو لا يزال يعمل |
| هل تستطيع التوقف في المنتصف | لا، فليس لديك شيء يعمل | نعم، وتحتفظ بالفائدة |
| المدة الكلية | أقصر على الورق | أطول، بصراحة |
| كم مرة تسوء الأمور | كثيراً | نادراً |
| مناسبة حين | يكون النظام صغيراً والمخاطرة منخفضة | يعتمد العمل على بقاء النظام يعمل |
أنظمة أبقيناها تعمل.
إدارة دورة حياة البطاقات لأكبر مقسم مدفوعات مشترك في باكستان، ولا تزال في الإنتاج.
منصة إدارة أعمال في عُمان، بُنيت وتطورت بقيادة مؤسسنا مديراً تقنياً.
معظم ما نحدّثه مكتوب بإصدارات PHP قديمة. نقرؤه بدل أن ننفر منه.
متى يحين وقت التحديث.
شخص واحد فقط يفهم النظام
السبب الأكثر شيوعاً والأكثر إلحاحاً. هذه مخاطرة على العمل، لا مسألة تقنية.
التغييرات البسيطة تستغرق أسابيع
حين تحتاج ميزة صغيرة شهراً، فالنظام يتقاضى منك فائدة على كل قرار.
لا تجد من توظّفه له
إذا كانت التقنية تُصعّب التوظيف، فالأمر يسوء كل عام.
لا تشترِ هذا إذا كان النظام يعمل ونادراً ما يتغير
نظام مستقر لا يحتاج أحد إلى تعديله ليس مشكلة. سنقول لك أن تتركه وشأنه، وأن تنفق الميزانية في مكان آخر.
كيف نعمل.
نقرأ الكود
كما ينبغي، ونخبرك بحاله، بما في ذلك حين يكون الجواب الصادق أن التحديث ليس عاجلاً.
نجد المخاطرة الحقيقية
ليست عادةً الكود الأقدم، بل الجزء الذي لا يفهمه إلا شخص واحد.
نتفق على الترتيب
أي قطعة أولاً، وما الذي تسلّمه كل مرحلة وحدها، ومتى، كتابةً.
نضيف الاختبارات أولاً
حول القطعة التي نستبدلها، لتعرف إن تغيّر سلوكها.
نشغّل الاثنين معاً
الجديد يتولى جزءاً من الحركة والقديم الباقي، والنسبة تتحرك مع ازدياد الثقة.
نحوّل ثم نزيل
فقط بعد أن تعمل القطعة الجديدة بنظافة. يبقى الكود القديم متاحاً إلى أن تنتفي الحاجة إليه فعلاً.
نسلّم كل مرحلة
وثائق وجولة مع فريقك لكل قطعة، لا تسليم واحد كبير في النهاية.
تحديث البرمجيات القديمة
7 أسئلة مع إجاباتها. لديك سؤال آخر؟ تواصل معنا.
على مراحل، في كل حالة تقريباً يعتمد فيها عملك على بقاء النظام يعمل. إعادة الكتابة الكاملة تبدو أنظف وتفشل أكثر بكثير: لا تسلّم شيئاً حتى النهاية، وتصون خلالها نظامين، وتجمع كل المخاطرة في ليلة تحويل واحدة. إعادة الكتابة معقولة لنظام صغير يمكن احتمال يوم سيئ فيه.