عبدالله بن سنكر: الديون التقنية، متى تصلّح الكود ومتى تعيد كتابته؟

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

وش هو الدين التقني بالضبط؟

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

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

علامات إن الدين صار يأكل منك

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

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

ليش إعادة الكتابة أخطر مما تتوقع

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

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

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

إطار القرار: خمسة أسئلة

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

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

الطريق الوسط اللي ينجح غالباً

بين الترقيع وإعادة الكتابة فيه نمط سمّاه Martin Fowler «التينة الخانقة» (Strangler Fig): تبني الأجزاء الجديدة بجانب النظام القديم، وتحوّل لها الطلبات جزءاً جزءاً — شاشة الدفع أولاً، بعدها التقارير، بعدها إدارة المستخدمين — لين يفضى القديم فتطفيه. النظام يبقى شغّالاً طول الوقت، وكل خطوة لها قيمة مستقلة، ولو توقفت في النص ما خسرت كل شي.

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

الدين التقني قرار مالي قبل ما يكون تقنياً. السؤال مو «هل الكود جميل؟»، السؤال «كم يكلّفنا هذا الكود كل شهر، وكم يكلّف إصلاحه؟». لما تحسبها بهذي الطريقة، القرار غالباً يوضح بنفسه.