تحديث الواجهة الأمامية القديمة
لا TypeScript. لا linter. لا Sentry. ويستخدمه 170 موقعًا يوميًا.
تحديث واجهة أمامية قديمة غير محددة الأنواع وغير مراقبة تدريجيًا مع إبقاء المنتج متاحًا للمستخدمين الحاليين.
قراءة في 5 دقائقبقلم Abdullah Raheel
كانت القيود الموروثة حقيقية
كانت واجهة CRA الموروثة مكتوبة بلغة JavaScript عادية من دون TypeScript أو ESLint أو Prettier أو Sentry أو نظام مكونات قابل لإعادة الاستخدام أو بنية ميزات متسقة. وضمت أكثر من 5,000 سطر من CSS الخام، وفئات Tailwind تتجاوزها أنماط مضمنة، وصفحات منسوخة، وبنية مجلدات مسطحة.
عززت المشكلات بعضها بعضًا. وصلت تغييرات API إلى المتصفح من دون ملاحظات المترجم. وكررت الشاشات المنسوخة أخطاء التنسيق نفسها. وغالبًا لم تصل أخطاء الإنتاج إلا على هيئة بلاغات مستخدمين لغياب مسار رصد.
وصلت تكلفة الصيانة إلى المستخدمين
ظل التطبيق يخدم 170 موقعًا للعملاء يوميًا. لم نحوّل V1 في مكانه ولم ننتظر بديلًا مكتملًا. أبقينا المسارات القديمة تعمل، واشترطنا أن يلتزم كل مسار V2 جديد بالمعايير الجديدة.
أعطى ذلك الفريق قاعدة بسيطة: لا توسع الأعراف القديمة. انقل الملكية عندما يُعاد بناء مسار، ثم أزل المسار القديم بعد تشغيل الجديد في الإنتاج.
إنشاء حد محدد الأنواع
شكّل Next.js 15 وTypeScript الحد الجديد. استخدمت المسارات الجديدة تعريفات مسار محددة الأنواع، وعملاء API مولدين، وسلوك جلب مشتركًا، ومكونات تملكها الميزات. لم يحوّل الفريق كل ملف قديم أولًا؛ بل توقف عن إضافة أسطح جديدة غير محددة الأنواع، ونقل الملكية إلى V2 عندما وصل العمل إلى كل مسار.
- جعل TypeScript والمسارات محددة الأنواع أخطاء التنقل وشكل API ظاهرة أثناء التطوير.
- حل العملاء المولدون وسلوك الجلب المشترك محل أعراف الطلبات المتناثرة.
- جعلت مجلدات الميزات ملكية المسارات والخطافات والمخططات والاختبارات واضحة.
- حلت العناصر الأولية القابلة لإعادة الاستخدام محل النسخ على مستوى الصفحة لأنماط التفاعل المتكررة.
إضافة حلقات ملاحظات قبل نقل كل شاشة
غيّر التحديث أيضًا طريقة اكتشاف الأعطال وقبول التغييرات. أضاف Sentry تقارير العميل والخادم والحافة وحدود أخطاء التطبيق. وحصلت سير عمل الوحدات والمتصفح على بوابات مطلوبة صريحة، بينما غطت الاختبارات المركزة على السلوك تدفقات عالية المخاطر مثل Investor Intake.
لم تصلح هذه الضوابط V1 تلقائيًا، لكنها جعلت كل مسار V2 قابلًا للرصد والاختبار قبل أن يرث مسؤوليات إنتاجية إضافية.
ابنِ حدود النظام الجديد حول المنتج القديم
تولى V2 الإطار العام والمصادقة وكل ميزة جرى ترحيلها حديثًا. وبقي CRA داخل iframe واحد للمسارات التي ظل يملكها فقط. يغطي مقال الترحيل المصاحب جسر postMessage وSSO والتوجيه بالتفصيل.
النقطة المهمة في هذا المقال هي الملكية: طُبقت المعايير الجديدة عند حد V2، وقلل كل ترحيل مكتمل مقدار الشفرة المستثناة منها.
اجعل الملكية مرئية أثناء الانتقال
تُتبعت الملكية بوضوح أثناء الانتقال. انتقلت Navbar وTopbar وSettings وInvestor Intake وAuthentication وTwilio إلى V2. وبقيت Home وGenius Mode وDeals وBuyers في V1 حتى جهزت بدائلها. انتقلت مواقع العملاء في مجموعات مضبوطة بدل تلقي كل سطح غير مكتمل دفعة واحدة.
منع ذلك الحصر إعادة الكتابة من التحول إلى مشروع موازٍ غير محدد. كانت الميزة إما مملوكة لـ V1، أو مخدومة عبر حد التوافق، أو أصلية في V2.
التحديث سلسلة خطوات، لا حدث واحد
أزال الانتقال النهائي iframe والعملاء المولدين القدامى وشفرة الجسر، ثم نظف المسارات والاختبارات وحراس المصادقة ومشاركة برنامج الاتصال وبنية المكونات. لم يكتمل التحديث إلا عندما أمكن حذف الحد المؤقت.
- لا تقس التقدم بعدد ملفات إطار العمل المنشأة حديثًا.
- قس مسؤوليات الإنتاج التي انتقلت ومسارات التوافق التي يمكن إزالتها.
- أبقِ الشفرة الجديدة داخل المعايير الجديدة بدل انتظار تحويل مثالي لقاعدة الشفرة كلها.
- احذف بنية الترحيل المؤقتة بعد انتقال آخر سطح يعتمد عليها.

