DeHubافتح DeHub

DeHub › المدونة

بناء للجميع: إعادة بناء التطبيق باستخدام React Native

بقلم DeHub Team — 2021-07-02

DeHub Q3 2021 update: Building for All: App Rebuild with React Native

في الربع الثالث من 2021 بدأنا بإعادة بناء تطبيق DeHub من الصفر باستخدام React Native.

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

ما المشكلة في التطبيق الأول

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

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

لماذا React Native

السبب الصادق هو نفوذ الفريق. سمحت React Native لمجموعة صغيرة بالشحن إلى iOS و Android من قاعدة تعليمات برمجية واحدة دون الانتقال إلى النسخة الأصلية بالكامل مرتين، ودون التنازل عن عرض الويب الملفوف — والذي كان من الممكن أن يكون قاتلاً بالنسبة لتطبيق مبني حول الفيديو والمحتوى المباشر.

وهذا يعني أيضًا أن تطبيق الهاتف المحمول وتطبيق الويب يمكنهما مشاركة نموذج عقلي ومفردات مكونة، وفي كثير من الحالات، المنطق الفعلي. بعد أربع سنوات، تدير DeHub تطبيق ويب React وتطبيق React Native للهاتف المحمول يتم الحفاظ عليهما بالتوازي، ويتميزان بالتقاطع بينهما بوتيرة لن تكون ممكنة إذا كانت الإجابة في عام 2021 هي إعادة كتابة أصليتين.

الأجزاء التي كانت أصعب من المتوقع

لا ينبغي لأحد أن يقرأ هذا كخيار خالٍ من الاحتكاك:

لماذا كان لا يزال صحيحًا

إعادة البناء هي السبب في نجاة التطبيق من كل ما حدث بعد ذلك. عندما تم إطلاق arcade في الربع الأول من عام 2022، عندما وصل تطبيق البث في ذلك الصيف، عندما تم سحب النظام البيئي بأكمله إلى تطبيق واحد في عام 2023 — لم يكن أي من تلك الحالات حالة من الاندفاع إلى الإصدار التجريبي. هبطوا على أساس بني عمدا لأخذ الوزن.

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

كيفية البقاء على قيد الحياة

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

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

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

جميع مقالات مدونة DeHub · الصفحة الرئيسية لـ dehub.io