تحديث البرمجيات القديمة دون إعادة كتابة شاملة

لدى كل شركة راسخة تقريبًا واحد منها: برنامج يستاء منه الجميع بصمت. إنه بطيء، قبيح، نصف الفريق يعرف حيلة للالتفاف على عطل لم يصلحه أحد قط، والشخص الوحيد الذي كان يفهمه غادر في 2019. والغريزة دائمًا واحدة: أحرقه وابنِ آخر جديدًا. وهذه الغريزة، في أغلب الأحيان، هي بالضبط كيف تخسر الشركات الجيدة عامًا وثروة صغيرة بلا مقابل.

رأيت إعادة الكتابة الكبرى تفشل مرات كافية حتى صار لديّ ردّ فعل تجاهها. يُريني مؤسس نظام طلباته المتهالك أو أداة جدولته العتيقة، فيتنهد ويقول نسخة ما من عبارة «نحتاج فقط إلى استبدال كل شيء.» وربما يومًا ما ستفعل. لكن إعادة الكتابة الكاملة — اقتلاع النظام القديم، وبناء آخر لامع بالتوازي، ثم قلب المفتاح — هي من أخطر الخطوات في عالم البرمجيات كله. إنها مكلفة، وتستغرق وقتًا أطول بكثير مما وُعد به، وطوال المدة كلها تعمل وأنت أعمى، تأمل أن يغطي الجديد كل حالة هامشية غريبة عالجها القديم بهدوء طوال خمسة عشر عامًا.

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

لماذا إعادة الكتابة الشاملة مغرية إلى هذا الحد — وخطيرة إلى هذا الحد

إعادة الكتابة الكاملة مغرية لأنها تَعِد بصفحة بيضاء. لا مزيد من فوضى الإرث، لا مزيد من التنازلات، قاعدة شيفرة جديدة مبنية بالطريقة الصحيحة بأدوات حديثة. على لوح أبيض تبدو بديهية. أما في الواقع، فأنت توقّع على إعادة بناء سنوات من منطق الأعمال المتراكم — كثير منه غير موثّق، وبعضه يعيش فقط في رؤوس أشخاص رحلوا — بينما الساعة تدور والفواتير تتوالى.

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

هناك حكمة معروفة في الصناعة هنا، وهي مستحقة: النظام الثاني، إعادة الكتابة الكبرى، اعتاد أن يستغرق ثلاثة أضعاف ما قُدّر له، وأن يصل بميزات أقل مما يستبدله. التقدير ليس خاطئًا لأن الناس مهملون، بل لأن أحدًا لا يستطيع في البداية أن يرى كل الأشياء الصغيرة التي يفعلها النظام القديم بصمت على نحو صحيح.

ماذا يعني «الإرث» فعلًا (الأمر ليس متعلقًا بالعمر)

نرمي كلمة إرث هنا وهناك وكأنها تعني فقط «قديم». ليست كذلك. كثير من البرمجيات التي تعمل منذ عقد على ما يرام تمامًا — مملة، مستقرة، مدفوعة الثمن، تؤدي عملها. العمر وحده ليس سببًا للمساس بأي شيء. أغلى خطأ في هذا المجال كله هو تحديث شيء كان يعمل بهدوء، لمجرد أنه بدا قديم الطراز.

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

شخّص قبل أن تمسّ أي شيء

قبل إعادة كتابة سطر واحد، تحتاج إلى خريطة صادقة لمكان وجود الألم فعلًا. في أغلب الأحيان، النظام الذي يكرهه الجميع سليم بنسبة 80٪. المشكلة متركزة في بضعة مواضع محددة — شاشة بطيئة واحدة، تكامل معطّل واحد، سير عمل يفرض إدخال البيانات مرتين — وتلك المواضع القليلة تولّد كل الشكاوى تقريبًا. اعثر عليها، تكن قد عثرت على مشروعك بأكمله.

طريقة العثور عليها ليست تدقيقًا تقنيًا أولًا — إنها محادثة. اجلس مع من يستخدمون الأداة كل يوم واسألهم أين يؤلم. أين ينتظرون؟ ماذا يعيدون كتابته؟ ماذا يتجنبون لأنه مؤلم؟ أين يحتفظون بجدول بيانات خاص للالتفاف على النظام الرسمي؟ تلك الحيل ذهب: كل واحدة منها صورة شعاعية دقيقة لمشكلة تستحق الإصلاح.

• الشاشات والخطوات التي يشكو منها الناس أكثر — لا نظريًا، بل في عملهم اليومي الفعلي.
• كل موضع تُكتب فيه البيانات مرتين لأن نظامين لا يتحدثان أحدهما إلى الآخر.
• التكاملات التي انكسرت، أو لم توجد قط، فأجبرت على النسخ واللصق اليدوي بين الأدوات.
• أي شيء يعرف شخص واحد فقط كيف يشغّله أو يصلحه — نقاط فشلك الوحيدة.
• الأجزاء السليمة فعلًا، كي تحميها وتتركها كما هي.
• ما سيحتاجه العمل العام المقبل ولا يستطيع النظام الحالي أن ينمو ليبلغه.

حين تفعل هذا بصدق، يتقلص المشروع عادةً. المالك الذي دخل قائلًا «استبدل كل شيء» يخرج وقد أدرك أنه يحتاج إلى إصلاح ثلاثة أشياء. هذا ليس خيبة أمل — إنه راحة. ثلاثة أشياء قابلة للإصلاح مشروع تستطيع إنهاءه هذا الربع. أما الاستبدال الكامل فعام قد لا تنجو منه.

نهج الخنق: استبدله قطعة قطعة

