Cómo contratar desarrolladores angulares: habilidades y conocimientos clave para buscar

Publicado: 2022-09-14

Con su arquitectura altamente escalable, muchos equipos de desarrollo web eligen Angular para crear aplicaciones de una sola página eficientes y sofisticadas. Pero contratar desarrolladores de Angular es más fácil decirlo que hacerlo. Si bien hay muchos candidatos, la clave para una experiencia de desarrollo perfecta es encontrar un excelente desarrollador de Angular, uno que aplique las mejores prácticas y técnicas avanzadas para cumplir con los estándares de codificación de alta calidad.

Comprender los conceptos clave sobre el popular marco de front-end de Google lo preparará para entrevistar con confianza a los prospectos y contratar a los desarrolladores del más alto calibre, aquellos que se esfuerzan por llevar una base de código al siguiente nivel. Este artículo establece las habilidades y conocimientos cruciales que debe tener un profesional de Angular premium.

TL;RD

Los candidatos angulares de alta calidad serán aquellos que:

  • Conozca las funciones principales de Angular.
  • Diseñe antes de empezar a codificar.
  • Comprender los ciclos de vida de las aplicaciones de Angular.
  • Tener un sólido conocimiento de la programación reactiva.
  • Saber qué estado es y cómo usarlo.
  • Son expertos y apoyan las pruebas automatizadas.
  • Manténgase informado sobre los últimos lanzamientos de Angular.

Nota: Esta guía se aplica a las últimas versiones de Angular, que ya no se conocen como AngularJS: "Angular" se aplica desde Angular 2. Si está contratando para el mantenimiento o la actualización de un proyecto de aplicación web AngularJS heredado (el 1.x rama), consulte Cómo contratar a un gran desarrollador de AngularJS.

Conozca las funciones principales de Angular

El marco Angular se ejecuta en TypeScript y todo el código escrito dentro de una aplicación se transfiere a JavaScript. TypeScript es un superconjunto de JavaScript que se compila en JavaScript simple. El código angular está representado por este superconjunto.

Muchos desarrolladores aprenden Angular pero carecen de una buena comprensión de los conceptos básicos que requieren JavaScript, TypeScript, HTML o CSS. Si faltan estos cimientos, los desarrolladores pueden usar soluciones alternativas inapropiadas y, por lo tanto, multiplicar la deuda técnica de un proyecto.

Entonces, pregúntele al candidato si tiene conocimientos de HTML5 y CSS3. Un buen desarrollador de Angular no necesita ser un experto en HTML o CSS, siempre y cuando alguien más en el equipo lo sea, pero debe comprender estos conceptos clave:

  • Caja flexible
  • Variables SCSS
  • La diferencia entre un span y un div
  • Las clases importantes en CSS
  • Atributos

Los desarrolladores angulares deben tener una sólida comprensión de JavaScript y TypeScript, así como algunas habilidades de HTML y CSS.

Pío

Diseño antes de codificar

Un buen diseño es la clave para una buena arquitectura de aplicaciones. Pregúntele a su candidato cómo hace sus diseños y compare su pensamiento con estas consideraciones ideales:

  • ¿Dónde irá el código? ¿Hay necesidad de una nueva biblioteca o un módulo?
  • ¿Cuáles son las entradas y salidas?
  • ¿Debería haber componentes o directivas reutilizables?
  • ¿Hacia dónde irá el Estado? (Discutido más adelante en Gestión estatal a continuación).
  • ¿Adónde irá la lógica empresarial, es decir, en qué servicio?
  • ¿Se pueden compartir ciertos componentes entre bibliotecas para crear, esencialmente, un sistema de diseño de interfaz de usuario?

Los detalles completos de un diseño en particular son menos importantes que si el candidato tiene el hábito de hacer diseños. Todos los diseños son temporales, por lo que, para la mayoría de las aplicaciones, la documentación puede ser tan simple como una foto de un boceto en una pizarra, a menos que se requiera documentación formal. En una etapa posterior, el desarrollador puede generar el diseño técnico a partir del código (con las herramientas adecuadas) para dejar claro cómo se interrelacionan todas las partes.

