كيفية توظيف المطورين الزاويين: المهارات الأساسية والمعرفة التي يجب البحث عنها

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

إن فهم المفاهيم الأساسية حول إطار عمل الواجهة الأمامية الشهير لـ Google سيعدك لمقابلة العملاء المحتملين بثقة وتوظيف أفضل المطورين - أولئك الذين يسعون جاهدين لجلب قاعدة بيانات إلى المستوى التالي. توضح هذه المقالة المهارات والمعرفة الأساسية التي يجب أن يتمتع بها محترف Angular المتميز.

ملاحظة: ينطبق هذا الدليل على أحدث إصدارات Angular ، والتي لم تعد تُعرف باسم AngularJS - تم تطبيق "Angular" منذ Angular 2. إذا كنت تقوم بالتوظيف لصيانة أو ترقية مشروع تطبيق الويب AngularJS القديم (1.x الفرع) ، تحقق من كيفية توظيف مطور AngularJS العظيم.

تعرف على الوظائف الأساسية للزاوية

يعمل إطار العمل Angular على TypeScript ، ويتم تحويل جميع التعليمات البرمجية المكتوبة داخل التطبيق إلى JavaScript. TypeScript هو مجموعة شاملة من JavaScript يتم تجميعها إلى JavaScript عادي. يتم تمثيل الرمز الزاوي من خلال هذه المجموعة الشاملة.

يتعلم الكثير من المطورين Angular لكنهم يفتقرون إلى فهم جيد للمفاهيم الأساسية التي تتطلبها JavaScript أو TypeScript أو HTML أو CSS. إذا كانت هذه الأسس مفقودة ، يكون المطورون على استعداد لاستخدام الحلول غير المناسبة وبالتالي مضاعفة الدين الفني للمشروع.

لذا ، اسأل المرشح عما إذا كان لديه معرفة بـ HTML5 و CSS3. لا يحتاج مطور Angular الجيد إلى أن يكون خبيرًا في HTML أو CSS طالما كان هناك شخص آخر في الفريق ، ولكن يجب أن يفهموا هذه المفاهيم الأساسية:

• فليكس بوكس
• متغيرات SCSS
• الفرق بين span و div
• الفئات المهمة في CSS
• صفات

يجب أن يتمتع المطورون الزاويون بفهم قوي لـ JavaScript و TypeScript ، بالإضافة إلى بعض مهارات HTML و CSS.

سقسقة

التصميم قبل البرمجة

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

• أين سيذهب الرمز؟ هل هناك حاجة لمكتبة جديدة أو وحدة نمطية؟
• ما هي المدخلات والمخرجات؟
• هل يجب أن تكون هناك أية مكونات أو توجيهات قابلة لإعادة الاستخدام؟
• أين ستذهب الدولة؟ (تمت مناقشته بمزيد من التفصيل تحت إدارة الدولة أدناه.)
• أين سيذهب منطق الأعمال — أي في أي خدمة؟
• هل يمكن مشاركة مكونات معينة بين المكتبات لإنشاء نظام تصميم واجهة المستخدم بشكل أساسي؟

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

فهم دورات حياة التطبيق الزاوي

اسأل مرشحك عما يعرفه عن دورة حياة المكون الزاوي . يجب أن تتضمن إجابتهم ثلاثة خطاطيف لدورة الحياة: ngOnInit و ngOnChanges و ngOnDestroy . كما توحي الأسماء ، يتم استدعاء ngOnInit عند تهيئة المكون ، ويتم استدعاء ngOnDestroy عند إتلاف المكون ، ويتم استدعاء ngOnChanges عند تغيير السمة. يمكن أن يحدث الأخير قبل ngOnInit - عندما يتم تعيين السمة بالفعل قبل تهيئة المكون بالكامل ، يتم تنفيذ ngOnChanges قبل ngOnInit .

إذا كان المرشح يعرف أيضًا عن ngDoCheck و ngAfterContentInit و ngAfterContentChecked و ngAfterViewInit و ngAfterViewChecked ، فإنهم يعرفون جميع خطاطيف اكتشاف التغييرات للمكونات وهم خطوة للأمام.