هناك نمط لفعل هذا بأمان، واسمه كئيب قليلًا لكنه لا يُنسى: نهج الخنق، نسبةً إلى شجرة التين الخانقة — متسلّق ينمو حول شجرة، ويستولي تدريجيًا على بنيتها حتى يقف النمو الجديد في النهاية بمفرده ويزول الجذع القديم. مطبّقًا على البرمجيات، تكون الفكرة عملية بشكل بديع: لا تستبدل النظام القديم في تبديل بطولي واحد. تُنمّي الجديد حوله، قطعة قطعة، حتى لا يبقى من القديم شيء يحتاجه أحد.

عمليًا يجري الأمر هكذا. تختار قطعة مؤلمة واحدة — مثلًا، وحدة الفوترة التي يكرهها الجميع. تبني بديلًا حديثًا لتلك القطعة وحدها. توجّه الفوترة إلى الوحدة الجديدة بينما يبقى كل شيء آخر يعمل على النظام القديم، دون مساس. تراقبها مدة. حين تصبح متينة، يسكن ذلك الجزء من النظام القديم، فتنتقل إلى القطعة التالية. يتقلص النظام القديم تدريجيًا، كشمعة، بدلًا من هدمه دفعة واحدة.

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

كيف يبدو الإيقاع فعلًا

1. 1
   اختر القطعة الأكثر إيلامًا والأكثر استقلالًا

   تريد ألمًا عاليًا وحوافّ نظيفة — وحدة تؤلم كثيرًا ولا تمدّ أصابعها في كل شيء آخر. تلك هدفك الأول.
2. 2
   ضع طبقة رقيقة أمام النظام القديم

   طبقة توجيه صغيرة تقرر أي الطلبات يذهب إلى النظام القديم وأيها إلى القطعة الجديدة. هذا هو المفصل الذي يجعل كل شيء آخر ممكنًا.
3. 3
   ابنِ وأطلق تلك القطعة الواحدة فقط

   استبدل وحدة واحدة، وضعها في أيدٍ حقيقية، ووجّه إليها تلك الشريحة من العمل فقط. أسابيع، لا سنوات — وبقية النظام لم تتحرك.
4. 4
   ثبّت، ثم انتقل إلى القطعة التالية

   ما إن تُمنح الوحدة الجديدة الثقة، يخمد الجزء المقابل من النظام القديم. كرّر مع القطعة المؤلمة التالية، متعلمًا وأنت تمضي.
5. 5
   أحِل النظام القديم على التقاعد حين يفرغ

   في النهاية لا يفعل النظام القديم شيئًا يعتمد عليه أحد. عندئذٍ فقط تطفئه — بهدوء، بلا دراما، لأن كل شيء مهم انتقل سلفًا.

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

أحيانًا لا تحتاج حتى إلى استبداله

قبل أن تستبدل أي شيء على الإطلاق، يجدر أن تسأل ما إن كان النظام القديم يحتاج إلى استبدال أم يحتاج فقط أن يكفّ عن كونه جزيرة. عدد مفاجئ من مشكلات «نحتاج نظامًا جديدًا» هو في الحقيقة مشكلات «أنظمتنا لا تتحدث بعضها إلى بعض». البرنامج القديم بارع في عمله — لكنه يقبع في صومعة، مجبرًا الناس على نقل البيانات داخلًا وخارجًا يدويًا.

في تلك الحالات، الإصلاح الأرخص والأسرع ليس نظامًا جديدًا. إنه جسر. تُحيط البرنامج القديم بوصلة — تكامل يجعله يتبادل البيانات مع أدواتك الأخرى تلقائيًا — وطبقة حديثة فوقه للأجزاء التي يلمسها الناس فعلًا. المحرّك القديم يظل يطنّ تحت السطح؛ الفريق يحصل على واجهة نظيفة ونهاية للنسخ واللصق. ليس أمرًا براقًا، لكنه غالبًا أعلى عائد لكل يورو في الجهد كله.

متى تكون إعادة الكتابة الكاملة هي القرار الصائب حقًا

قضيت هذا الدليل كله أُثنيك عن إعادة الكتابة الكبرى، فدعني أنصف: أحيانًا تكون فعلًا هي الجواب. هناك أُسس متعفّنة إلى حدّ أن لا قدر من الترقيع أو الجَسر أو الاستبدال قطعة قطعة سينقذها، والتظاهر بعكس ذلك مجرد تأجيل للمحتوم بينما تنفق المال على دعم جثة.

العلامات الصادقة محددة. التقنية التي بُني عليها النظام ميتة أو تحتضر — لا دعم، لا تحديثات أمان، لا أحد بقي قادرًا على العمل عليها. العمل تغيّر تغيّرًا جوهريًا إلى حدّ أن النموذج القديم لم يعد يطابق الواقع البتة. أو النظام متشابك إلى حدّ أن حتى التغييرات الصغيرة تكسر أشياء في مواضع لا علاقة لها روتينيًا، ما يعني عادةً غياب مفاصل نظيفة لتطبيق نهج الخنق أصلًا. حين يصدق اثنان أو ثلاثة من هذه معًا، يكفّ العمل التدريجي عن كونه الخيار الأأمن.

وهنا الثمرة الهادئة لإنجاز العمل التدريجي أولًا، حتى لو أعدت البناء في النهاية: حين تصل، ستفهم النظام أعمق بكثير مما كنت في البداية. كل وحدة استبدلتها علّمتك شيئًا لم يدوّنه المؤلفون الأصليون قط. إعادة كتابة مستنيرة بتلك المعرفة كائن مختلف تمامًا، وأكثر أمانًا بكثير، من تلك التي تُطلق على تفاؤل اليوم الأول.

الجزء الذي لا يذكره أحد: الأمر في معظمه عن الناس

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

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

أسئلة شائعة