Cómo contratar desarrolladores angulares: habilidades y conocimientos clave para buscar
Publicado: 2022-09-14Con 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 undiv
- 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?"
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 elObservable
cuando el componente ya no es necesario). - Cancelación manual de la
unsubscribe
mediante el método de cancelación de suscripción en unObservable
al final de la vida útil del componente (ngOnDestroy
). - De una forma más declarativa con el operador
takeUntil
dentro del operador depipe
y usando un sujeto (es decir, algo llamadodestroy$
). En este caso, el sujeto emitedestroy$.next()
al final de la vida útil del componente (ngOnDestroy
). Después de recibir el evento de destrucción, el operadortakeUntil
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 operadorestake
ytakeWhile
. - 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
yselector
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:
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
oeffect
. - 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.
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 unNgModule
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
yFormArrays
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.