Comprender los ciclos de vida de las aplicaciones angulares

Pregúntele a su candidato qué sabe sobre el ciclo de vida del componente Angular . Su respuesta debe incluir tres enlaces de ciclo de vida: ngOnInit , ngOnChanges y ngOnDestroy . Como sugieren los nombres, se llama a ngOnInit en la inicialización del componente, se llama a ngOnDestroy cuando se destruye el componente y se llama ngOnChanges cuando cambia un atributo. Esto último puede ocurrir antes ngOnInit cuando el atributo ya está asignado antes de que el componente se haya inicializado por completo, entonces ngOnChanges se ejecuta antes ngOnInit .

Si el candidato también conoce ngDoCheck , ngAfterContentInit , ngAfterContentChecked , ngAfterViewInit y ngAfterViewChecked , conoce todos los ganchos de detección de cambios para los componentes y está un paso adelante.

Una buena pregunta de seguimiento para hacer sobre cualquiera de los ganchos: "¿Cuándo ocurre esta detección de cambios?"

Aparecen cinco cuadros con flechas que apuntan hacia abajo a la izquierda. Todos son verdes excepto el cuarto, que es azul y tiene un corchete que se expande en cinco cuadros más que apuntan hacia abajo y que aparecen a la derecha (el primero es blanco, mientras que el resto son azules). De arriba a abajo, los cuadros de la izquierda dicen: "constructor, ngOnChanges, ngOnInit, ngDoCheck y ngOnDestroy". La flecha de "constructor" a "ngOnChanges" está etiquetada como "El componente tiene entradas vinculadas", y hay una flecha adicional que apunta desde "constructor" a "ngOnInit" etiquetada como "El componente no tiene entradas vinculadas". La flecha de "ngOnChanges" a "ngOnInit" tiene la etiqueta "Primera ejecución", y hay una flecha adicional que apunta de "ngOnChange" a "ngDoCheck" con la etiqueta "No es la primera ejecución". Aparece un cuadro blanco con el texto "1+ cambio de propiedades de entrada vinculadas a datos" en la parte superior izquierda de "ngOnChanges" y lo señala. Los cuadros de la derecha, de arriba a abajo, dicen: "¿Primera vez que se llama?, ngAfterContentInit, ngAfterContentChecked, ngAfterViewInit y ngAfterViewChecked". La flecha de "¿Llamó por primera vez?" a "ngAfterContentInit" tiene la etiqueta "Sí", y hay una flecha adicional que apunta desde "¿Primera vez que se llama?" a "ngAfterContentChecked" con la etiqueta "No". La flecha de "ngAfterContentChecked" a "ngAfterViewInit" tiene la etiqueta "Primera vez que se llama" y una flecha adicional apunta de "ngAfterContentChecked" a "ngAfterViewChecked" con la etiqueta "No es la primera vez que se llama".
Una descripción general de los ciclos de vida de los componentes de Angular.

Un ciclo de vida menos conocido es el ciclo de vida del proveedor , que solo tiene un gancho: ngOnDestroy . Esto se llama solo cuando el proveedor está adjunto al nivel del componente, en cuyo caso se destruye junto con el componente. Si se proporciona a nivel raíz o de módulo, nunca se destruirá.

El constructor de un proveedor se ejecutará la primera vez que se utilice el proveedor, por lo que es posible que el constructor nunca se ejecute. Pregúntele a su candidato sobre esta posibilidad: en escenarios del mundo real, ¡puede ser una fuente de errores que a menudo se pasa por alto!

Sólidos conocimientos de programación reactiva

En una aplicación Angular, la programación reactiva suele ser la parte más difícil de entender. Muchas personas piensan de manera procedimental cuando comienzan a programar un fragmento de código, asumiendo que es más fácil de entender y trabajar con él, como los pasos de una receta.

