رد فعل تجربة تطوير اختبار ل Aviasales

مرحبًا ، أردت مشاركة تجربتي في تطوير حالة اختبار لـ Aviasales.

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

يمكنك العثور على مهمة الاختبار هنا على الرابط .

هنا رابط إلى مستودع المهمة المكتملة.

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

ما اخترته للتنمية:

1. لقد اخترت NextJS كأساس ، لأنني لا أريد العبث بإعداد بيئة Webpack ، ويمكنك نشر المشروع نفسه ببضع نقرات.
2. أردت أن أكتب بسرعة واخترت حزمة React-IOC بالتزامن مع MobX ، بدلاً من Redux. هذه حزمة تسمح لك بكتابة التطبيقات من خلال الخدمات التي تشبه الخدمات الزاوية.
3. لقد استخدمت Web Worker بحيث لم يكن هناك أي تأخير في الواجهة أثناء فرز كمية كبيرة من البيانات.
4. لم أستخدم Typescript لغرض عدم كتابة تعليمة برمجية إضافية مع مضيعة للوقت غير مجدية في مهمة اختبار.
5. استنادا إلى الفقرة 4 ، أنا أيضا لم أكتب الاختبارات.
6. أضفت حزمتين إضافيتين للمشروع: debounce، RxJS. الأول مطلوب لإنشاء عمليات رد اتصال بسيطة ، على سبيل المثال ، تغيير حالة التنزيل بحيث لا يُظهر الدوار زيادة التحميل إذا استغرق التنزيل وقتًا قصير جدًا. أستخدم دائمًا الحزمة الثانية لإنشاء برنامج نصي للعمل ، على سبيل المثال ، لمعالجة الحالات في حالة حدوث خطأ عند إرسال طلب إلى الخادم.

إجراءات المرحلة الأولى من التطوير:

1. مستودع تهيئة.
2. تهيئة مشروع NextJS.
3. تمت إضافة صفحة قاعدة فهرس مع رسالة Hello World.
4. إنشاء خدمة ticket.provider التي تتفاعل مع خادم api.
5. إنشاء خدمة التذاكر. خدمة ، والتي تحقن تذكرة. تقديم وملء المراقب مع مجموعة من التذاكر المعروضة
6. تم إنشاء ticket.filter.service ، الذي يخزن البيانات المفلترة التي تم حقنها من ticket.service عبرcomputed

المرحلة الثانية من التطوير:

1. إنشاء مكونات وأنماط مطلية لهم باستخدام التخطيط المقدم في مستودع المهمة.
2. لقد أدخلت غزل من التنزيل ونزلت قيمتها عن الخدمات.
3. توصيل كل منطق الخدمة مع المكونات.
4. الأدوات المساعدة المضافة مع تنسيق البيانات ، مثل الوقت والمال.

ثم قررت تجربة واجهة "touch" ووجدت عيوبًا عند استخدام التطبيق:

1. هناك تباطؤ في الواجهة عند تغيير التصفية والفرز ، لذا قمت بنقل تخزين البيانات واستعادتها وتصفيتها إلى Web Worker ، وبعد ذلك اختفت التأخيرات تمامًا.
2. لم يصلح سبينر الرسوم المتحركة لخط القفز ، لذلك استبدلتها بعرض مرئي لخطوط الرسوم المتحركة الخفقان.
3. لسهولة تقديم البيانات ، قمت بنقل مكالمات تنسيق البيانات إلى Web Worker ، مما يقلل من الحمل على تقديم المكون

ثم أنهيت عملي وفي نهاية اليوم أرسلت مهمة للتحقق.

منذ أن حصرت نفسي في الوقت المناسب ، لم أقم بتحسين التطبيق أكثر ، أي أنني لم أستخدم React.memo (...). أنا أيضا لم تبدأ في استبدال نافذة وجهاز التوجيه عن طريق الحقن في الخدمات. سامحني على هذا ، هذا عيب.

لكن في اليوم التالي أضفت وظيفة تذكر حالة التصفية في خط رابط المتصفح ، وبعد ذلك كنت راضيًا بالفعل عن العمل المنجز.

انتظرت ردا منهم لمدة 7 أيام ، لم يردوا على أي من رسائلي. لقد كانت تجربة غير سارة ، إذا جاز التعبير. ولكن لا يزالون يجيبون ، وكانت الإجابة محزنة للغاية للقراءة. يمكن رؤية الرسالة أدناه.

دعنا نلقي نظرة على النقاط:

[1]. "تم العمل بعناية فائقة"

لا أرى مكانًا ، وليس حجة ، حيث لا توجد أمثلة.

[2]. "يبدو أن التطوير سعى إلى تحقيق أهداف" أنه يعمل "، وتجاهل" كيف يعمل ".

ليس حجة ، لا أمثلة.

[3]. "بناءً على متطلباتنا لمستويات المرشحين ، بالكاد تصل المهمة المكتملة إلى الوسط".

ما هي المتطلبات؟ اين هم؟

[4]. "نتوقع أن المرشحات لن تكون مشفرة ومتكيفة مع البيانات. إذا ذهبت إلى aviasales ، يمكنك أن ترى أن التذاكر معروضة فور ظهور الدفعة الأولى ، ونحن لا ننتظر تحميل الجميع. "

هذا الشرط لم يكن في المهمة المرفقة. وتطبيق Aviasales نفسه ، في رأيي ، لا يحتوي على واجهة مرجعية ، وقفز التذاكر ليس هو الحل الأفضل.

[5]. "لماذا يعرف filter.service عن جهاز التوجيه والنافذة؟ يجب ألا يتحكم في حالة التطبيق وله هذه التبعيات بشكل عام.

