Come assumere sviluppatori angolari: competenze e conoscenze chiave da cercare
Pubblicato: 2022-09-14Grazie alla sua architettura altamente scalabile, molti team di sviluppo Web scelgono Angular per creare applicazioni a pagina singola efficienti e sofisticate. Ma assumere sviluppatori Angular è più facile a dirsi che a farsi. Sebbene ci siano molti candidati là fuori, la chiave per un'esperienza di sviluppo senza interruzioni è trovare un grande sviluppatore Angular, uno che applichi le migliori pratiche e tecniche avanzate per soddisfare standard di codifica di alta qualità.
Comprendere i concetti chiave del popolare framework front-end di Google ti preparerà a intervistare con sicurezza potenziali clienti e ad assumere gli sviluppatori di altissimo livello, coloro che si sforzano di portare una base di codice al livello successivo. Questo articolo illustra le abilità e le conoscenze cruciali che un professionista angolare premium dovrebbe avere.
TL; DR
I candidati Angular di alta qualità saranno coloro che:
- Conoscere le funzioni principali di Angular.
- Progetta prima che inizino a programmare.
- Comprendere i cicli di vita delle applicazioni angolari.
- Avere una solida conoscenza della programmazione reattiva.
- Sapere cos'è lo stato e come usarlo.
- Sono esperti e supportano i test automatizzati.
- Tieniti informato sulle ultime versioni di Angular.
Nota: questa guida si applica alle ultime versioni di Angular, che non sono più conosciute come AngularJS: "Angular" è applicato da Angular 2. Se stai assumendo per la manutenzione o l'aggiornamento di un progetto di applicazione Web AngularJS legacy (il 1.x branch), dai un'occhiata a Come assumere un grande sviluppatore AngularJS.
Conoscere le funzioni principali di Angular
Il framework Angular viene eseguito su TypeScript e tutto il codice scritto all'interno di un'applicazione viene trasferito in JavaScript. TypeScript è un superset di JavaScript che compila in JavaScript semplice. Il codice angolare è rappresentato da questo superset.
Molti sviluppatori imparano Angular ma non hanno una buona comprensione dei concetti fondamentali richiesti da JavaScript, TypeScript, HTML o CSS. Se mancano queste basi, gli sviluppatori tendono a utilizzare soluzioni alternative inadeguate e quindi moltiplicano il debito tecnico di un progetto.
Quindi, chiedi al candidato se ha conoscenza di HTML5 e CSS3. Un buon sviluppatore Angular non ha bisogno di essere un esperto di HTML o CSS fintanto che lo è qualcun altro nel team, ma dovrebbe comprendere questi concetti chiave:
- Flexbox
- variabili SCSS
- La differenza tra uno
span
e undiv
- Le classi importanti nei CSS
- Attributi
Gli sviluppatori angolari dovrebbero avere una solida conoscenza di JavaScript e TypeScript, nonché alcune abilità HTML e CSS.
Twitta
Progettazione prima della codifica
Un buon design è la chiave per una buona architettura dell'applicazione. Chiedi al tuo candidato come realizza i suoi progetti e confronta il suo pensiero con queste considerazioni ideali:
- Dove andrà il codice? C'è bisogno di una nuova libreria o di un modulo?
- Quali sono gli ingressi e le uscite?
- Dovrebbero esserci componenti o direttive riutilizzabili?
- Dove andrà lo Stato? (Discusso ulteriormente sotto la gestione statale di seguito.)
- Dove andrà a finire la logica aziendale, ovvero in quale servizio?
- È possibile condividere determinati componenti tra le librerie per creare, essenzialmente, un sistema di progettazione dell'interfaccia utente?
Le specifiche complete di un progetto particolare sono meno importanti del fatto che il candidato abbia l'abitudine di realizzare progetti. Tutti i progetti sono temporanei, quindi, per la maggior parte delle applicazioni, la documentazione può essere semplice come la foto di uno schizzo su una lavagna a meno che non sia richiesta una documentazione formale. In una fase successiva, lo sviluppatore può generare il progetto tecnico dal codice (con gli strumenti giusti) per chiarire come tutte le parti sono correlate.
Comprensione dei cicli di vita delle applicazioni angolari
Chiedi al tuo candidato cosa sa sul ciclo di vita dei componenti angolari . La loro risposta dovrebbe includere tre hook del ciclo di vita: ngOnInit
, ngOnChanges
e ngOnDestroy
. Come suggeriscono i nomi, ngOnInit
viene chiamato all'inizializzazione del componente, ngOnDestroy
viene chiamato quando il componente viene distrutto e ngOnChanges
viene chiamato quando un attributo cambia. Quest'ultimo può verificarsi prima ngOnInit
l'attributo è già assegnato prima che il componente sia completamente inizializzato, ngOnChanges
viene eseguito prima ngOnInit
.
Se il candidato conosce anche ngDoCheck
, ngAfterContentInit
, ngAfterContentChecked
, ngAfterViewInit
e ngAfterViewChecked
, conosce tutti gli hook di rilevamento delle modifiche per i componenti e sono un passo avanti.
Una buona domanda di follow-up da porre su uno qualsiasi degli hook: "Quando si verifica questo rilevamento delle modifiche?"
Un ciclo di vita meno noto è il provider lifecycle , che ha un solo hook: ngOnDestroy
. Viene chiamato solo quando il provider è collegato a livello di componente, nel qual caso viene distrutto insieme al componente. Se viene fornito a livello di root o di modulo, non verrà mai distrutto.
Il costruttore di un provider verrà eseguito la prima volta che viene utilizzato il provider, quindi è possibile che il costruttore non venga mai eseguito. Interroga il tuo candidato su questa possibilità: negli scenari del mondo reale, può essere una fonte di bug spesso trascurata!
Solida conoscenza della programmazione reattiva
In un'applicazione Angular, la programmazione reattiva è spesso la parte più difficile da capire. Molte persone pensano in modo procedurale quando iniziano a programmare un pezzo di codice, partendo dal presupposto che sia più facile da capire e con cui lavorare, come i passaggi di una ricetta.
La programmazione reattiva implica reagire a cose che non possiamo controllare e che possono verificarsi in un ordine imprevedibile. Sebbene ogni giorno reagiamo alle cose in questo modo, ad esempio frenando quando l'auto davanti a noi si ferma improvvisamente, molti sviluppatori trovano difficile adottare un approccio reattivo alla programmazione.
Ma tutto ciò che accade all'interno di un'app Angular si basa sulla programmazione reattiva. Alcuni esempi di reattività in un'applicazione di acquisto angolare, ad esempio, possono includere:
- Quando l'utente effettua l'accesso, il numero sull'icona del carrello si aggiorna e le voci di menu cambiano in opzioni più specifiche.
- Quando l'utente passa a una categoria, i prodotti si aggiornano in base alla categoria selezionata.
- Quando l'utente aggiunge un prodotto al carrello, l'icona del carrello si aggiorna con il numero di prodotti.
- Quando un articolo è esaurito (registrato tramite un listener che monitora le quantità di stock correnti dal back-end), l'interfaccia utente della pagina si aggiorna.
Tieni presente che queste cose accadono automaticamente e non è necessario un aggiornamento della pagina per essere visualizzate. In un colloquio, chiedi al candidato di descrivere come ha applicato la programmazione reattiva in un'applicazione che ha sviluppato. Se il candidato descrive soluzioni che implicano l'aggiornamento della pagina o la chiamata manuale di ChangeDetectorRef.detectChanges()
per aggiornare un componente, considera che una bandiera gialla.
Insidie con osservabili in angolare
Gli sviluppatori meno esperti a volte possono scoprire che il codice che scrivono nelle loro applicazioni Angular non viene eseguito. Gli sviluppatori Angular stagionati possono identificare una causa comune: non esiste un abbonamento su un Observable
, un tipo di oggetto principale nella programmazione reattiva. Solo con un abbonamento verranno eseguite chiamate di back-end o altre reazioni.
Esistono due modi per creare sottoscrizioni: Gli sviluppatori possono utilizzare la pipe async
o il metodo di subscribe
. Ma c'è un avvertimento: se gli sviluppatori eseguono un abbonamento manuale (con il metodo di subscribe
), Observable
dovrà essere distrutto manualmente (sebbene ci siano alcuni casi limite in cui si verifica per impostazione predefinita). Gli sviluppatori possono distruggere gli Observables
in diversi modi:
- Utilizzando il tubo
async
, ove possibile (questo distrugge l'Observable
quando il componente non è più necessario). - Annullamento manuale dell'iscrizione utilizzando il metodo di
unsubscribe
dell'iscrizione su unObservable
al termine del ciclo di vita del componente (ngOnDestroy
). - In un modo più dichiarativo con l'operatore
takeUntil
all'interno dell'operatorepipe
e utilizzando un soggetto (cioè qualcosa chiamato comedestroy$
). In questo caso, il soggetto emettedestroy$.next()
alla fine della vita del componente (ngOnDestroy
). Dopo aver ricevuto l'evento destroy, l'operatoretakeUntil
non accetterà più eventi dall'Osservabile a cui è legato in modo che la sua logica di abbonato non venga più attivata. Per un esempio, vedere l'operatore takeUntil nella sezione 2. Funzionalità simili possono essere esposte con gli operatoritake
etakeWhile
. - Poiché le applicazioni Angular sono passate al compilatore Ivy, possiamo anche utilizzare le annotazioni. La libreria
until-destroy
o un'altra libreria di terze parti come SubSink può essere utilizzata per annullare senza problemi l'iscrizione agli osservabili una volta che un componente viene distrutto.
Un altro potenziale punto dolente con la programmazione reattiva deriva da perdite di memoria e chiamate multiple al back-end. Chiedi al candidato se è a conoscenza di questi problemi e come li risolverebbe normalmente. Perdite di memoria possono verificarsi se non si annulla la sottoscrizione da Observable
s come descritto sopra. Più chiamate al back-end a causa di più abbonamenti su una chiamata back-end possono essere risolte condividendo Observable
.
Conoscere lo stato e come usarlo
Tutte le applicazioni a pagina singola hanno uno stato e questo stato è disponibile da qualche parte nel front-end. Ma cos'è uno stato, esattamente? Contiene tutte le variabili specifiche dell'esperienza utente corrente. Ad esempio, i dettagli dell'utente autenticato come il nome e l'URL dell'immagine del profilo, una specifica voce di menu selezionata o un elenco sullo schermo come un elenco di articoli del carrello.
In un'applicazione Angular, ci sono tre tipi principali di stato front-end da considerare:
Stato | Scopo |
---|---|
Applicazione | Informazioni generali disponibili per l'intera applicazione come utenti autenticati, ruoli utente, voci di menu o carrello acquisti di un utente. Tutto ciò che cambia in questo stato cambierà per l'intera applicazione. |
Modulo | Informazioni disponibili per l'intero modulo in cui viene utilizzato un servizio. Ogni volta che uno sviluppatore riutilizza un modulo con i provider, crea una nuova istanza di ciascun provider. Lo stato non verrà mai distrutto e verrà creato solo la prima volta che viene utilizzato un determinato provider. |
Componente | Informazioni disponibili per un determinato componente. I componenti sono le parti più piccole di un'applicazione. Un'applicazione Angular può avere più stati dei componenti, ma saranno accessibili solo tramite ciascun componente. Lo stato verrà creato quando il componente viene creato e distrutto quando il componente viene distrutto. |
Una buona comprensione di cosa sia lo stato e quando dovrebbe essere caricato o ricaricato, è una delle abilità chiave da cercare quando si assumono sviluppatori Angular. Questo è un territorio privilegiato da esplorare se il tuo team ha l'opportunità di rivedere un codice di esempio scritto dal candidato. Se il richiedente utilizza una biblioteca per la gestione dello stato:
- Cerca l'uso di NgRx, Akita, NgXs o librerie simili specifiche per la gestione dello stato.
- Quindi controlla se sono presenti notifiche per
effects
,action
,reducer
,store
eselector
nel codice correlato.
Diamo un'occhiata al flusso generale dello stato dell'applicazione in NgRx (che è simile a quello di Akita e di altre librerie) come esempio:
Se lo sviluppatore crea il proprio stato con i servizi, la sua competenza nella gestione dello stato può essere più difficile da identificare:
- Cerca i riferimenti alle parole
state
oeffect
. - Verifica se il codice sta reagendo a qualche azione, ad esempio, se l'utente preme il pulsante A, il testo dovrebbe cambiare nella schermata B.
Domande per gli intervistatori sullo stato
Non sempre puoi scoprire tutto ciò che devi sapere esaminando il codice di un richiedente. Aggiungi queste query al tuo elenco di domande per indagare sulla comprensione dello stato dei potenziali sviluppatori Angular:
- Dove hai usato lo
state
e come? Questo è un solido punto di partenza per comprendere la loro esperienza con lo stato; non aver paura di sondare i dettagli. - Come si decide se utilizzare o meno una libreria? È un buon segno se sanno che non è sempre utile includere una libreria di stato in un'applicazione.
- Cosa metteresti all'interno dello stato, dove lo metteresti e come utilizzi un sistema di gestione statale? Se dicono "Ho messo tutto nello stato dell'applicazione globale", questo è un segno sicuro che lo sviluppatore non è a conoscenza degli effetti collaterali negativi che un tale sistema può dare a un'applicazione.
Gli sviluppatori che comprendono i vari tipi di stato eviteranno questi effetti collaterali:
- Lo stato che si applica solo a un componente potrebbe essere modificato o danneggiato da altri componenti.
- I dati sono nidificati nell'archivio, quindi diventa difficile tenere traccia dei dati e i dati diventano illeggibili (ai fini del debug, dello scambio di dati, ecc.).
- La modifica dei dati all'interno di un modulo li emette già al resto dell'applicazione, mentre dovrebbe essere inviato all'archivio solo durante il salvataggio dei dati, in altre parole, il resto dell'applicazione potrebbe consumare dati non validi.
Non ci vuole molto prima che il negozio globale diventi un pasticcio disorganizzato e non è chiaro da dove provenga ciascuna parte del pasticcio, rendendo più difficile il debug e la manutenzione.
Comprendere l'importanza dei test automatizzati
I test automatici dovrebbero essere considerati importanti quanto la qualità del codice per qualsiasi applicazione Web Angular. Uno dei motivi principali per cui i programmatori scrivono test è documentare il proprio codice: se un nuovo sviluppatore entra a far parte dell'azienda, la logica aziendale e alcuni flussi dell'interfaccia utente dovrebbero essere chiari in base alle aspettative della suite di test. Inoltre, i test automatizzati rivelano bug all'inizio dello sviluppo.
Poni al tuo potenziale sviluppatore Angular tre domande di test:
- Cosa ne pensi dei test? Qualsiasi candidato a cui non interessano i test automatizzati dovrebbe cessare di essere preso in considerazione. Anche se preferiscono non utilizzare lo sviluppo guidato dai test (TDD), gli sviluppatori che non riescono a vedere il valore dei test automatizzati costeranno alla tua azienda i tempi di test manuali e, peggio ancora, i tempi di inattività dell'utente finale quando vengono visualizzate le regressioni quando vengono apportate modifiche a un'app col tempo.
- Su cosa ti concentri durante il test? Piuttosto che testare dati di base come essere in grado di assegnare valori a un campo o cercare metriche di copertura del test specifiche (ad esempio, copertura dell'85%), un grande sviluppatore Angular dovrebbe concentrarsi sul test della logica aziendale principale.
- Di solito ci sono più test E2E o più test unitari? Come mai? In quanto applicazioni front-end, le app Angular possono sfruttare due tipi principali di test automatizzati: test unitari e test end-to-end (E2E). In genere, una suite di test avrà molti test unitari e meno test E2E. Gli unit test sono piccoli, quindi sono veloci da scrivere ed eseguire. I test E2E sono più grandi e più lenti. Avviso corretto: non tutti gli sviluppatori avranno la stessa opinione sul corretto rapporto tra unità e test E2E da mantenere. In realtà, dipende dalla complessità dell'app da testare e, anche in questo caso, la risposta è discutibile in una certa misura.
Framework di test angolari
Gli sviluppatori angolari hanno delle scelte quando si tratta di framework di test automatizzati. I test unitari possono essere eseguiti tramite Jest o Jasmine e Karma. Ogni sviluppatore Angular dovrebbe avere familiarità con Jasmine e Karma. Jest è anche comune: è generalmente più veloce e offre opzioni di test più avanzate.
Lo standard di test E2E per un'applicazione Angular è Goniometro, lo strumento predefinito generato da Angular CLI. Un'alternativa è Cypress, un promettente framework di test E2E con molte opzioni.
Assicurati che il candidato abbia una conoscenza approfondita di almeno un framework di test unitari e un framework di test E2E.
Rimani informato sulle ultime versioni di Angular
Gli sviluppatori Great Angular potrebbero non utilizzare sempre l'ultima versione in fase di sviluppo per vari motivi, ma dovrebbero conoscere il programma di rilascio di Angular in modo da poter rimanere al passo con le modifiche ed essere pronti a passare. Un modo per valutare questo è chiedere al candidato se ha familiarità con la strategia di rilascio di Angular. Angular mira a una versione principale ogni sei mesi, in genere intorno a febbraio e maggio. Una versione Angular è sotto "supporto attivo" durante i primi sei mesi dopo la sua data di rilascio ed è sotto "supporto a lungo termine" per 12 mesi dopo la sua data di rilascio. Questa è una linea temporale abbastanza stretta rispetto ad altre tecnologie, il che rende particolarmente importante rimanere aggiornati.
Potresti anche fare qualche ricerca sulla versione più recente di Angular e chiedere al tuo candidato i vantaggi di queste nuove funzionalità. Ad esempio, nel periodo in cui Angular 14 è stato rilasciato, potresti aver chiesto al candidato di:
- Componenti standalone, che riducono la necessità di moduli angolari. I componenti autonomi non sono dichiarati in nessun
NgModule
esistente e gestiscono direttamente le proprie dipendenze. Di conseguenza, si può fare affidamento direttamente su di essi senza la necessità di unNgModule
intermedio. - Forme digitate, un altro importante aggiornamento in Angular 14, che imposta la tipizzazione rigorosa come predefinita per le forme reattive angolari. I moduli tipizzati assicurano che i valori all'interno
FormControls
,FormGroups
eFormArrays
siano indipendenti dai tipi nell'intera superficie dell'API. Ciò consente forme più sicure, soprattutto per casi complessi profondamente nidificati.
Il prossimo grande sviluppatore angolare per il tuo team front-end
Ogni progetto e team di sviluppo web è diverso e attribuirà un'importanza diversa ai vari aspetti delle abilità e delle conoscenze di uno sviluppatore Angular. Ma la comprensione degli argomenti fondamentali che abbiamo presentato qui consentirà ai responsabili delle assunzioni di partecipare in modo significativo alle assunzioni, anche nelle valutazioni più tecniche.
Il Toptal Engineering Blog estende la sua gratitudine a Ramazan Yildiz per aver esaminato i concetti tecnici e i diagrammi presentati in questo articolo.