تحديث المنتجات القائمة

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

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

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

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

ونعطي الترحيلات عناية خاصة: تغييرات المخطط تُنفَّذ بخطوات قابلة للتراجع مع مسار رجوع مُتحقَّق منه، وتُدقَّق البيانات قبل إزالة المسار القديم. فعلنا هذا في منتجنا نفسه، بترحيل Kevta من MongoDB إلى PostgreSQL خلف واجهة برمجية لم تتغيّر.

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