لأنه يتم إنشاء الخدمات للتحكم في حالة التطبيق بأكمله ، أو الوحدة النمطية حيث توجد. هنا يقترح المؤلف بوضوح كتابة كل المنطق في المكونات.

[6]. "عمال الويب. ما هو الربح؟ في هذه الحالة ، يتم إنفاق الكثير من الوقت على العمليات غير المتزامنة ، ويتم إنفاق الحمل المحفوظ في سلسلة الرسائل الرئيسية على إجراء تسلسل / إلغاء تسلسل الكائنات (والكائنات القابلة للرصد). إذا كنا نتحدث عن التحسينات ، فعندئذٍ كان الأمر يستحق البدء ليس مع الإزالة في عامل الويب ، ولكن إصلاح المشكلات في سلسلة الرسائل الرئيسية. "

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

[7]. "لا معنى لإضافة rxjs إلى المشروع فقط لإعادة المحاولة والتحميل المتسلسل."

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

[8]. "لا يمكن تحجيم المشروع وصيانته. (ticket.segments || [{}, {}]).map((ticket) => ...) مثل (ticket.segments || [{}, {}]).map((ticket) => ...) مرهقة للغاية. "

دعنا ticket.segments || [{}, {}] إلى معايير القياس والدعم: إمكانية الوصول (الخدمات تحل هذه المشكلة) ، والمخاطر ( ticket.segments || [{}, {}] هي مجرد مثال على كيفية التعامل مع الحالات إذا كان الإدخال لا يحتوي على بيانات. مثال سيء ، ولكن نهج بنية لاغية على الأقل ، ولكن أحاول الامتثال) ، رمز نظيف (حسنا ، على الأقل أعرف ما هو عليه :) ، على الرغم من أنني حاولت أن أكتب كل شيء كما ينبغي). يبدو أن كل شيء يتم التقاطه ، مرة أخرى ليس حجة.

[9]. لدي انطباع بأنه لا يوجد أي تفهم مطلقًا لكيفية عمل React تحت الغطاء. هناك العديد من الأخطاء الحرجة في العمل مع الدعائم للمكونات التي لها تأثير سيء للغاية على الأداء. يتم تجاهل آليات تحسين رد فعل ".

لا أستطيع أن أفهم مكان هذه المشاكل الموصوفة. أي نوع من الآليات؟

[10]. "إنشاء وظائف المعالج داخل تجسيد."

ليس لدي أي وظائف معالج في تقديمها على الإطلاق ، هل يفهم أي شخص ما هو مكتوب هنا؟ لقد قمت بنقل معالجة التنسيق إلى Web Worker

[11]. "إنشاء كائن فارغ جديد ونقله إلى التذكرة. ticket-list-loading.jsx:10 أو Ticket.tsx:24 "

لا يوجد شيء حرج هنا ، باستثناء كسلتي لإخراج مكون بطاقة التحميل بشكل منفصل. تمرير كائن فارغ لا ينتهك أي مبدأ برمجة ، إلا أنه هنا كان من الضروري القيام بذلك من خلال ticket = ticket || {}; ticket = ticket || {}; ولكن هذا يرجع فقط إلى حقيقة أن وقت التطوير اقتصر على يوم واحد وسوف يستغرق المزيد من الوقت لإصلاح جميع العيوب الطفيفة.

[12]. "مؤشرات الصفيف كمفاتيح في قائمة التذاكر"

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

وأخيرا ، الاستنتاج: "بشكل عام ، لم تنجح React (
إجمالي: بالنسبة للمستوى المتوسط ​​، نتوقع أنه لن تكون هناك مشاكل حرجة في رد الفعل ، ولكن هناك الكثير منهم في العمل المنجز ".

لا يوجد بالفعل أي تعليقات ...

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

النص الكامل للرسالة:

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

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

علاوة على ذلك ، المزيد من النقاط الفنية.

1. لماذا تعرف filter.service عن جهاز التوجيه والنافذة؟ لا ينبغي أن تتحكم في حالة التطبيق ولها مثل هذه التبعيات على الإطلاق.
2. عمال الويب. ما هو الربح؟ في هذه الحالة ، يتم إنفاق الكثير من الوقت على العمليات غير المتزامنة ، ويتم إنفاق الحمل المحفوظ في سلسلة الرسائل الرئيسية على إجراء تسلسل / إلغاء تسلسل الكائنات (والكائنات القابلة للرصد). إذا كنا نتحدث عن التحسينات ، فعندئذٍ كان الأمر يستحق البدء ليس مع الإزالة في عامل الويب ، ولكن إصلاح المشكلات في سلسلة الرسائل الرئيسية.
3. لا معنى لإضافة rxjs إلى المشروع فقط من أجل تنفيذ إعادة المحاولة والتحميل المتسلسل.
4. لا يمكن تحجيم المشروع وصيانته. ticket.segments || [{}, {}]).map((ticket) => ticket مثل ( ticket.segments || [{}, {}]).map((ticket) => ticket ) مرهقة للغاية.
   الرد:
   لدي انطباع بأنه لا يوجد أي تفهم مطلقًا لكيفية عمل React تحت الغطاء. هناك العديد من الأخطاء الحرجة في العمل مع الدعائم للمكونات التي لها تأثير سيء للغاية على الأداء. يتم تجاهل آليات تحسين رد الفعل. باختصار عن المشاكل:
5. إنشاء وظائف معالج داخل تقديم.
6. قم بإنشاء كائن فارغ جديد ونقله إلى التذكرة. ticket-list-loading.jsx:10 أو Ticket.tsx:24 .
7. صفيف المؤشرات كمفاتيح في قائمة التذاكر.
   بشكل عام ، لم يعمل React :(

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