La programación reactiva implica reaccionar ante cosas que no podemos controlar, y eso puede ocurrir en un orden impredecible. Aunque reaccionamos a las cosas de esta manera todos los días, por ejemplo, frenar cuando el automóvil frente a nosotros se detiene repentinamente, a muchos desarrolladores les resulta difícil adoptar un enfoque reactivo para la programación.

Pero, todo lo que sucede dentro de una aplicación Angular se basa en la programación reactiva. Algunos ejemplos de reactividad en una aplicación de compras Angular, por ejemplo, pueden incluir:

  • Cuando el usuario inicia sesión, el número en el ícono del carrito de compras se actualiza y los elementos del menú cambian a opciones más específicas.
  • Cuando el usuario navega a una categoría, los productos se actualizan según la categoría seleccionada.
  • Cuando el usuario agrega un producto a su carrito, el ícono del carrito de compras se actualiza con la cantidad de productos.
  • Cuando un artículo está agotado (registrado a través de un oyente que monitorea las cantidades de existencias actuales desde el back-end), la interfaz de usuario de la página se actualiza.

Tenga en cuenta que estas cosas suceden automáticamente y no es necesario actualizar la página para que aparezcan. En una entrevista, pídale al candidato que describa cómo aplicó la programación reactiva en una aplicación que desarrolló. Si el candidato describe soluciones que implican actualizar la página o llamar manualmente a ChangeDetectorRef.detectChanges() para actualizar un componente, considérelo como una bandera amarilla.

Trampas con Observables en Angular

Los desarrolladores con menos experiencia a veces pueden encontrar que el código que escriben en sus aplicaciones Angular no se ejecuta. Los desarrolladores experimentados de Angular pueden identificar una causa común: no hay suscripción en un Observable , un tipo de objeto principal en la programación reactiva. Solo con una suscripción se ejecutarán llamadas de back-end u otras reacciones.

Hay dos formas de crear suscripciones: los desarrolladores pueden usar la canalización async o el método de subscribe . Pero hay una advertencia: si los desarrolladores realizan una suscripción manual (con el método de subscribe ), el Observable deberá destruirse manualmente (aunque hay algunos casos extremos en los que sucede de forma predeterminada). Los desarrolladores pueden destruir Observables de varias maneras:

  • Usando la tubería async , donde sea posible (esto destruye el Observable cuando el componente ya no es necesario).
  • Cancelación manual de la unsubscribe mediante el método de cancelación de suscripción en un Observable al final de la vida útil del componente ( ngOnDestroy ).
  • De una forma más declarativa con el operador takeUntil dentro del operador de pipe y usando un sujeto (es decir, algo llamado destroy$ ). En este caso, el sujeto emite destroy$.next() al final de la vida útil del componente ( ngOnDestroy ). Después de recibir el evento de destrucción, el operador takeUntil ya no aceptará eventos del Observable al que está vinculado, por lo que su lógica de suscriptor ya no se activará. Para ver un ejemplo, consulte el operador takeUntil en la sección 2. Se puede exponer una funcionalidad similar con los operadores take y takeWhile .
  • Dado que las aplicaciones Angular cambiaron al compilador Ivy, también podemos usar anotaciones. La biblioteca until-destroy u otra biblioteca de terceros como SubSink se puede usar para cancelar sin problemas la suscripción a observables una vez que se destruye un componente.

Otro punto problemático potencial con la programación reactiva proviene de las fugas de memoria y las múltiples llamadas al back-end. Pregúntele al candidato si es consciente de estos problemas y cómo los resolvería normalmente. Las pérdidas de memoria pueden ocurrir si no se cancela la suscripción de Observable s como se describe anteriormente. Se pueden resolver varias llamadas al back-end debido a varias suscripciones en una llamada al back-end compartiendo el Observable .

Conozca el estado y cómo usarlo

