الدين التقني: متى وكيف يجب تحديث تطبيق قديم

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

هل يعني ذلك إعادة بناء كل شيء؟ ليس بالضرورة. إليكم كيف تعرفون أن الوقت قد حان لتحديث التطبيق، وما تكلفة الانتظار، والطرق الثلاث للتصرف.

الدين التقني بعبارات بسيطة

الدين التقني هو الفجوة بين التطبيق الذي لديكم وتطبيق يمكنكم مواصلة تطويره بثقة. ويتراكم بطريقتين:

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

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

خمس علامات على أن وقت تحديث تطبيقكم قد حان

1. كل شيء يزداد بطئاً

الشاشات بطيئة التحميل، وعمليات التصدير لا تنتهي، والتطبيق يتجمد في أوقات الذروة. فتنتظر فرقكم، أو تلتف على الأداة بجداول البيانات.

2. التحديثات الأمنية لم تعد ممكنة

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

3. كل تعديل مصدر قلق

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

4. كل شيء يتوقف على شخص واحد

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

5. التقنية تقادمت

برنامج Windows من حقبة أخرى، أو قاعدة بيانات Access، أو تطبيق ويب صُمم لمتصفحات قديمة: المشكلة لا تقتصر على المظهر.

• المطورون الذين يتقنون هذه التقنية يزدادون ندرة.
• لا يستطيع التطبيق الاتصال بأدواتكم الجديدة، لأنه لا يملك واجهة برمجية (API).
• يعلن مزود الاستضافة لديكم انتهاء دعم النسخة التي تستخدمونها.

علامة واحدة من هذه العلامات لا تبرر بالضرورة إعادة البناء. لكن اجتماع عدة علامات يغيّر السؤال: لم يعد السؤال «هل يجب التحديث؟» بل «كيف؟».

تكلفة الجمود

يبدو عدم فعل أي شيء خياراً اقتصادياً. لكن للانتظار تكلفة، كل ما في الأمر أنها أقل ظهوراً من عرض سعر:

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

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

إعادة الهيكلة، أو إعادة الكتابة على مراحل، أو الاستبدال

هناك ثلاث طرق رئيسية لتقليص الدين التقني، ويمكن الجمع بينها، جزءاً جزءاً. باختصار:

• التقنية لا تزال مدعومة والشيفرة لا تزال مفهومة: أعيدوا الهيكلة.
• التقنية متقادمة، لكن قواعد عملكم هي ما يميزكم: أعيدوا الكتابة على مراحل.
• احتياجاتكم أصبحت قياسية: انظروا في البرامج الجاهزة.

إعادة الهيكلة: التنظيف دون تغيير كل شيء

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

إعادة الكتابة على مراحل: إعادة البناء وحدةً وحدة

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

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

الاستبدال: عندما يكون البرنامج الجاهز أفضل

قد يلبي تطبيقكم حاجة أصبحت قياسية. وعندئذ يمكن لبرنامج جاهز أن يحل محله، بشرط ترحيل البيانات بشكل سليم وتكييف بعض العادات. نتناول هذا الاختيار بالتفصيل في البرمجيات الجاهزة أم المخصصة: كيف تختارون دون ندم.

ما يجب تجنبه: «الانفجار الكبير»

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

تقييم ذاتي: هل يحتاج تطبيقكم إلى إعادة بناء؟

ضعوا علامة على العبارات التي تصف وضعكم:

1. جزء من الأساس التقني (اللغة، أو المكونات، أو النظام) لم يعد يتلقى تحديثات أمنية.
2. تُترك التحديثات المتاحة معلقة، خوفاً من تعطيل كل شيء.
3. شخص واحد فقط يعرف حقاً كيف يعمل التطبيق.
4. لا توجد اختبارات آلية، أو تكاد لا توجد.
5. تُنفَّذ الإصدارات يدوياً، وهي مصدر قلق.
6. يشتكي المستخدمون بانتظام من البطء.
7. تلتف فرقكم على الأداة بجداول البيانات أو بإعادة الإدخال.
8. لا يستطيع التطبيق تبادل البيانات مع أدواتكم الأخرى.

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

الأسئلة الشائعة

كيف يُقاس الدين التقني؟

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

إعادة البناء أم التحديث: ما الفرق؟

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

كيف تمنعون الدين التقني من العودة؟

بتخصيص حيز لسداده في كل دورة عمل: تحديث المكونات بانتظام، وأتمتة الاختبارات وعمليات النشر، وتحديث التوثيق أولاً بأول. وفي Orange Business Services، شارك مؤسسنا في هذا النوع من أعمال الأتمتة، مع تكامل مستمر قائم على Jenkins و SonarQube. كما تمنع الصيانة المستمرة، عبر اشتراك شهري مثلاً، تراكم التحديثات المتأخرة.

باختصار

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

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