Cum să angajați dezvoltatori angular: abilități și cunoștințe cheie de căutat

Cu arhitectura sa extrem de scalabilă, multe echipe de dezvoltare web aleg Angular pentru a crea aplicații eficiente și sofisticate pe o singură pagină. Dar, angajarea dezvoltatorilor Angular este mai ușor de spus decât de făcut. Deși există mulți candidați, cheia pentru o experiență de dezvoltare fără întreruperi este găsirea unui dezvoltator Angular grozav , unul care să aplice cele mai bune practici și tehnici avansate pentru a îndeplini standardele de codare de înaltă calitate.

Înțelegerea conceptelor cheie despre cadrul popular de front-end de la Google vă va pregăti pentru a intervieva cu încredere potențialii potențiali și a angaja dezvoltatori de cel mai înalt calibru - cei care se străduiesc să aducă o bază de cod la următorul nivel. Acest articol prezintă abilitățile și cunoștințele esențiale pe care ar trebui să le aibă un profesionist premium Angular.

Notă: Acest ghid se aplică celor mai recente versiuni Angular, care nu mai sunt cunoscute ca AngularJS — „Angular” s-a aplicat de la Angular 2. Dacă angajați pentru întreținerea sau actualizarea unui proiect de aplicație web AngularJS vechi (1.x sucursală), consultați Cum să angajați un dezvoltator AngularJS excelent.

Cunoașteți funcțiile de bază ale Angular

Cadrul Angular rulează pe TypeScript și tot codul scris în interiorul unei aplicații este transpilat în JavaScript. TypeScript este un superset de JavaScript care se compilează în JavaScript simplu. Codul unghiular este reprezentat de acest superset.

Mulți dezvoltatori învață Angular, dar nu au o bună înțelegere a conceptelor de bază care sunt cerute de JavaScript, TypeScript, HTML sau CSS. Dacă aceste fundații lipsesc, dezvoltatorii sunt predispuși să folosească soluții neadecvate și astfel să înmulțească datoria tehnică a unui proiect.

Așadar, întreabă-l pe candidat dacă are cunoștințe despre HTML5 și CSS3. Un dezvoltator Angular bun nu trebuie să fie un expert HTML sau CSS atâta timp cât este altcineva din echipă, dar ar trebui să înțeleagă aceste concepte cheie:

• Flexbox
• variabile SCSS
• Diferența dintre un span și un div
• Clasele importante în CSS
• Atribute

Dezvoltatorii angular ar trebui să aibă o înțelegere solidă a JavaScript și TypeScript, precum și unele abilități HTML și CSS.

Tweet

Proiectare înainte de codificare

Designul bun este cheia unei arhitecturi bune de aplicație. Întrebați-vă candidatul cum își realizează designul și comparați gândirea cu aceste considerații ideale:

• Unde va merge codul? Este nevoie de o nouă bibliotecă sau un modul?
• Care sunt intrările și ieșirile?
• Ar trebui să existe componente sau directive reutilizabile?
• Unde va merge statul? (Discutat în continuare la Managementul de stat de mai jos.)
• Unde va merge logica de afaceri, adică în ce serviciu?
• Pot fi partajate anumite componente între biblioteci pentru a crea, în esență, un sistem de design UI?

Specificul complet al unui anumit design este mai puțin important decât dacă candidatul are obiceiul de a realiza modele. Toate modelele sunt temporare, astfel încât, pentru majoritatea aplicațiilor, documentarea poate fi la fel de simplă ca o fotografie a unei schițe pe o tablă albă, cu excepția cazului în care este necesară o documentație oficială. Într-o etapă ulterioară, dezvoltatorul poate genera designul tehnic din cod (cu instrumentele potrivite) pentru a clarifica modul în care toate părțile se interacționează.

Înțelegerea ciclurilor de viață a aplicațiilor unghiulare

Întrebați-vă candidatul ce știu despre ciclul de viață al componentei Angular . Răspunsul lor ar trebui să includă trei cârlige ciclului de viață: ngOnInit , ngOnChanges și ngOnDestroy . După cum sugerează numele, ngOnInit este apelat la inițializarea componentei, ngOnDestroy este apelat atunci când componenta este distrusă și ngOnChanges este apelat când un atribut se modifică. Acesta din urmă poate apărea înainte de ngOnInit — când atributul este deja atribuit înainte ca componenta să fie complet inițializată, atunci ngOnChanges este executat înainte de ngOnInit .

Dacă candidatul știe și despre ngDoCheck , ngAfterContentInit , ngAfterContentChecked , ngAfterViewInit și ngAfterViewChecked , ei cunosc toate cârligele de detectare a modificărilor pentru componente și sunt cu un pas înainte.