Todas las aplicaciones de una sola página tienen un estado, y este estado está disponible en algún lugar del front-end. Pero, ¿qué es un estado, exactamente? Contiene todas las variables específicas de la experiencia de usuario actual. Por ejemplo, los detalles del usuario autenticado, como el nombre y la URL de la imagen de perfil, un elemento de menú específico seleccionado o una lista en pantalla, como una lista de elementos del carrito de compras.

En una aplicación Angular, hay tres tipos principales de estado frontal a considerar:

Estado Alcance
Solicitud Información general disponible para toda la aplicación, como usuarios autenticados, roles de usuario, elementos de menú o la cesta de la compra de un usuario. Todo lo que cambie en este estado cambiará para toda la aplicación.
Módulo Información disponible para todo el módulo donde se utiliza un servicio. Cada vez que un desarrollador reutiliza un módulo con proveedores, crea una nueva instancia de cada proveedor. El estado nunca se destruirá y solo se creará la primera vez que se utilice un proveedor determinado.
Componente Información disponible para un determinado componente. Los componentes son las partes más pequeñas de una aplicación. Una aplicación Angular puede tener varios estados de componentes, pero solo se podrá acceder a ellos a través de cada componente. El estado se creará cuando se cree el componente y se destruirá cuando se destruya el componente.

Una buena comprensión de qué estado es y cuándo se debe cargar o recargar es una de las habilidades clave que se deben buscar al contratar desarrolladores de Angular. Este es un territorio privilegiado para explorar si su equipo tiene la oportunidad de revisar algún código de ejemplo escrito por el candidato. Si el solicitante está utilizando una biblioteca para la gestión estatal:

  • Busque el uso de NgRx, Akita, NgXs o bibliotecas específicas de administración de estado similares.
  • Luego, mire para ver si hay notificaciones para effects , action , reducer , store y selector en el código relacionado.

Veamos el flujo general del estado de la aplicación en NgRx (que es similar al de Akita y otras bibliotecas) como ejemplo:

Un cuadro blanco de "Selector" en la parte superior izquierda apunta hacia abajo a un cuadro verde de "Componente" en la parte inferior izquierda, que apunta a la derecha a un cuadro blanco de "Acción" en capas. El cuadro "Acción" apunta hacia arriba a un cuadro "Reductor" en capas blanco y hacia la derecha (con una flecha punteada) a un cuadro "Efectos" en capas blanco. El cuadro "Reductor" apunta a un cuadro azul "Almacenar", que apunta a la izquierda al cuadro "Selector". En la parte inferior derecha, el cuadro "Efectos" apunta a la izquierda (con una flecha punteada) al cuadro "Acción" y hacia arriba a un cuadro verde "Servicio". El cuadro "Servicio" apunta hacia abajo al cuadro "Efectos" y hacia arriba a una pila de cilindros verdes. La pila de cilindros verde apunta hacia el cuadro "Servicio".

Si el desarrollador crea su propio estado con servicios, su competencia en la gestión del estado puede ser más difícil de identificar:

  • Busque referencias a las palabras state o effect .
  • Vea si el código está reaccionando a alguna acción, por ejemplo, si el usuario presiona el Botón A, el texto debería cambiar en la Pantalla B.

Preguntas para los entrevistadores sobre el estado

No siempre puede encontrar todo lo que necesita saber investigando el código de un solicitante. Agregue estas consultas a su lista de preguntas para investigar qué tan bien los posibles desarrolladores de Angular entienden el estado:

  • ¿Dónde ha usado state y cómo? Este es un punto de partida sólido para comprender su experiencia con el estado; no tenga miedo de sondear los detalles.
  • ¿Cómo se toma la decisión de usar o no una biblioteca? Es una buena señal si saben que no siempre es útil incluir una biblioteca estatal en una aplicación.
  • ¿Qué pondría dentro del estado, dónde lo pondría y cómo hace uso de un sistema de gestión estatal? Si dicen: "Pongo todo en mi estado de aplicación global", esta es una señal segura de que el desarrollador no es consciente de los efectos secundarios negativos que dicho sistema puede tener en una aplicación.

