Comment embaucher des développeurs angulaires : compétences et connaissances clés à rechercher

Grâce à son architecture hautement évolutive, de nombreuses équipes de développement Web choisissent Angular pour créer des applications monopage efficaces et sophistiquées. Mais embaucher des développeurs Angular est plus facile à dire qu'à faire. Bien qu'il existe de nombreux candidats, la clé d'une expérience de développement transparente est de trouver un excellent développeur Angular, qui applique les meilleures pratiques et des techniques avancées pour répondre aux normes de codage de haute qualité.

Comprendre les concepts clés du framework frontal populaire de Google vous préparera à interroger en toute confiance des prospects et à embaucher les développeurs les plus qualifiés, ceux qui s'efforcent de faire passer une base de code au niveau supérieur. Cet article présente les compétences et les connaissances cruciales qu'un professionnel angulaire premium devrait avoir.

Remarque : Ce guide s'applique aux dernières versions d'Angular, qui ne sont plus connues sous le nom d'AngularJS : "Angular" s'applique depuis Angular 2. Si vous embauchez pour la maintenance ou la mise à niveau d'un projet d'application Web AngularJS hérité (le 1.x branch), consultez Comment embaucher un excellent développeur AngularJS.

Connaître les fonctions de base d'Angular

Le framework Angular s'exécute sur TypeScript et tout le code écrit dans une application est transpilé en JavaScript. TypeScript est un sur- ensemble de JavaScript qui se compile en JavaScript brut. Le code angulaire est représenté par ce sur-ensemble.

De nombreux développeurs apprennent Angular mais ne comprennent pas bien les concepts de base requis par JavaScript, TypeScript, HTML ou CSS. Si ces fondations manquent, les développeurs sont susceptibles d'utiliser des solutions de contournement inappropriées et multiplient ainsi la dette technique d'un projet.

Alors, demandez au candidat s'il a des connaissances en HTML5 et CSS3. Un bon développeur Angular n'a pas besoin d'être un expert HTML ou CSS tant que quelqu'un d'autre dans l'équipe l'est, mais il doit comprendre ces concepts clés :

• Boîte flexible
• Variables SCSS
• La différence entre un span et un div
• Les classes importantes en CSS
• Les attributs

Les développeurs angulaires doivent avoir une solide compréhension de JavaScript et de TypeScript, ainsi que certaines compétences en HTML et CSS.

Tweeter

Concevoir avant de coder

Une bonne conception est la clé d'une bonne architecture d'application. Demandez à votre candidat comment il réalise ses conceptions et comparez sa réflexion avec ces considérations idéales :

• Où ira le code ? Y a-t-il besoin d'une nouvelle bibliothèque ou d'un module ?
• Quelles sont les entrées et les sorties ?
• Devrait-il y avoir des composants ou des directives réutilisables ?
• Où ira l'Etat ? (Discuté plus en détail sous Gestion de l'état ci-dessous.)
• Où ira la logique métier, c'est-à-dire dans quel service ?
• Certains composants peuvent-ils être partagés entre les bibliothèques pour créer, essentiellement, un système de conception d'interface utilisateur ?

Les détails complets d'un design particulier sont moins importants que le fait que le candidat ait l'habitude de faire des designs. Toutes les conceptions sont temporaires, donc, pour la plupart des applications, la documentation peut être aussi simple qu'une photo d'un croquis sur un tableau blanc, à moins qu'une documentation formelle ne soit requise. À un stade ultérieur, le développeur peut générer la conception technique à partir du code (avec les bons outils) pour préciser comment toutes les parties sont interdépendantes.

Comprendre les cycles de vie des applications angulaires

Demandez à votre candidat ce qu'il sait du cycle de vie des composants angulaires . Leur réponse doit inclure trois hooks de cycle de vie : ngOnInit , ngOnChanges et ngOnDestroy . Comme les noms le suggèrent, ngOnInit est appelé lors de l'initialisation du composant, ngOnDestroy est appelé lorsque le composant est détruit et ngOnChanges est appelé lorsqu'un attribut change. Ce dernier peut se produire avant ngOnInit - lorsque l'attribut est déjà affecté avant que le composant ne soit complètement initialisé, alors ngOnChanges est exécuté avant ngOnInit .

Si le candidat connaît également ngDoCheck , ngAfterContentInit , ngAfterContentChecked , ngAfterViewInit et ngAfterViewChecked , il connaît tous les crochets de détection de changement pour les composants et a une longueur d'avance.

