قبل كل شيء، قدّر ما يحمله النظام القديم
النظام الذي يدير عمل شركة منذ سنوات طويلة يضم أكثر من شيفرة قديمة؛ ففيه كل قاعدة واستثناء وتصحيح أُضيف لأن خطأً ما وقع ذات مرة. ومعظم ذلك غير مدوّن في أي مكان آخر، وربما غادر الشركة من طلبوه أصلاً.
ولهذا يكون استبدال البرمجيات القديمة أصعب مما يبدو. فالميزات الظاهرة سهلة الحصر، أما السلوك الخفي، كطريقة عمل قاعدة التقريب أو ما يحدث لطلب يُسجَّل في آخر يوم من الشهر، فلا يُكتشف إلا حين يخطئ فيه النظام الجديد. لذلك يجب أن تتعامل أي خطة مع هذه المعرفة، لا مع التقنية وحدها.
أمامك أكثر من طريقين
| الطريق | ما يعنيه | يناسب حين |
|---|---|---|
| الإبقاء عليه وعزله | تترك النظام كما هو، وتضع أمامه واجهة حديثة أو واجهة برمجة (API) | النظام مستقر ونادراً ما يتغير، وحاجته الأساسية أن يتصل بأدوات أحدث |
| إعادة الاستضافة | تنقله إلى بنية تحتية حديثة بأقل قدر ممكن من التغييرات | الخطر في الأجهزة أو الاستضافة، لا في البرمجيات |
| إعادة هيكلة الشيفرة | تحسّن الشيفرة من الداخل على مراحل، دون أن تغيّر ما يفعله النظام | منطق النظام سليم، لكن تعديل شيفرته بأمان صعب |
| الاستبدال على أجزاء | تبني أجزاء جديدة إلى جانب النظام القديم، وتنقل إليها الوظائف واحدة تلو الأخرى | النظام كبير وحيوي، ويجب أن يبقى عاملاً طوال الوقت |
| إعادة الكتابة | تبني نظاماً جديداً كاملاً، ثم تنتقل إليه | النظام صغير، أو تصميمه القديم يعيق كل ما تحتاج إليه |
| شراء منتج جاهز | تُوقف النظام وتعتمد بدلاً منه منتجاً موجوداً في السوق | ما يؤديه النظام أصبح وظيفة قياسية منذ أن بُني |
يشمل التحديث الطرق الثلاثة الأولى، وكثيراً ما يشمل الطريق الرابع أيضاً، أما الاستبدال فيشمل الطريقين الأخيرين. والاستبدال على أجزاء يجمع بين الاثنين، ولهذا كثيراً ما يكون هو الحل.
متى يناسب كل منهما
رجّح التحديث حين
- ما زال النظام يطابق طريقة عمل شركتك
- المشكلة في السرعة أو الاستقرار أو الأمان أو تكلفة التعديلات
- النظام أهم من أن يُوقف، ولو ليوم واحد
- قواعده معقدة وتوثيقها ضعيف
- يجب أن تُنفق الميزانية على مراحل، تحقق كل منها قيمة
رجّح الاستبدال حين
- تغيّرت إجراءات العمل وصار النظام يعرقلها
- لم يعد دعم التقنية أو تأمينها ممكناً على الإطلاق
- صار في السوق منتج يؤدي العمل نفسه جيداً
- النظام صغير بما يكفي لإعادة بنائه بثقة
- نموذج البيانات نفسه لا يصلح لما تحتاج إليه في المرحلة المقبلة
لماذا تُعدّ إعادة الكتابة الكاملة أخطر الطرق
- لا يُسلَّم شيء قبل النهاية. تدفع الشركة مدة طويلة قبل أن ترى أي فائدة، وعليها في الوقت نفسه أن تواصل صيانة النظام القديم
- الهدف يتحرك. فبينما يُبنى النظام الجديد، تواصل الشركة تعديل القديم، وتظل إعادة الكتابة تلاحقه
- القواعد الخفية تظهر متأخرة. سلوك لم يرد في أي قائمة يظهر أثناء الاختبار، أو بعد الانتقال إلى النظام الجديد
- الانتقال يجري دفعة واحدة. فتتركز المخاطر كلها في عطلة نهاية أسبوع واحدة
- التقديرات هنا في أضعف حالاتها. فحجم إعادة الكتابة يُقدَّر انطلاقاً من الميزات الظاهرة، وهي الجزء الأصغر
لا يعني هذا أن إعادة الكتابة خطأ في كل الأحوال؛ فقد تكون أنظف طريق لنظام صغير، أو لنظام يعيقك تصميمه فعلاً. المقصود أن تختارها عن وعي، بعد أن تعرف تكلفة البدائل.
كيف يجري الاستبدال جزءاً بعد جزء
- 01
ضع طبقة أمام النظام
تمر كل الطلبات عبر نقطة دخول جديدة، تستطيع أن توجّه كل طلب إلى النظام القديم أو إلى جزء جديد.
- 02
اختر الجزء الأول
وظيفة ذات قيمة، ومفهومة جيداً، وقليلة الارتباط ببقية النظام.
- 03
ابنِه من جديد وشغّل الاثنين معاً
لفترة من الوقت، يعالج الجزء الجديد والجزء القديم الحالات نفسها، وتُقارَن نتائجهما.
- 04
انقل هذا الجزء
تتحول طلبات هذه الوظيفة إلى الجزء الجديد، ويُستغنى عن شيفرتها القديمة.
- 05
كرّر
كل جزء يحقق قيمة، ويعلّمك شيئاً عن القواعد المخفية في الجزء التالي.
يتقلص النظام القديم حتى يصبح ممكناً إيقاف ما تبقى منه أو إبقاؤه معزولاً. وفي كل مرحلة يبقى لدى الشركة نظام يعمل، ويمكن إيقاف المشروع مؤقتاً دون أن يُترك شيء نصف منجز.
حين يكون النظام منتج برمجيات كخدمة (SaaS) له عملاء يدفعون
تزداد خطورة هذا القرار حين يكون النظام منتج SaaS. فالنظام الداخلي يمكن نقله خلال عطلة نهاية أسبوع بعد إبلاغ الموظفين مسبقاً، أما منتج له عملاء يدفعون فلا يملك أن يتوقف، ويلاحظ كل عميل، في اليوم نفسه، أن شيئاً اعتمد عليه صار يعمل بطريقة مختلفة.
- العملاء يواصلون طلب الميزات. وإعادة البناء التي تجمّد المنتج إلى أن يلحق النظام الجديد بالقديم تسلّم السوق للمنافسين، أما العمل التدريجي فيسمح باستمرار الإصدارات.
- مطابقة ميزات المنتج القديم أكبر مما تبدو. فسنوات من التفاصيل الصغيرة في السلوك والإعدادات والحالات الاستثنائية لا وجود لها إلا في الشيفرة القديمة وفي عادات العملاء.
- البيانات تنتقل عميلاً بعد عميل. فلكل حساب تاريخه وإعداداته، ولذلك يتكون النقل من خطوات صغيرة كثيرة، يجب أن يكون التراجع عن كل منها ممكناً.
- منتجان يعنيان تكلفة مضاعفة. فما دام القديم والجديد يعملان جنباً إلى جنب، يحتاج كل منهما إلى استضافة ودعم وإصلاحات.
لهذه الأسباب يكون الطريق التدريجي هو المعتاد مع منتجات SaaS: تُبنى الأجزاء الجديدة إلى جانب المنتج القديم، خلف نظام تسجيل الدخول والفوترة نفسه، ويُحوَّل إليها الاستخدام قسماً بعد قسم. ثم يُنقل العملاء على دفعات، بدءاً بمن طلبوا ما تقدمه الأجزاء الجديدة.
وتبقى إعادة البناء الكاملة القرار الصحيح في حالات أقل: حين يعيق نموذج البيانات نفسه ما يحتاج إليه العملاء الآن، أو حين يتعذر استضافة التقنيات القديمة أو إيجاد فريق يعمل عليها بأمان، أو حين يكون المنتج صغيراً بحيث يمكن مطابقة ميزاته بسرعة.
مثال تطبيقي
نظام الطلبات لدى شركة بيع بالجملة
الشركة افتراضية. بُني نظام الطلبات لديها منذ زمن بعيد على منصة لم يعد يعرفها اليوم إلا قليل من المهندسين.
- المشكلةالميزات الجديدة تستغرق شهوراً، والمطوّر الوحيد الذي يفهم النظام على وشك التقاعد، والعملاء يريدون الطلب عبر الإنترنت.
- الخطة المغريةإعادة كتابة كل شيء بتقنيات حديثة، والانتقال إلى النظام الجديد في العام المقبل.
- ما كشفه التقييمقواعد تسعير فيها مئات الاستثناءات الخاصة بعملاء بعينهم، ولا توثيق لها إلا في الشيفرة. وإعادة الكتابة الكاملة كانت ستضطر إلى اكتشاف كل استثناء منها من جديد.
- الخطة المختارةأولاً واجهة API أمام النظام القديم، ليُبنى على الفور موقع جديد يطلب منه العملاء. ثم نُقل التسعير إلى خدمة جديدة عملت بالتوازي مع النظام القديم حتى تطابقت نتائجهما. ويأتي بعده المخزون ثم الفوترة، كلٌّ في دوره.
صار العملاء يطلبون عبر الإنترنت منذ المرحلة الأولى، قبل وقت طويل من إيقاف النظام القديم. وجرى التحقق من قواعد التسعير على طلبات حقيقية، بدل الاكتفاء بالثقة في مواصفات مكتوبة.
ما تقيّمه قبل أن تختار
قائمة التقييم
0 من 8 منجزةيجيب التدقيق التقني المستقل للشيفرة عن معظم هذه الأسئلة بالأدلة، وهو إنفاق أول معقول قبل أي إنفاق أكبر.
ماذا تفعل الآن
أجرِ التقييم، ثم احسب تكلفة طريقين على الأقل جنباً إلى جنب، بما في ذلك تكلفة إبقاء النظام القديم عاملاً خلال كل منهما. تشرح صفحة تحديث البرمجيات القديمة طريقتنا في هذا العمل، وتتناول مقارنتنا بين البرمجيات المخصصة والجاهزة الحالة التي قد يناسبك فيها منتج جاهز اليوم.
وإن أردت رأياً في نظامك، أخبرنا بما يفعله وأين تكمن مشكلاته، وسنخبرك بالطريق الذي نبدأ بدراسته.
أسئلة شائعة
كيف نعرف إن كانت برمجياتنا تُعدّ قديمة؟
العمر وحده لا يحسم ذلك. يُعدّ النظام قديماً حين يصبح تعديله بطيئاً أو محفوفاً بالمخاطر، أو حين تتوقف المنصة عن تلقي الدعم، أو حين يقل عدد من يستطيعون صيانته. أما نظام عمره عشر سنوات، مختبَر وموثّق ويعمل على منصة مدعومة، فهو ببساطة نظام ناضج.
هل التحديث أقل تكلفة من الاستبدال؟
في الغالب نعم، لأن العمل يتوزع على مراحل وكل مرحلة تعود بقيمة. لكنه ليس دائماً أقل تكلفة في المجموع؛ فإذا لم يعد النظام يناسب عملك، فكل ما تنفقه على تحسينه يذهب إلى المكان الخطأ. والمقارنة العادلة تحسب تكلفة كل طريق كاملة، بما فيها تشغيل النظام القديم أثناء العمل.
هل يمكن تحديث النظام دون أن يتوقف العمل؟
نعم، وهذه هي الحجة الرئيسية للعمل على أجزاء. فالطبقة التي توضع أمام النظام القديم تتيح للأجزاء الجديدة أن تتولى الوظائف واحدة تلو الأخرى، ويعمل القديم والجديد جنباً إلى جنب حتى يثبت الجزء الجديد جدارته. فلا يوجد يوم ينتقل فيه كل شيء دفعة واحدة.
ماذا يحدث لبياناتنا؟
تنتقل على مراحل أو دفعة واحدة، بحسب الطريق الذي تختاره. وفي الحالتين ينبغي أن تُفحص أولاً، ثم تُنظَّف، وتُنقل في عمليات تجريبية، وتُطابَق مع النظام القديم. أما البيانات التاريخية التي لا يحتاج إليها النظام الجديد، فيمكن أرشفتها في صيغة مقروءة بدل نقلها.