Los desarrolladores que comprendan los distintos tipos de estado evitarán estos efectos secundarios:

  • El estado que solo se aplica a un componente podría ser modificado o corrompido por otros componentes.
  • Los datos están anidados en el almacén, por lo que se vuelve difícil hacer un seguimiento de los datos y los datos se vuelven ilegibles para los humanos (para fines de depuración, intercambio de datos, etc.).
  • La edición de datos dentro de un formulario ya los emite al resto de la aplicación, mientras que solo debe enviarse a la tienda cuando se guardan los datos; en otras palabras, el resto de la aplicación podría estar consumiendo datos no válidos.

No pasa mucho tiempo antes de que la tienda global se convierta en un desastre desorganizado, y no está claro dónde se origina cada parte del desorden, lo que dificulta la depuración y el mantenimiento.

Comprender la importancia de las pruebas automatizadas

Las pruebas automatizadas deben considerarse tan importantes como la calidad del código para cualquier aplicación web de Angular. Una de las principales razones por las que los programadores escriben pruebas es para documentar su código: si un nuevo desarrollador se une a la empresa, la lógica comercial y ciertos flujos de la interfaz de usuario deben ser claros según las expectativas del conjunto de pruebas. Además, las pruebas automatizadas revelan errores al principio del desarrollo.

Hágale a su potencial desarrollador de Angular tres preguntas de prueba:

  • ¿Cuáles son sus pensamientos sobre las pruebas? Cualquier candidato al que no le importen las pruebas automatizadas debe dejar de ser considerado. Incluso si prefieren no usar el desarrollo basado en pruebas (TDD), los desarrolladores que no ven el valor de las pruebas automatizadas le costarán a su empresa el tiempo de prueba manual y, lo que es peor, el tiempo de inactividad del usuario final cuando aparecen regresiones a medida que se realizan cambios en una aplicación. tiempo extraordinario.
  • ¿En qué te enfocas cuando pruebas? En lugar de probar datos básicos como poder asignar valores a un campo o esforzarse por obtener métricas de cobertura de prueba específicas (es decir, una cobertura del 85 %), un gran desarrollador de Angular debe centrarse en probar la lógica empresarial central.
  • ¿Suele haber más pruebas E2E o más pruebas unitarias? ¿Por qué? Como aplicaciones front-end, las aplicaciones Angular pueden aprovechar dos tipos principales de pruebas automatizadas: pruebas unitarias y pruebas de extremo a extremo (E2E). Por lo general, un conjunto de pruebas tendrá muchas pruebas unitarias y menos pruebas E2E. Las pruebas unitarias son pequeñas, por lo que son rápidas de escribir y ejecutar. Las pruebas E2E son más grandes y más lentas. Advertencia justa: no todos los desarrolladores tendrán la misma opinión en cuanto a la proporción correcta de pruebas unitarias y E2E que se debe mantener. En realidad, depende de la complejidad de la aplicación que se está probando, e incluso entonces, la respuesta es discutible hasta cierto punto.