Une bonne question de suivi à poser sur l'un des crochets : "Quand cette détection de changement se produit-elle ?"

Un cycle de vie moins connu est le cycle de vie du fournisseur , qui n'a qu'un seul crochet : ngOnDestroy . Ceci est appelé uniquement lorsque le fournisseur est attaché au niveau du composant, auquel cas il est détruit avec le composant. S'il est fourni au niveau de la racine ou du module, il ne sera jamais détruit.

Le constructeur d'un fournisseur sera exécuté la première fois que le fournisseur est utilisé, il est donc possible que le constructeur ne soit jamais exécuté. Interrogez votre candidat sur cette possibilité - dans des scénarios réels, cela peut être une source de bogues souvent négligée !

Solide connaissance de la programmation réactive

Dans une application Angular, la programmation réactive est souvent la partie la plus difficile à comprendre. Beaucoup de gens pensent de manière procédurale lorsqu'ils commencent à programmer un morceau de code, en supposant qu'il est plus facile à comprendre et à utiliser, comme les étapes d'une recette.

La programmation réactive consiste à réagir à des choses que nous ne pouvons pas contrôler et qui peuvent se produire dans un ordre imprévisible. Bien que nous réagissions aux choses de cette manière tous les jours - par exemple, freiner lorsque la voiture devant nous s'arrête soudainement - de nombreux développeurs ont du mal à adopter une approche réactive de la programmation.

Mais tout ce qui se passe dans une application Angular est basé sur une programmation réactive. Quelques exemples de réactivité dans une application d'achat Angular, par exemple, peuvent inclure :

• Lorsque l'utilisateur se connecte, le numéro sur l'icône du panier est mis à jour et les éléments de menu sont remplacés par des options plus spécifiques.
• Lorsque l'utilisateur accède à une catégorie, les produits sont mis à jour en fonction de la catégorie sélectionnée.
• Lorsque l'utilisateur ajoute un produit à son panier, l'icône du panier se met à jour avec le nombre de produits.
• Lorsqu'un article est en rupture de stock (enregistré via un écouteur surveillant les quantités de stock actuelles depuis le back-end), l'interface utilisateur de la page est mise à jour.

Notez que ces choses se produisent automatiquement et n'ont pas besoin d'une actualisation de la page pour apparaître. Lors d'un entretien, demandez au candidat de décrire comment il a appliqué la programmation réactive dans une application qu'il a développée. Si le candidat décrit des solutions qui impliquent d'actualiser la page ou d'appeler manuellement ChangeDetectorRef.detectChanges() pour actualiser un composant, considérez qu'il s'agit d'un indicateur jaune.

Pièges avec les observables en angulaire

Les développeurs moins expérimentés peuvent parfois constater que le code qu'ils écrivent dans leurs applications angulaires n'est pas exécuté. Les développeurs chevronnés d'Angular peuvent identifier une cause commune : il n'y a pas d'abonnement sur un Observable , un type d'objet principal de la programmation réactive. Ce n'est qu'avec un abonnement que les appels back-end ou d'autres réactions seront exécutés.

Il existe deux façons de créer des abonnements : les développeurs peuvent utiliser le canal async ou la méthode d' subscribe . Mais il y a une mise en garde : si les développeurs effectuent un abonnement manuel (avec la méthode d' subscribe ), l' Observable devra être détruit manuellement (bien qu'il existe des cas extrêmes où cela se produit par défaut). Les développeurs peuvent détruire les Observables de plusieurs manières :