O întrebare ulterioară bună de pus despre oricare dintre cârlige: „Când are loc detectarea schimbării?”

Un ciclu de viață mai puțin cunoscut este ciclul de viață al furnizorului , care are un singur cârlig: ngOnDestroy . Acesta este apelat numai atunci când furnizorul este atașat la nivel de componentă, caz în care este distrus împreună cu componenta. Dacă este furnizat la nivel de rădăcină sau modul, nu va fi niciodată distrus.

Constructorul unui furnizor va fi executat prima dată când furnizorul este utilizat, deci este posibil ca constructorul să nu fie executat niciodată. Interogați-vă candidatul cu privire la această posibilitate – în scenariile din lumea reală, poate fi o sursă de erori adesea trecută cu vederea!

Cunoștințe solide de programare reactivă

Într-o aplicație Angular, programarea reactivă este adesea partea cea mai greu de înțeles. Mulți oameni gândesc într-un mod procedural atunci când încep să programeze o bucată de cod, presupunând că este mai ușor de înțeles și de lucrat, la fel ca pașii unei rețete.

Programarea reactivă implică reacția la lucruri pe care nu le putem controla și care pot apărea într-o ordine imprevizibilă. Deși reacționăm la lucruri în acest fel în fiecare zi – de exemplu, frânarea când mașina din fața noastră se oprește brusc – pentru mulți dezvoltatori le este dificil să adopte o abordare reactivă a programării.

Dar, tot ceea ce se întâmplă în interiorul unei aplicații Angular se bazează pe programare reactivă. Câteva exemple de reactivitate într-o aplicație de cumpărături Angular, de exemplu, pot include:

• Când utilizatorul se conectează, numărul de pe pictograma coșului de cumpărături se actualizează, iar elementele de meniu se schimbă la opțiuni mai specifice.
• Când utilizatorul navighează la o categorie, produsele se actualizează în funcție de categoria selectată.
• Când utilizatorul adaugă un produs în coșul său, pictograma coșului de cumpărături se actualizează cu numărul de produse.
• Când un articol nu este în stoc (înregistrat printr-un ascultător care monitorizează cantitățile curente din stoc din back-end), interfața de utilizare a paginii se actualizează.

Rețineți că aceste lucruri se întâmplă automat și nu au nevoie de o reîmprospătare a paginii pentru a apărea. Într-un interviu, cereți candidatului să descrie modul în care a aplicat programarea reactivă într-o aplicație pe care a dezvoltat-o. Dacă candidatul descrie soluții care implică reîmprospătarea paginii sau apelarea manuală a ChangeDetectorRef.detectChanges() pentru a reîmprospăta o componentă, luați în considerare că este un steag galben.

Capcane cu observabile în unghiular

Dezvoltatorii mai puțin experimentați pot descoperi uneori că codul pe care îl scriu în aplicațiile lor Angular nu este executat. Dezvoltatorii experimentați Angular pot identifica o cauză comună: nu există niciun abonament pentru un Observable , un tip de obiect principal în programarea reactivă. Numai cu un abonament vor fi executate apeluri back-end sau alte reacții.

Există două moduri de a crea abonamente: Dezvoltatorii pot folosi conducta async sau metoda de subscribe . Dar există o avertizare: dacă dezvoltatorii fac un abonament manual (cu metoda de subscribe ), Observable va trebui să fie distrus manual (deși există unele cazuri marginale în care se întâmplă în mod implicit). Dezvoltatorii pot distruge Observables în mai multe moduri:

• Folosind conducta async , acolo unde este posibil (acest lucru distruge Observable atunci când componenta nu mai este necesară).
• Dezabonarea manuală utilizând metoda de unsubscribe pe un Observable la sfârșitul duratei de viață a componentei ( ngOnDestroy ).
• Într-un mod mai declarativ cu operatorul takeUntil în interiorul operatorului pipe și folosind un subiect (adică ceva numit destroy$ ). În acest caz, subiectul emite destroy$.next() la sfârșitul duratei de viață a componentei ( ngOnDestroy ). După primirea evenimentului de distrugere, operatorul takeUntil nu va mai accepta evenimente din Observable la care este legat, astfel încât logica de abonat să nu mai fie declanșată. Pentru un exemplu, consultați operatorul takeUntil din secțiunea 2. Funcționalități similare pot fi expuse cu operatorii take și takeWhile .
• Deoarece aplicațiile Angular au trecut la compilatorul Ivy, putem folosi și adnotări. Biblioteca until-destroy sau o altă bibliotecă terță parte precum SubSink poate fi folosită pentru a vă dezabona fără probleme de la observabile odată ce o componentă este distrusă.