سؤال متابعة جيد لطرحه حول أي من الخطافات: "متى يتم اكتشاف هذا التغيير؟"

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

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

معرفة قوية بالبرمجة التفاعلية

في تطبيق Angular ، غالبًا ما تكون البرمجة التفاعلية هي أصعب جزء يمكن فهمه. يفكر الكثير من الناس بطريقة إجرائية عندما يبدأون في برمجة جزء من التعليمات البرمجية ، بافتراض أنه من الأسهل فهمها والعمل معها ، مثل خطوات الوصفة.

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

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

• عندما يقوم المستخدم بتسجيل الدخول ، يتم تحديث الرقم الموجود على أيقونة عربة التسوق ، وتتغير عناصر القائمة إلى خيارات أكثر تحديدًا.
• عندما ينتقل المستخدم إلى فئة ، يتم تحديث المنتجات وفقًا للفئة المحددة.
• عندما يضيف المستخدم منتجًا إلى سلة التسوق الخاصة به ، يتم تحديث رمز عربة التسوق بعدد المنتجات.
• عندما يكون أحد العناصر غير متوفر في المخزون (يتم تسجيله من خلال مستمع يراقب كميات المخزون الحالية من النهاية الخلفية) ، يتم تحديث واجهة مستخدم الصفحة.

لاحظ أن هذه الأشياء تحدث تلقائيًا ، ولا تحتاج إلى تحديث الصفحة لتظهر. في مقابلة ، اطلب من المرشح أن يصف كيف طبقوا البرمجة التفاعلية في تطبيق قاموا بتطويره. إذا كان المرشح يصف الحلول التي تتضمن تحديث الصفحة أو استدعاء ChangeDetectorRef.detectChanges() يدويًا لتحديث أحد المكونات ، ضع في اعتبارك هذه العلامة الصفراء.

المزالق مع المرصدات في الزاوية

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

توجد طريقتان لإنشاء الاشتراكات: يمكن للمطورين استخدام مسار غير async أو طريقة subscribe . ولكن هناك تحذير: إذا أجرى المطورون اشتراكًا يدويًا (باستخدام طريقة subscribe ) ، فسيلزم إتلاف Observable يدويًا (على الرغم من وجود بعض حالات الحافة التي يحدث فيها افتراضيًا). يمكن للمطورين تدمير Observables بعدة طرق:

• استخدام الأنبوب غير async ، حيثما أمكن ذلك (يؤدي ذلك إلى إتلاف Observable عندما لا تكون هناك حاجة إلى المكون).
• إلغاء الاشتراك يدويًا باستخدام طريقة unsubscribe في ngOnDestroy Observable .
• بطريقة أكثر تفصيلاً باستخدام عامل التشغيل takeUntil داخل مشغل pipe ، وباستخدام موضوع (أي شيء يسمى destroy$ ). في هذه الحالة ، يرسل الموضوع destroy$.next() في نهاية عمر المكون ( ngOnDestroy ). بعد تلقي حدث التدمير ، لن يقبل عامل التشغيل takeUntil الأحداث من المرصد المرتبط به حتى لا يتم تشغيل منطق المشترك الخاص به. للحصول على مثال ، راجع عامل التشغيل takeUntil في القسم 2. يمكن الكشف عن وظائف مماثلة باستخدام عوامل التشغيل take and takeWhile .
• منذ أن تحولت التطبيقات Angular إلى مترجم Ivy ، يمكننا أيضًا استخدام التعليقات التوضيحية. يمكن استخدام المكتبة until-destroy أو مكتبة أخرى تابعة لجهة خارجية مثل SubSink لإلغاء الاشتراك بسلاسة من العناصر التي يمكن ملاحظتها بمجرد تدمير أحد المكونات.

تأتي نقطة الألم المحتملة الأخرى مع البرمجة التفاعلية من تسرب الذاكرة والمكالمات المتعددة إلى النهاية الخلفية. اسأل المرشح عما إذا كان على دراية بهذه المشكلات ، وكيف يمكنه حلها بشكل طبيعي. يمكن أن يحدث تسرب في الذاكرة من خلال الفشل في إلغاء الاشتراك من Observable s كما هو موضح أعلاه. يمكن حل المكالمات المتعددة إلى النهاية الخلفية بسبب الاشتراكات المتعددة في مكالمة خلفية من خلال مشاركة Observable .