• Utilisation du canal async , si possible (cela détruit l' Observable lorsque le composant n'est plus nécessaire).
• Désabonnement manuel en utilisant la méthode de unsubscribe sur un Observable à la fin de la durée de vie du composant ( ngOnDestroy ).
• D'une manière plus déclarative avec l'opérateur takeUntil à l'intérieur de l'opérateur pipe , et en utilisant un sujet (c'est-à-dire quelque chose nommé comme destroy$ ). Dans ce cas, le sujet émet destroy$.next() à la fin de la durée de vie du composant ( ngOnDestroy ). Après avoir reçu l'événement destroy, l'opérateur takeUntil n'acceptera plus les événements de l'Observable auquel il est lié afin que sa logique d'abonné ne soit plus déclenchée. Pour un exemple, voir l'opérateur takeUntil dans la section 2. Des fonctionnalités similaires peuvent être exposées avec les opérateurs take et takeWhile .
• Depuis que les applications Angular sont passées au compilateur Ivy, nous pouvons également utiliser des annotations. La bibliothèque until-destroy ou une autre bibliothèque tierce comme SubSink peut être utilisée pour se désabonner en douceur des observables une fois qu'un composant est détruit.

Un autre problème potentiel avec la programmation réactive provient des fuites de mémoire et des appels multiples vers le back-end. Demandez au candidat s'il est conscient de ces problèmes et comment il les résoudrait normalement. Des fuites de mémoire peuvent se produire si vous ne parvenez pas à vous désabonner des Observable comme décrit ci-dessus. Plusieurs appels vers le back-end en raison de plusieurs abonnements sur un appel back-end peuvent être résolus en partageant le Observable .

Connaître l'état et comment l'utiliser

Toutes les applications à page unique ont un état, et cet état est disponible quelque part sur le front-end. Mais qu'est-ce qu'un état, exactement ? Il contient toutes les variables propres à l'expérience utilisateur en cours. Par exemple, les détails de l'utilisateur authentifié comme le nom et l'URL de l'image de profil, un élément de menu spécifique sélectionné ou une liste à l'écran telle qu'une liste d'éléments du panier.

Dans une application Angular, il existe trois principaux types d'état frontal à prendre en compte :

Une bonne compréhension de ce qu'est l'état et du moment où il doit être chargé ou rechargé est l'une des compétences clés à rechercher lors de l'embauche de développeurs Angular. C'est un terrain de choix à explorer si votre équipe a la possibilité d'examiner un exemple de code écrit par le candidat. Si le demandeur utilise une bibliothèque pour la gestion de l'état :

• Recherchez l'utilisation de NgRx, Akita, NgXs ou de bibliothèques similaires spécifiques à la gestion d'état.
• Ensuite, regardez s'il existe des notifications pour effects , action , reducer , store et selector dans le code associé.

Regardons le flux général de l'état de l'application dans NgRx (qui est similaire à celui d'Akita et d'autres bibliothèques) à titre d'exemple :

Si le développeur crée son propre état avec des services, sa compétence en gestion d'état peut être plus difficile à identifier :

• Recherchez les références aux mots state ou effect .
• Voyez si le code réagit à une action, par exemple, si l'utilisateur appuie sur le bouton A, le texte devrait changer sur l'écran B.

Questions à poser aux enquêteurs sur l'état

Vous ne pouvez pas toujours découvrir tout ce que vous devez savoir en enquêtant sur le code d'un candidat. Ajoutez ces requêtes à votre liste de questions pour déterminer dans quelle mesure les développeurs potentiels d'Angular comprennent l'état :

• Où avez-vous utilisé state — et comment ? Il s'agit d'un point de départ solide pour comprendre leur expérience avec l'État ; n'ayez pas peur de chercher des détails.
• Comment décidez-vous d'utiliser ou non une bibliothèque? C'est bon signe s'ils savent qu'il n'est pas toujours utile d'inclure une bibliothèque d'état dans une application.
• Que placeriez-vous à l'intérieur de l'État, où le placeriez-vous et comment utiliseriez-vous un système de gestion de l'État ? S'ils disent : « Je mets tout dans mon état global d'application », c'est un signe certain que le développeur n'est pas conscient des effets secondaires négatifs qu'un tel système peut donner à une application.

Les développeurs qui comprennent les différents types d'états éviteront ces effets secondaires :

• Un état qui ne s'applique qu'à un seul composant peut être modifié ou corrompu par d'autres composants.
• Les données sont imbriquées dans le magasin, il devient donc difficile de suivre les données et les données deviennent illisibles pour l'homme (à des fins de débogage, d'échange de données, etc.).
• La modification de données à l'intérieur d'un formulaire les émet déjà vers le reste de l'application, alors qu'elles ne doivent être envoyées au magasin que lors de l'enregistrement des données. En d'autres termes, le reste de l'application peut consommer des données non valides.

Il ne faut pas longtemps avant que le magasin global ne devienne un gâchis désorganisé, et l'origine de chaque partie du gâchis n'est pas claire, ce qui rend plus difficile le débogage et la maintenance.

Comprendre l'importance des tests automatisés

Les tests automatisés doivent être considérés comme aussi importants que la qualité du code pour toute application Web angulaire. L'une des principales raisons pour lesquelles les programmeurs écrivent des tests est de documenter leur code : si un nouveau développeur rejoint l'entreprise, la logique métier et certains flux d'interface utilisateur doivent être clairs en fonction des attentes de la suite de tests. De plus, les tests automatisés révèlent les bogues au début du développement.