Un alt punct de durere potențial cu programarea reactivă vine din scurgerile de memorie și apelurile multiple către back-end. Întrebați candidatul dacă este conștient de aceste probleme și cum le-ar rezolva în mod normal. Scurgerile de memorie pot apărea dacă nu vă dezabonați de la Observable așa cum este descris mai sus. Apelurile multiple către back-end din cauza abonamentelor multiple la un apel back-end pot fi rezolvate prin partajarea Observable .

Cunoașteți starea și cum să o utilizați

Toate aplicațiile cu o singură pagină au o stare, iar această stare este disponibilă undeva pe front-end. Dar ce este un stat, mai exact? Conține toate variabilele specifice experienței curente a utilizatorului. De exemplu, detalii autentificate ale utilizatorului, cum ar fi numele și adresa URL a imaginii de profil, un anumit element de meniu selectat sau o listă de pe ecran, cum ar fi o listă de articole din coșul de cumpărături.

Într-o aplicație Angular, există trei tipuri principale de stare front-end de luat în considerare:

O bună înțelegere a stării și când ar trebui să fie încărcată sau reîncărcată, este una dintre abilitățile cheie de căutat atunci când angajați dezvoltatori Angular. Acesta este un teritoriu principal de explorat dacă echipa dvs. are ocazia să revizuiască un exemplu de cod scris de candidat. Dacă solicitantul folosește o bibliotecă pentru administrarea statului:

• Căutați utilizarea NgRx, Akita, NgXs sau biblioteci similare specifice managementului de stat.
• Apoi, uitați-vă pentru a vedea dacă există notificări pentru effects , action , reducer , store și selector în codul aferent.

Să ne uităm la fluxul general al stării aplicației în NgRx (care este similar cu cel al Akita și al altor biblioteci) ca exemplu:

Dacă dezvoltatorul își creează propriul stat cu servicii, competența lor în managementul statului poate fi mai greu de identificat:

• Căutați referințe la cuvintele state sau effect .
• Vedeți dacă codul reacționează la o acțiune, de exemplu, dacă utilizatorul apasă butonul A, textul ar trebui să se schimbe pe ecranul B.

Întrebări pe care să le pună intervievatorii despre stat

Nu poți afla întotdeauna tot ce trebuie să știi investigând codul unui solicitant. Adăugați aceste interogări la lista de întrebări pentru a investiga cât de bine înțeleg potențialii dezvoltatori Angular starea:

• Unde ai folosit state — și cum? Acesta este un punct de plecare solid pentru a înțelege experiența lor cu statul; nu vă fie teamă să cercetați detalii.
• Cum iei decizia dacă folosești sau nu o bibliotecă? Este un semn bun dacă știu că nu este întotdeauna util să includă o bibliotecă de stat într-o aplicație.
• Ce ai pune în interiorul statului, unde l-ai pune și cum folosești un sistem de management al statului? Dacă spun: „Am pus totul în starea mea globală de aplicație”, acesta este un semn sigur că dezvoltatorul nu este conștient de efectele secundare negative pe care un astfel de sistem le poate produce unei aplicații.

Dezvoltatorii care înțeleg diferitele tipuri de stări vor evita aceste efecte secundare:

• Starea care se aplică doar unei componente ar putea fi modificată sau coruptă de alte componente.
• Datele sunt imbricate în magazin, așa că devine greu să ținem evidența datelor, iar datele devin imposibil de citit de om (în scopul depanării, schimbului de date etc.).
• Editarea datelor în interiorul unui formular le emite deja către restul aplicației, în timp ce acestea ar trebui să fie trimise în magazin numai atunci când salvează datele - cu alte cuvinte, restul aplicației ar putea consuma date nevalide.

Nu durează mult până când magazinul global devine o mizerie dezorganizată și nu este clar de unde provine fiecare parte a mizeriei, ceea ce face mai dificilă depanarea și întreținerea.

Înțelegerea importanței testării automate

Testarea automată ar trebui considerată la fel de importantă ca calitatea codului pentru orice aplicație web Angular. Unul dintre motivele majore pentru care programatorii scriu teste este să-și documenteze codul: dacă un nou dezvoltator se alătură companiei, logica de afaceri și anumite fluxuri de UI ar trebui să fie clare pe baza așteptărilor suitei de teste. De asemenea, testarea automată dezvăluie erori la începutul dezvoltării.

Puneți potențialului dvs. dezvoltator Angular trei întrebări de testare:

• Ce părere aveți despre testare? Orice candidat căruia nu-i pasă de testarea automată ar trebui să înceteze să fie luat în considerare. Chiar dacă preferă să nu folosească dezvoltarea bazată pe teste (TDD), dezvoltatorii care nu reușesc să vadă valoarea testării automate vor costa timpul de testare manuală a companiei și, mai rău, timpul de nefuncționare al utilizatorului final atunci când apar regresii pe măsură ce se fac modificări la o aplicație. peste orar.
• Pe ce te concentrezi când testezi? În loc să testeze date de bază, cum ar fi posibilitatea de a atribui valori unui câmp sau de a încerca pentru metrici specifice de acoperire a testelor (adică, acoperire de 85%), un dezvoltator Angular excelent ar trebui să se concentreze pe testarea logicii de bază a afacerii.
• Există de obicei mai multe teste E2E sau mai multe teste unitare? De ce? Ca aplicații front-end, aplicațiile Angular pot folosi două tipuri principale de teste automate: teste unitare și teste end-to-end (E2E). De obicei, o suită de teste va avea multe teste unitare și mai puține teste E2E. Testele unitare sunt mici, deci sunt rapide de scris și executat. Testele E2E sunt mai mari și mai lente. Avertisment corect: nu toți dezvoltatorii vor avea aceeași părere cu privire la raportul corect de teste de unitate și E2E de menținut. În realitate, depinde de complexitatea aplicației testate și chiar și atunci, răspunsul este discutabil într-o oarecare măsură.

Cadre de testare unghiulară

Dezvoltatorii angular au opțiuni când vine vorba de cadre de testare automată. Testarea unitară poate fi efectuată prin Jest sau Jasmine și Karma. Fiecare dezvoltator Angular ar trebui să fie familiarizat cu Jasmine și Karma. Jest este, de asemenea, obișnuit - este în general mai rapid și oferă opțiuni de testare mai avansate.

Standardul de testare E2E pentru o aplicație Angular este Protractor, instrumentul implicit generat de CLI Angular. O alternativă este Cypress, un cadru promițător de testare E2E, cu o mulțime de opțiuni.

Asigurați-vă că candidatul are cunoștințe aprofundate despre cel puțin un cadru de testare unitară și un cadru de testare E2E.

Rămâneți informat despre cele mai recente lansări Angular

Este posibil ca dezvoltatorii Great Angular să nu folosească întotdeauna cea mai recentă versiune în dezvoltare din diverse motive, dar ar trebui să cunoască programul de lansare Angular, astfel încât să poată fi la curent cu schimbările și să fie pregătiți să schimbe. O modalitate de a evalua acest lucru este să întrebați candidatul dacă este familiarizat cu strategia de lansare a Angular. Angular vizează o lansare majoră la fiecare șase luni, de obicei în jurul lunii februarie și mai. O versiune Angular este sub „asistență activă” în primele șase luni de la data lansării și este sub „suport pe termen lung” timp de 12 luni de la data lansării. Aceasta este o cronologie destul de strânsă în comparație cu alte tehnologii, ceea ce face deosebit de important să rămâneți la curent.

Ați putea, de asemenea, să faceți câteva cercetări despre cea mai recentă versiune de Angular și să întrebați candidatul despre beneficiile acestor noi funcții. De exemplu, în perioada în care Angular 14 a fost lansat, este posibil să fi întrebat candidatul despre:

• Componente independente, care reduc nevoia de module Angular. Componentele independente nu sunt declarate în niciun NgModule existent și își gestionează direct propriile dependențe. Ca rezultat, se poate depinde direct de ele, fără a fi nevoie de un NgModule intermediar.
• Formulare tipizate, o altă actualizare majoră în Angular 14, care a stabilit tastarea strictă ca implicită pentru Formele reactive Angular. Formularele tipizate asigură că valorile din FormControls , FormGroups și FormArrays sunt sigure de tip pe întreaga suprafață API. Acest lucru permite forme mai sigure, în special pentru cazurile complexe profund imbricate.

Următorul mare dezvoltator angular pentru echipa ta de front-end

Fiecare proiect și echipă de dezvoltare web este diferită și va acorda o importanță diferită diferitelor aspecte ale abilităților și cunoștințelor unui dezvoltator Angular. Dar înțelegerea subiectelor de bază pe care le-am prezentat aici va permite managerilor de angajare să participe semnificativ la angajare, chiar și la evaluările mai tehnice.

Blogul Toptal Engineering își exprimă recunoștința lui Ramazan Yildiz pentru revizuirea conceptelor tehnice și diagramelor prezentate în acest articol.