تعرف على الدولة وكيفية استخدامها

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

في تطبيق Angular ، هناك ثلاثة أنواع رئيسية من حالة الواجهة الأمامية يجب مراعاتها:

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

• ابحث عن استخدام NgRx أو Akita أو NgXs أو مكتبات أخرى خاصة بإدارة الدولة.
• ثم انظر لمعرفة ما إذا كانت هناك أي إعلامات effects ، action ، reducer ، store ، selector في الكود ذي الصلة.

دعنا نلقي نظرة على التدفق العام لحالة التطبيق في NgRx (وهو مشابه لحالة Akita والمكتبات الأخرى) كمثال:

إذا قام المطور بإنشاء دولته الخاصة مع الخدمات ، فقد يكون من الصعب تحديد كفاءته في إدارة الحالة:

• ابحث عن مراجع للكلمات state أو effect .
• تحقق مما إذا كان الرمز يتفاعل مع بعض الإجراءات ، على سبيل المثال ، إذا ضغط المستخدم على الزر A ، فيجب تغيير النص على الشاشة B.

أسئلة للمحاورين لطرحها على الدولة

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

• أين استخدمت state - وكيف؟ هذه نقطة انطلاق قوية لفهم تجربتهم مع الدولة ؛ لا تخف من التحقيق في التفاصيل.
• كيف تتخذ قرارًا باستخدام المكتبة أم لا؟ إنها علامة جيدة إذا كانوا يعرفون أنه ليس من المفيد دائمًا تضمين مكتبة حالة في أحد التطبيقات.
• ما الذي ستضعه داخل الدولة ، وأين تضعه ، وكيف تستفيد من نظام إدارة الدولة؟ إذا قالوا ، "لقد وضعت كل شيء في حالة التطبيق العالمية الخاصة بي" ، فهذه علامة أكيدة على أن المطور ليس على دراية بالآثار الجانبية السلبية التي يمكن أن يقدمها مثل هذا النظام للتطبيق.

سيتجنب المطورون الذين يفهمون أنواع الحالات المختلفة هذه الآثار الجانبية:

• الحالة التي تنطبق على مكون واحد فقط يمكن أن يتم تعديلها أو إتلافها بواسطة مكونات أخرى.
• يتم تضمين البيانات في المتجر ، لذلك يصعب تتبع البيانات ، وتصبح البيانات غير قابلة للقراءة البشرية (لأغراض التصحيح ، وتبادل البيانات ، وما إلى ذلك).
• تحرير البيانات داخل نموذج يرسلها بالفعل إلى بقية التطبيق ، بينما يجب دفعها فقط إلى المتجر عند حفظ البيانات - بمعنى آخر ، قد يستهلك باقي التطبيق بيانات غير صالحة.

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

فهم أهمية الاختبار الآلي

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

اطرح ثلاثة أسئلة اختبار على مطور Angular المحتمل:

• ما هي أفكارك حول الاختبار؟ يجب التوقف عن النظر في أي مرشح لا يهتم بالاختبار الآلي. حتى إذا كانوا يفضلون عدم استخدام التطوير القائم على الاختبار (TDD) ، فإن المطورين الذين يفشلون في رؤية قيمة الاختبار الآلي سيكلفون شركتك وقت الاختبار اليدوي ، والأسوأ من ذلك ، توقف المستخدم النهائي عندما تظهر الانحدارات مع إجراء تغييرات على أحد التطبيقات متأخر , بعد فوات الوقت.
• على ماذا تركز عند الاختبار؟ بدلاً من اختبار المعطيات الأساسية مثل القدرة على تعيين قيم لحقل ما أو السعي للحصول على مقاييس تغطية اختبار محددة (أي تغطية بنسبة 85٪) ، يجب على مطور Angular الرائع التركيز على اختبار منطق الأعمال الأساسي.
• هل يوجد عادة المزيد من اختبارات E2E أو المزيد من اختبارات الوحدة؟ لماذا ا؟ كتطبيقات أمامية ، يمكن للتطبيقات Angular الاستفادة من نوعين رئيسيين من الاختبارات الآلية: اختبارات الوحدة والاختبارات الشاملة (E2E). عادةً ما تحتوي مجموعة الاختبار على العديد من اختبارات الوحدة وعدد أقل من اختبارات E2E. اختبارات الوحدة صغيرة ، لذا فهي سريعة في الكتابة والتنفيذ. اختبارات E2E أكبر وأبطأ. تحذير عادل: لن يكون لدى جميع المطورين نفس الرأي فيما يتعلق بالنسبة الصحيحة لاختبارات الوحدة و E2E للحفاظ عليها. في الواقع ، يعتمد الأمر على مدى تعقيد التطبيق الذي يتم اختباره ، وحتى ذلك الحين ، فإن الإجابة قابلة للنقاش إلى حد ما.