Un diagrama de flujo comienza en la parte superior izquierda, con un cuadro dividido en azul claro y verde. La parte azul claro tiene el texto "¿Qué piensas sobre las pruebas?" y la parte verde tiene el texto "¿Al candidato le importan las pruebas automatizadas?" Desde la parte verde, una flecha de "No" apunta a la derecha a un cuadro azul oscuro que dice "El candidato no tiene las habilidades adecuadas para las pruebas" y una flecha de "Sí" apunta a otro cuadro dividido. La parte azul claro del segundo cuadro tiene el texto "¿En qué te enfocas cuando pruebas?" y la parte verde tiene el texto "¿El candidato se enfoca en probar la lógica comercial clave (que va más allá de los porcentajes de cobertura de código)?" Desde la parte verde, una flecha de "No" apunta a la derecha a un cuadro azul oscuro que dice "Es posible que el candidato no tenga las habilidades adecuadas para las pruebas" y una flecha de "Sí" apunta a otro cuadro dividido. La parte azul claro del tercer cuadro tiene el texto "¿Por lo general, hay más pruebas E2E o más pruebas unitarias? ¿Por qué?" y la parte verde tiene el texto "¿Entiende el candidato la importancia y el propósito de las pruebas unitarias y de extremo a extremo?" Desde la parte verde, una flecha "No" apunta hacia arriba y hacia la derecha hacia el cuadro azul oscuro que dice "Es posible que el candidato no tenga las habilidades adecuadas para las pruebas" y una flecha "Sí" apunta hacia la derecha hacia un cuadro azul oscuro que dice "El candidato tiene las habilidades adecuadas para las pruebas". habilidades."
Una guía para probar las preguntas de la entrevista para los desarrolladores de Angular.

Marcos de pruebas angulares

Los desarrolladores angulares tienen opciones cuando se trata de marcos de prueba automatizados. Las pruebas unitarias se pueden realizar a través de Jest o Jasmine and Karma. Todo desarrollador de Angular debe estar familiarizado con Jasmine y Karma. Jest también es común: generalmente es más rápido y presenta opciones de prueba más avanzadas.

El estándar de prueba E2E para una aplicación de Angular es Transportador, la herramienta predeterminada generada por la CLI de Angular. Una alternativa es Cypress, un marco de prueba E2E prometedor con muchas opciones.

Asegúrese de que el candidato tenga un conocimiento profundo de al menos un marco de pruebas unitarias y un marco de pruebas E2E.

Mantenerse informado sobre las últimas versiones de Angular

Es posible que los grandes desarrolladores de Angular no siempre usen la última versión en desarrollo por varias razones, pero deben conocer el cronograma de lanzamiento de Angular para que puedan mantenerse al tanto de los cambios y estar preparados para cambiar. Una forma de evaluar esto es preguntarle al candidato si está familiarizado con la estrategia de lanzamiento de Angular. Angular tiene como objetivo un lanzamiento importante cada seis meses, generalmente alrededor de febrero y mayo. Una versión de Angular está bajo "soporte activo" durante los primeros seis meses después de su fecha de lanzamiento y está bajo "soporte a largo plazo" durante 12 meses después de su fecha de lanzamiento. Esta es una línea de tiempo bastante ajustada en comparación con otras tecnologías, por lo que es particularmente importante mantenerse actualizado.

También puede investigar un poco sobre la versión más reciente de Angular y preguntarle a su candidato sobre los beneficios de estas nuevas funciones. Por ejemplo, en el momento en que se lanzó Angular 14, es posible que le haya preguntado al candidato sobre:

  • Componentes independientes, que reducen la necesidad de módulos angulares. Los componentes independientes no se declaran en ningún NgModule existente y administran directamente sus propias dependencias. Como resultado, se puede depender de ellos directamente sin necesidad de un NgModule intermedio.
  • Formularios escritos, otra actualización importante en Angular 14, que establece la escritura estricta como predeterminada para los formularios reactivos angulares. Los formularios escritos garantizan que los valores dentro de FormControls , FormGroups y FormArrays sean seguros para tipos en toda la superficie de la API. Esto permite formas más seguras, especialmente para casos complejos profundamente anidados.

El próximo gran desarrollador de Angular para su equipo front-end

Cada proyecto y equipo de desarrollo web es diferente y otorgará una importancia diferente a los diversos aspectos de las habilidades y conocimientos de un desarrollador de Angular. Pero comprender los temas fundamentales que hemos presentado aquí permitirá que los gerentes de contratación participen de manera significativa en la contratación, incluso en las evaluaciones más técnicas.

El blog de ingeniería de Toptal agradece a Ramazan Yildiz por revisar los conceptos técnicos y los diagramas presentados en este artículo.