Posez trois questions de test à votre développeur Angular potentiel :

• Que pensez-vous des tests ? Tout candidat qui ne se soucie pas des tests automatisés devrait cesser d'être pris en considération. Même s'ils préfèrent ne pas utiliser le développement piloté par les tests (TDD), les développeurs qui ne voient pas la valeur des tests automatisés coûteront à votre entreprise du temps de test manuel et, pire, des temps d'arrêt pour l'utilisateur final lorsque des régressions apparaissent lorsque des modifications sont apportées à une application. heures supplémentaires.
• Sur quoi vous concentrez-vous lors des tests ? Plutôt que de tester des données de base comme la possibilité d'attribuer des valeurs à un champ ou de s'efforcer d'obtenir des métriques de couverture de test spécifiques (c'est-à-dire une couverture de 85%), un grand développeur angulaire devrait se concentrer sur le test de la logique métier de base.
• Y a-t-il généralement plus de tests E2E ou plus de tests unitaires ? Pourquoi? En tant qu'applications frontales, les applications Angular peuvent tirer parti de deux principaux types de tests automatisés : les tests unitaires et les tests de bout en bout (E2E). En règle générale, une suite de tests aura de nombreux tests unitaires et moins de tests E2E. Les tests unitaires sont petits, ils sont donc rapides à écrire et à exécuter. Les tests E2E sont plus gros et plus lents. Attention : tous les développeurs n'auront pas le même avis quant au bon ratio de tests unitaires et E2E à maintenir. En réalité, cela dépend de la complexité de l'application testée, et même dans ce cas, la réponse est discutable dans une certaine mesure.

Cadres de test angulaire

Les développeurs angulaires ont le choix en matière de frameworks de test automatisés. Les tests unitaires peuvent être effectués via Jest ou Jasmine and Karma. Chaque développeur angulaire doit être familiarisé avec Jasmine et Karma. Jest est également courant - il est généralement plus rapide et propose des options de test plus avancées.

La norme de test E2E pour une application Angular est Protractor, l'outil par défaut généré par la CLI Angular. Une alternative est Cypress, un cadre de test E2E prometteur avec de nombreuses options.

Assurez-vous que le candidat possède une connaissance approfondie d'au moins un cadre de test unitaire et un cadre de test E2E.

Rester informé des dernières versions d'Angular

Les grands développeurs d'Angular n'utilisent peut-être pas toujours la dernière version en développement pour diverses raisons, mais ils doivent connaître le calendrier de publication d'Angular afin de pouvoir se tenir au courant des changements et être prêts à changer. Une façon d'évaluer cela est de demander au candidat s'il connaît la stratégie de publication d'Angular. Angular vise une version majeure tous les six mois, généralement vers février et mai. Une version angulaire est sous "support actif" pendant les six premiers mois après sa date de sortie, et sous "support à long terme" pendant 12 mois après sa date de sortie. Il s'agit d'un délai assez serré par rapport à certaines autres technologies, ce qui rend particulièrement important de rester à jour.

Vous pouvez également faire des recherches sur la version la plus récente d'Angular et interroger votre candidat sur les avantages de ces nouvelles fonctionnalités. Par exemple, à peu près au moment de la sortie d'Angular 14, vous avez peut-être demandé au candidat :

• Composants autonomes, qui réduisent le besoin de modules angulaires. Les composants autonomes ne sont déclarés dans aucun NgModule existant et gèrent directement leurs propres dépendances. Par conséquent, ils peuvent être utilisés directement sans avoir besoin d'un NgModule intermédiaire.
• Formulaires typés, une autre mise à jour majeure dans Angular 14, qui définit le typage strict comme valeur par défaut pour les formulaires réactifs angulaires. Les formulaires typés garantissent que les valeurs à l'intérieur FormControls , FormGroups et FormArrays sont de type sûr sur toute la surface de l'API. Cela permet des formulaires plus sûrs, en particulier pour les cas complexes profondément imbriqués.

Le prochain grand développeur angulaire pour votre équipe frontale

Chaque projet et chaque équipe de développement Web est différent et accordera une importance différente aux différents aspects des compétences et des connaissances d'un développeur Angular. Mais comprendre les sujets fondamentaux que nous avons présentés ici permettra aux responsables du recrutement de participer de manière significative au recrutement, même aux évaluations plus techniques.

Le blog Toptal Engineering exprime sa gratitude à Ramazan Yildiz pour avoir révisé les concepts techniques et les schémas présentés dans cet article.