أطر الاختبار الزاوي

لدى المطورين الزاويون خيارات عندما يتعلق الأمر بأطر عمل الاختبار الآلي. يمكن إجراء اختبار الوحدة من خلال Jest أو Jasmine و Karma. يجب أن يكون كل مطور Angular على دراية بـ Jasmine و Karma. تعد Jest أيضًا شائعة - فهي أسرع بشكل عام وتتميز بخيارات اختبار أكثر تقدمًا.

معيار اختبار E2E لتطبيق Angular هو منقلة ، الأداة الافتراضية التي تم إنشاؤها بواسطة Angular CLI. البديل هو Cypress ، وهو إطار واعد لاختبار E2E مع الكثير من الخيارات.

تأكد من أن المرشح لديه معرفة عميقة بإطار عمل اختبار وحدة واحد على الأقل وإطار اختبار E2E واحد.

البقاء على اطلاع بأحدث الإصدارات الزاويّة

قد لا يستخدم مطورو Great Angular دائمًا أحدث إصدار قيد التطوير لأسباب مختلفة ، ولكن يجب أن يعرفوا جدول إصدار Angular حتى يتمكنوا من مواكبة التغييرات والاستعداد للتبديل. تتمثل إحدى طرق تقييم ذلك في سؤال المرشح عما إذا كان على دراية باستراتيجية إطلاق Angular. يهدف Angular إلى إصدار كبير كل ستة أشهر ، عادةً في حوالي فبراير ومايو. إصدار Angular يخضع لـ "الدعم النشط" خلال الأشهر الستة الأولى بعد تاريخ إصداره ، ويخضع لـ "دعم طويل الأجل" لمدة 12 شهرًا بعد تاريخ إصداره. هذا جدول زمني ضيق إلى حد ما مقارنة ببعض التقنيات الأخرى ، مما يجعل من المهم بشكل خاص مواكبة التطورات.

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

• المكونات المستقلة ، والتي تقلل من الحاجة إلى الوحدات الزاويّة. لم يتم التصريح عن المكونات المستقلة في أي NgModule موجودة ، وتقوم بإدارة التبعيات الخاصة بها بشكل مباشر. نتيجة لذلك ، يمكن الاعتماد عليها مباشرة دون الحاجة إلى NgModule وسيطة.
• النماذج المطبوعة ، تحديث رئيسي آخر في Angular 14 ، والذي يحدد الكتابة الصارمة كخيار افتراضي للنماذج Angular Reactive Forms. تضمن النماذج المكتوبة أن القيم الموجودة داخل FormControls و FormGroups و FormArrays آمنة من النوع عبر سطح واجهة برمجة التطبيقات بالكامل. يتيح ذلك نماذج أكثر أمانًا ، خاصةً للحالات المعقدة المتداخلة بعمق.

المطور الزاوي العظيم التالي لفريق الواجهة الأمامية

يختلف كل مشروع وفريق لتطوير الويب وسيضع أهمية مختلفة على الجوانب المختلفة لمهارات ومعرفة مطور Angular. لكن فهم الموضوعات التأسيسية التي قدمناها هنا سيسمح لمديري التوظيف بالمشاركة بشكل هادف في التوظيف - حتى في التقييمات الأكثر تقنية.

تتقدم مدونة Toptal Engineering بامتنانها إلى Ramazan Yildiz لمراجعة المفاهيم الفنية والرسوم البيانية الواردة في هذه المقالة.