La mayoría de las clases en el colegio se centraban en:

• leer artículos sobre temas aleatorios, rara vez sobre algo que me interesara lo más mínimo
• estudiar teoría gramatical
• hacer ejercicios en los que se "practicaba" de una forma muy poco natural. Las conversaciones eran casi siempre con otros estudiantes, que eran tan incompetentes como yo en el idioma en cuestión.

La mayoría de las clases particulares eran más de lo mismo: una pérdida de tiempo, pero al menos estabas más expuesto al idioma.

Mi trayectoria en el estudio de idiomas

Empecé a aprender idiomas de forma típica: estudiando inglés en un colegio público, con un poco de ayuda en casa, y luego con clases en una escuela de idiomas. Sacaba buenas notas en el colegio, pero apenas era capaz de hablarlo.

Todo cambió cuando me pasé de una escuela de idiomas convencional a una que utilizaba un método directo, un enfoque en el que los alumnos hablaban durante la clase. Esto me ayudó a "soltarme" y por primera vez me desenvolví en el uso del vocabulario y las construcciones gramaticales en una conversación.

Por aquella época descubrí el software de repetición espaciada, una forma eficaz de entrenarme con el vocabulario. Me impresionó tanto la eficacia de aprender idiomas "a mi manera" que se convirtió en una afición; en una faceta que duró unos cuantos años. En esa temporada dejé de centrarme en el inglés y aprendí primero el francés partiendo de cero, y luego empecé de nuevo con el alemán, esta vez dispuesto a aprenderlo. En mi mejor momento hablaba bastante bien el alemán y el francés, y el uso de estos idiomas conformaba una parte importante de mi vida social, a pesar de que vivía en Cracovia (Polonia).

El último idioma en el que me apliqué seriamente fue el español, tras mudarme a España. Aunque ya no me fascinaba tanto aprender idiomas, el estar inmerso en una lengua y en una cultura nueva, me animó a aprenderlo y me motivó.

¿Cómo aprendería otro idioma ahora?

Aprendí a manejar los idiomas mientras estudiaba inglés, y luego pulí la técnica al estudiar francés, alemán y español. ¿Qué haría ahora si volviera a aprender idiomas?

Unas cuantas clases online a la semana

Ahora mismo hay tantas plataformas de enseñanza online - por ejemplo, italki, con las que tienes acceso a nativos de tu idioma de destino, donde quiera que vivas. Yo optaría por unas pocas clases a la semana. En caso de tener limitaciones de tiempo o dinero, las mantendría en 30 ó 45 minutos, pero espaciadas a lo largo de la semana para tener contacto con el idioma cada pocos días.

Como sé que no necesito muchas explicaciones teóricas, me decantaría por profesores más asequibles y no profesionales. No sólo es más barato, sino que ayuda a evitar que el profesor traiga manías de fábrica, como las que quería eludir en el colegio. Por ejemplo, pasar mucho tiempo comentando sutilezas gramaticales. Me encanta aprender bien la gramática, pero de manera intuitiva, no analítica.

Centrarse en la conversación

Mis clases serían únicamente de conversación. Las primeras frases que se aprenden son:

• "¿Cómo se dice ... ?"
• "¿Qué significa ...?"

De esta manera podemos empezar a dar clases en el nuevo idioma desde el primer día.

¿De qué hablaría? Lo ideal sería que tuviese suficientes intereses en común con mi profesor para que la conversación fluyera de forma natural. De no ser así, siempre habría temas relevantes:

• quién soy
• a qué me dedico
• qué planes tengo para el próximo fin de semana
• lo que he hecho recientemente
• las noticias que han acaparado las conversaciones últimamente - no cualquier noticia, sino aquéllas de las que no se puede evitar hablar

Éstos son precisamente los temas de los que hablarías si conocieses a alguien con quien pudieses practicar un nuevo idioma; la gente con la que te relacionas durante las vacaciones, tus suegros, las personas con las que socializas en el extranjero, etc.

Tomar notas

Siempre que mi profesor me enseñaba palabras o frases, las anotaba para poder repetirlas al salir de clase. Cuando aprendía español intensivamente, tenía una colección de notas pegadas en la pared que procuraba volver a leer varias veces al día. Éstas eran incluso útiles durante la clase en sí: si me olvidaba de una palabra nueva, podía simplemente identificarla entre mis notas.

Repetir con otro profesor

Lo ideal era que cada clase que tuviera a lo largo de la semana fuera con un profesor diferente. Así podía aprender algunos términos relativos a los temas que estaba estudiando con una persona y al día siguiente utilizar esas palabras al contarle la misma historia a otro profesor. Además, es menos probable que te quedes sin temas de conversación con alguien a quien ves una vez en semana en lugar de varias veces a la semana.

Utilizar software de vocabulario

La repetición espaciada es una forma estupenda de mejorar el rendimiento a la hora de aprender. La idea es repetir la palabra a medida que la memoria empieza a fallar; así, por un lado la retienes, pero a la vez no le dedicas demasiado tiempo. Este sistema se podría adaptar con fichas de cartulina, pero lo más eficaz es contar con una aplicación que lo haga por ti. Algunos ejemplos de programas son:

• SuperMemo - un programa de pago que utilicé mucho cuando aprendía inglés francés y alemán, o
• Anki - un programa gratuito y de código abierto, práctico sobre todo si quieres crear tus propias listas de vocabulario

En ambos casos, la aplicación te pregunta por palabras que ya deberías conocer, permitiéndote poder comprobarlo por ti mismo y autoevaluarte. En función del resultado, programará la repetición de ese término antes si has fallado, o más tarde si lo has acertado.

Las cosas que más me gustaron de aprender con SuperMemo fueron:

• los archivos de audio para todas las palabras y frases expuestas de ejemplo - para yo poder repetirlas, en lugar de tener que descifrar el alfabeto fonético
• el tamaño de sus bases de datos: las aplicaciones contenían miles de palabras para todos los niveles.
• la repetición espaciada

Desgraciadamente, hay menos material disponible para los idiomas menos comunes: así que para inglés o francés tendríamos innumerables recursos, pero para el polaco o el vasco no tanto.

¿Qué trucos tienes para aprender idiomas?

¿Cuál ha sido tu experiencia aprendiendo idiomas? ¿Tienes algún truco que quieras compartir con otros lectores? ¡Me encantaría leerlos en los comentarios!

Qué son las pruebas unitarias

Las pruebas son una forma de fijar explícitamente expectativas sobre el código. Las estableces para que la máquina compruebe si tu código cumple con las expectativas.

Es un programa que verifica tu programa. Normalmente, en los proyectos de JavaScript, usarás alguna biblioteca de pruebas, como:

• Jest,
• Jasmine, o
• Chai

Pero éstas son sólo herramientas. Lo que importa es que tengas alguna forma de validar automáticamente tu aplicación.

Cómo te ayudan las pruebas unitarias

Hay cuatro razones por las que escribir pruebas te facilitará la vida a la hora de codificar:

1. Es una forma rápida y fiable de comprobar si el código funciona como se esperaba. No tienes que pensar en casos límite para tenerlos todos cubiertos por pruebas unitarias.
2. Una buena cobertura de pruebas es una red de seguridad que te permite refactorizar el código con más arrojo. Así es más probable que tomes las medidas necesarias para mantener tu código base en buenas condiciones.
3. Escribir pruebas unitarias te obliga a pensar en las unidades y en cómo se debe repartir la carga entre ellas, lo que hace que tu código sea más modular y más fácil de mantener.
4. Las pruebas unitarias pueden convertirte en un programador más rápido. Al principio, tienes que invertir tiempo en crear el caso de prueba, pero una vez que está listo, puedes volver a ejecutarlo de forma muy económica. La inversión puede pagar dividendos incluso durante el desarrollo inicial.

Construir un andamiaje

Antes de probar la funcionalidad, asegúrate de que puedes probar cualquier cosa. Instala la biblioteca de pruebas y crea tu script de pruebas. Una vez que tengas algo en marcha, puedes empezar a configurar el andamiaje para algunas de tus pruebas. Tienes que tomar una decisión sobre la nomenclatura. Por ejemplo, si tu código es mi-proyecto/plane-ticket.js, tu código de pruebas puede ubicarse en mi-proyecto/plane-ticket.spec.js.

Construye todo lo necesario para probar una clase cualquiera y luego comprueba algunos aspectos comunes:

• si un objeto es un objeto, o
• si una función es una función

De esta manera, demostrarás que puedes probar cosas.

Configurar los mocks

Los mocks son objetos creados para reemplazar las dependencias de la unidad que estás probando. Por ejemplo, si pruebas la función saveBlogPost, querrás interceptar la petición HTTP antes de que la función la envíe. Querrás averiguar qué utiliza tu función para enviar la petición y sustituirlo por un mock. Esto debería ser fácil si construyes tu código usando un patrón de inyección de dependencia.

Mantener una estructura

Como podrás ver, en cada prueba ocurren muchas cosas. Se pueden distinguir tres fases principales:

1. Configuración de los mocks
2. Ejecución del código que se quiere comprobar
3. Comprobación de las expectativas

Es lógico mantener esta separación en tu código; será más fácil de leer de esta manera. Una forma fácil de organizarlo es agrupando todas las líneas y quizás añadiendo un comentario especificando de qué parte se trata.

Desarrollo guiado por pruebas

El desarrollo guiado por pruebas es un procedimiento común para crear un buen código con una buena cobertura de pruebas. Empiezas añadiendo una prueba para una función antes de que se implemente. Ejecutadas las pruebas, debería de fallar - si no es así, algo grave estará pasando y tendrás que investigar qué es. Las pruebas fallan y agregas al código la implementación que falta. Una vez más, se espera que esto por sí solo solucione el fallo. Si todo va bien, inviertes un poco de tiempo en optimizar tu solución, tanto en el código como en las pruebas, sin cambiar la lógica. Esta forma de proceder te permite iterar rápidamente en la creación del código y sus pruebas.

Si sigues esta práctica, nunca se te podrá escapar ninguna prueba para tu lógica. No tendrás la tentación de saltarte la escritura de pruebas, un problema común cuando se deja la escritura de pruebas para el final.

Contra-recomendación

Para ser un líder, hay que saber a dónde vas. Deja de lado las pruebas durante un tiempo si necesitas explorar qué soluciones son factibles. Una vez que tengas claro el camino, puedes agregar pruebas o abordar el problema de nuevo de una manera guiada por pruebas.

Pruebas que faltan

Si tienes mala suerte, puede que estés trabajando con código heredado sin pruebas ni otras medidas de calidad, algo así como lo que describo aquí. En tal caso, más vale tarde que nunca; puedes empezar a escribir pruebas a medida que trabajas con el código base. De esta manera, mejoras la situación de cara a un futuro y en algunos casos excepcionales, tal vez encuentres algún error oculto.

¿Y tú?

¿Cómo de difícil te parece aprender a probar? He visto quejas en Internet de personas a las que les cuesta encontrar buenos recursos para ello. Cuéntame qué experiencias has tenido hasta ahora.

Cíñete a lo que conoces mejor

Puede resultar tentador matar dos pájaros de un tiro e intentar aprender o practicar alguna tecnología nueva mientras solicitas un empleo. Sin duda a mí me ha resultado tentador en algún momento. Pero no es así como generarás el mejor código. Es mejor ceñirse a lo que mejor conoces y aprender cosas nuevas en un proyecto diferente.

Ya sabes qué opción te resultará en una mejor oferta.

Hazlo fácil de revisar

Asegúrate de que lo que entregas es fácil de revisar. El flujo ideal desde el punto de vista del revisor sería:

• obtener un enlace que funcione
• constatar por sí mismo que la aplicación funciona como se espera
• profundizar en el código para ver cómo has conseguido lo que has hecho

Revisar el código sin constatar si funciona carece de sentido. No me va a importar mucho el aspecto de tu código antes de comprobar si cumple con lo que se espera. Y si no está claro que funcione bien, puede que nunca me moleste en revisarlo en profundidad.

Dales todo en bandeja de plata

Ofrece algo interactivo

Para una aplicación de interfaz, la solución más fácil es desplegarla en uno de los servidores gratuitos que están al alcance:

• Páginas de GitHub,
• Páginas de GitLab, o
• Netlify.

Nunca envíes archivos ZIP

El envío de archivos ZIP tiene dos desventajas que por sí solas podrían romper el acuerdo:

• es un inconveniente
• abrir un archivo ZIP supone un riesgo de seguridad

¡Puede ser divertido abrirlo!

Asegúrate de que funciona

Y que funcione en varios navegadores y dispositivos. No tiene que ser súper bonito, pero debe ser funcional, independientemente de que los revisores estén sentados frente al ordenador o en un autobús con su teléfono.

Agrega README.md

Cualquier proyecto que tengas precisa de un README, y con mayor razón si se trata de una tarea para una entrevista. Debes presentar brevemente el ejercicio que pones en marcha y enlazarlo a una aplicación utilizable. A continuación, puedes añadir algo de documentación de alto nivel: qué marco de trabajo has usado y cómo construir o probar tu código.

Muestra cómo piensas

Comparte con el revisor tu proceso de razonamiento. Si utilizas algunos patrones o mejores prácticas, haz referencia a ellos explícitamente en la documentación. Si has tenido alguna disyuntiva, descríbela y explica por qué has elegido la forma que has usado para realizar tu trabajo.

Hazlo brillar

Si quieres destacar, puedes considerar añadir algunas de las siguientes cosas. Probablemente se salga un poco del objetivo de lo que requería la tarea, pero demuestra que conoces las labores que vas a realizar cada día en tu trabajo.

Haz que sea atractivo

Agrega algunas rutas a tu proyecto. Puedes conseguir la atención del revisor durante un poco más de tiempo si tienes páginas adicionales. ¿Tal vez un breve /sobre para que puedan relacionar fácilmente esta aplicación de demostración con tu CV?

Pruebas unitarias

La puesta en marcha de pruebas unitarias puede ser un gran ejemplo que indica que eres un desarrollador centrado en la calidad. No tienes que apuntar a una cobertura completa de pruebas de código: debería de ser suficiente con unas pocas pruebas que demuestren que sabes lo que es.

Configurar lint y prettier

Muchos equipos profesionales utilizan linters y herramientas automatizadas para imponer el estilo de código elegido. En el caso de la interfaz, lo más común es que se trate de ESLint y Prettier. Puedes darle un toque bonito si presumes de lo mismo en tu proyecto - si en el equipo hay algún desarrollador centrado en la consistencia, seguro que se dará cuenta.

Realizar commits significativos

Git (o en general, el control de versiones) es una herramienta fundamental para el trabajo en conjunto en proyectos de TI. El equipo colabora en el repositorio de Git, por lo que es primordial tener buenos mensajes de commit. Si creas un historial que tenga sentido para un borrador de proyecto, puede ser un buen indicativo del aspecto de tus contribuciones para la empresa.

¿Y tú?

¿Cuál es tu mejor proyecto de demostración? ¡Comparte los enlaces en los comentarios!

• un amable compañero de trabajo con más experiencia
• un amigo servicial
• un mentor externo—gratuito o de pago

¿Cómo puedes asegurarte de aprovechar al máximo esta ayuda?

Desarrollador Senior de JS

Trae tus verdaderos problemas

Tu mentor tiene mucha más experiencia laboral que tú. Puede compartir sus conocimientos contigo, siempre que plantees los problemas que te preocupan. Por ejemplo:

• si te enfrentas a algún reto técnico, puede recomendarte otro enfoque, o
• si chocas con algún compañero de trabajo, puede evaluar la situación y ayudarte a averiguar cómo abordarla en el futuro, o
• si estás abrumado con opciones para una biblioteca, puede ayudarte a elegir y comprometerte con una de las opciones, o
• si tu situación laboral no es óptima, puede ayudarte a preparar una negociación salarial o a buscar un trabajo nuevo. Para esto, probablemente lo mejor es que tu mentor sea alguien ajeno a tu empresa actual.

Haz tus deberes

La mentoría es divertida si el aprendiz -tú- es receptivo. Presta atención a las sugerencias de tu mentor. Si te recomienda un artículo, léelo. Si te recomienda un libro o un curso, hazte con un ejemplar y síguelo. Si recibes comentarios sobre la revisión del código, como mínimo involúcrate en la propuesta: comenta sobre sus ventajas y desventajas, aunque no tengas tiempo de seguirla.

Trata a tu mentor como tratarías a un búho.

Mientras estudias

Si no tienes problemas reales de trabajo, puedes inventarte algunos. Mientras trabajas en un proyecto personal, puedes pedirle a tu mentor que revise tu código. Lo mejor sería trabajar en público. El flujo de trabajo que podrías utilizar es:

1. Realizas la primera implementación por tu cuenta
2. Tu mentor te da sugerencias y comentarios
3. Pones en práctica lo anterior

Al hacerlo en público, se transmiten tres fuertes indicios a un posible empleador:

• estás lo suficientemente comprometido para ejecutar un proyecto
• cuentas con ayuda externa y no dependes sólo de los recursos del empleador para progresar.
• demuestras lo bien que aceptas y pones en marcha los comentarios y sugerencias

¿Y tú?

¿Cuál ha sido tu relación con la mentoría hasta ahora? ¡Comparte tu experiencia en los comentarios!

Iterar

Avanzar en pasos pequeños y manejables es una piedra angular en muchas metodologías comunes en nuestra industria:

• agile– se trata de iterar con los cambios en el producto para descubrir qué necesitan los clientes, mientras que
• producto mínimo viable (MVP) – tiene como objetivo crear la primera versión que se puede comparar con el mercado, y luego se itera desde allí.

Veamos cómo usar un enfoque similar en su vida diaria.

Mientras aprende

La mejor idea sería:

• aprender una parte del material, y luego
• usarlo.

El material de trabajo te presentará regularmente desafíos para aplicar y probar tu conocimiento en un curso o libro bien organizado. Si aprendes sin ese lujo, necesitarás crear esos ejercicios por ti mismo. En ambos casos, la mejor respuesta que puedes obtener es que tu código funciona como se espera—por lo que debes usar lo que estás aprendiendo en tu proyecto paralelo o comenzar uno nuevo.

Mientras trabaja en un ticket

¿A menudo te quedas atascado en un ticket? Lo más probable es que estés tratando de hacer demasiadas cosas al mismo tiempo. Por lo general, puedes dividir una tarea en:

• refactorizar el código en el que estás a punto de trabajar
• Agregar infraestructura de código—métodos auxiliares, tipos de actualización, etc.
• hacer los cambios en la lógica de la aplicación
• agregando pruebas de extremo a extremo para la nueva función

En la mayoría de los casos, tiene más sentido hacer cada parte en commit separados: no quieres revisar o revertir las refactorizaciones con una nueva implementación. Dividir las cosas en commit separados , y tal vez incluso en pull request , le permite obtener una revisión de su código más rápido, lo que acelera su progreso.

¿Qué debes hacer si no conoces el código lo suficientemente bien como para planificar tus acciones con anticipación, o simplemente lo olvidaste y tienes todos los cambios realizados simultáneamente? No te preocupes , el conocimiento que obtuviste durante el primer intento no se desperdiciará—ahora, puedes dar un paso atrás, comenzar una nueva rama y aplicar o rehacer parte del gran commit que comenzaste.

Mientras haces proyectos

No importa si trabajas en proyectos comerciales o de código abierto—escucha el mismo mantra en todas partes:

• "Publicar temprano, publicar a menudo."
• "Muévete rápido y rompe cosas."

Incluso si estás trabajando en algún proyecto de aprendizaje personal, puedes aplicar esta mentalidad. En lugar de planificar una gran versión final de tu proyecto, intenta simplificar lo que estás construyendo al mínimo. Puedes encontrar algunos ejemplos en mi artículo sobre el aprendizaje con proyectos personales.

Evita caer en la madriguera del conejo

Su principal objetivo al hacer las cosas en iteraciones es evitar caer en una madriguera de conejo. Es bueno pasar tiempo investigando cosas; y como desarrollador, debes ser resistente a la frustración de no saber cómo funciona algo o cómo corregir un error. Lo malo es que la misma fuerza ante la frustración a veces juega en tu contra. En algún momento, los rendimientos de la inversión de pasar más tiempo disminuyen hasta el punto en que solo estarás perdiendo el tiempo. Estarás muy involucrado en el problema y ya estarás involucrado en solucionarlo cuando suceda, por lo que dejarlo ir no será fácil. ¡Veamos cómo puedes evitar estas trampas!

No estás solo

En la mayoría de los casos, no estás trabajando solo: hay otras personas a tu alrededor que pueden ayudarte. Como principiante, tienes dos posibles maneras de fallar:

• buscar ayuda demasiado rápido
• buscar ayuda demasiado tarde

¿Qué es demasiado tarde o demasiado rápido? Bueno, eso depende de la situación en la que se encuentre tu equipo. Puedo imaginar fácilmente dos extremos:

• tu equipo está bajo mucha presión—una emergencia de algún tipo, por lo que no hay ningún desarrollador experimentado disponible para ayudarlo
• está reemplazando a un desarrollador que se va en 2 semanas, por lo que la prioridad es obtener el mayor conocimiento posible de ellos

Mi consejo es encontrar reglas explícitas con su equipo y luego apegarse a ellas. Entonces, si estás de acuerdo en que cuatro horas de golpearse la cabeza contra la pared con un ticket es demasiado, después de cuatro horas, busca ayuda.

Aprende cómo dejarlo

No es una idea mejor solo porque pasaste tantas horas implementándola. En todo caso, demostró que el enfoque no es factible o no es tan fácil como se esperaba. Evita la falacia del costo irrecuperable: la estrategia excelente es estimar, antes de comenzar, cuánto tiempo desea dedicar a una tarea antes de dejarla atrás, y luego apegarse a esa estimación. Dependiendo del ticket, dejarlo puede significar dejar que otro desarrollador lo recoja o no hacerlo todo junto, al menos ahora.

Busca siempre retroalimentación

Cada paso de la interacción es un punto en el que podemos y debemos recibir retroalimentación. Nos permitirá hacer algunas correcciones de rumbo y asegurarnos de que estamos en el camino correcto. Hay muchos tipos de comentarios que podríamos buscar:

• pruebas automatizadas que pasan localmente o en CI
• colega más experimentado o su mentor revisando el código
• presentar nuestro producto externamente y recopilar comentarios

¿Quieres aprender más? Consulta mi otro artículo sobre retroalimentación.

• aprender,
• la creación de una aplicación de trabajo, o
• ganar dinero,

entonces se trata de un sistema de control no trivial. Echemos un vistazo a las características clave de un ciclo de retroalimentación efectivo y cómo puedes usarlo en tu carrera de TI.

Cuanto más rápido, mejor

Cuanto antes sepas si las cosas van bien o mal, mejor. No hay ninguna ventaja en avanzar en la oscuridad. Si ya estás en un buen camino, la retroalimentación reforzará tu compromiso con lo que haces ahora. Si estás haciendo algo mal, puedes corregir tu curso cuando recibas comentarios. Imaginate lo complejo que sería conducir o andar en bicicleta si tu visión se retrasara incluso una fracción de segundo. Sería suficiente para producir efectos similares a conducir ebrio.

Dependiendo de la complejidad del sistema, actuar sobre ese conocimiento aún puede requerir tiempo. Si notas que tu carrera actual no es para ti , aún necesitarás algunos años para obtener una nueva. Pero preferirías saber esto durante tu primer semestre en la universidad en lugar de después de graduarte.

Tus bucles de retroalimentación diarios

Pensemos por un momento en todos los ciclos de retroalimentación de los que formas parte todos los días como desarrollador.

Cambios en el código

A medida que trabajas en el código, debes verificar el impacto de tus cambios en el comportamiento del código. Las pruebas automatizadas son una forma rápida y sólida de obtener retroalimentación. Escribir pruebas lleva tiempo al principio, pero te permite ser más productivo a largo plazo. Eso es incluso sin considerar el impacto de calidad a largo plazo de mantenerlos cerca.

Con lógica compleja, a menudo prefiero comenzar con pruebas. Simplemente entender todos los detalles internos es difícil, y preferiría hacerlo una vez mientras escribo las pruebas y no cada vez que cambio algo en el código.

Trabajo diario en un ticket

Si estás trabajando en un equipo bien organizado, algunos otros miembros del equipo revisarán tu trabajo. Tener tu trabajo revisado es una excelente manera de aprender la forma en que el equipo hace las cosas, así como aprender más sobre el arte de la programación. Pero puede ser frustrante si pasas uno o dos días trabajando en un ticket y luego recibes más de 40 comentarios en la solicitud de extracción.

Puedes acelerar los comentarios que recibes dividiendo el trabajo en pequeños pasos y solicitando comentarios después de cada uno de ellos:

1. Después de leer un ticket, explicalo a alguien que entienda bien de qué se trata. Si no lo entendiste bien, podrán corregirte.
2. Escribe cómo planeas abordar la solución—y haz que otro desarrollador la revise antes de dedicar tiempo a implementarla. Tal vez te señalen algo que no sabías.
3. Sin embargo, lo más importante es la retroalimentación sobre la lógica del programa. Solicita una revisión mientras aún estás realizando las pruebas.

Versión de la aplicación

A medida que avanza el sprint, hay una pila creciente de cambios inéditos que esperan ser publicados. Tendría sentido esperar solo si tiene un protocolo de prueba elaborado y si este tiempo está bien empleado. Si no se realizan pruebas significativas, solo está retrasando los comentarios de los usuarios. Cuando sea posible, intente implementar con la mayor frecuencia posible. De esta manera, en lugar de un gran lanzamiento con todos los cambios (y errores) que realizó su equipo en unas pocas semanas de sprint, publica una pequeña parte cada pocos días.

Adecuación al mercado del producto

Incluso en una escala mayor, esto todavía se aplica. Con metodologías como Agile o Lean Startup, el objetivo es sacar tu producto lo antes posible y obtener retroalimentación del mercado.

¿Qué pasa con la calidad de la retroalimentación?

No toda la retroalimentación es igual. Siempre está en algún lugar del espectro—desde los resultados precisos de las pruebas, hasta la opinión subjetiva de la persona que la escribió. En el caso de información objetiva, como

• las pruebas fallan o las funciones fallan,
• las aplicaciones son perceptiblemente lentas, u
• otros indicadores de desempeño están fuera de los valores esperados,

a menudo es una buena idea comenzar a abordarlo de inmediato.

En caso de opinión subjetiva:

• manera de codificación
• denominación de variables o métodos
• cualquier otra cosa que diferentes desarrolladores puedan arreglar de una manera diferente

Aquí las cosas son más sutiles. Podría estar yendo en contra de una convención bien establecida en el proyecto, o su nombre podría ser confuso—cosas que es mejor arreglar pronto. Por otro lado, a veces las personas comparten cómo harían las cosas, pero más teniendo una conversación sobre cómo se deberían hacer las cosas en el proyecto.

¿Y tu?

¿Alguna vez has recibido comentarios que dieron forma a tu carrera? Por favor comparte tu historia en los comentarios; ¡Me encantaría oírlo!

La aplicación de ejemplo

Para que sea sencillo , usaré una aplicación generada con Create React App (CRA) como aplicación de ejemplo. De esta forma, obtenemos una aplicación no trivial que:

• es similar a casos simples del mundo real,
• tiene algunas dependencias npm, y
• la mayor parte de lo que necesitamos ya está configurado.

La aplicación resultante se ve así:

Pasos de verificación

Anteriormente escribí sobre qué pasos puede ejecutar con su CI. Veamos cómo puede configurarlo para nuestra aplicación de ejemplo.

Construcción

Para construir, el código generado por CRA hace todo lo que necesitamos:

$ npm run build

> netlify-ci@0.1.0 build
> react-scripts build

Creating an optimized production build...
Compiled successfully.

File sizes after gzip:

  43.71 kB  build/static/js/main.1fb16459.js
  1.78 kB   build/static/js/787.c84d5573.chunk.js
  541 B     build/static/css/main.073c9b0a.css
…

Netlify selecciona automáticamente la secuencia de comandos construir de nuestro repositorio generado por CRA como un comando de compilación, y funciona perfectamente:

Pruebas

El código generado por CRA viene con una configuración completa para pruebas unitarias y una prueba de ejemplo. El script npm test está hecho para desarrollo; se ejecuta en modo interactivo y observa los archivos de forma predeterminada. Para ejecutar en CI, necesitamos una sola ejecución:

$ npm test -- --watchAll=false

> netlify-ci@0.1.0 test
> react-scripts test "--watchAll=false"

 PASS  src/App.test.js
  ✓ renders learn react link (16 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.644 s, estimated 1 s
Ran all test suites.

Para tenerlo disponible, definamos un nuevo script en package.json:

{
  …
  "scripts": {
    …
    "test": "react-scripts test",
    "test:ci": "react-scripts test --watchAll=false",
    …
  },

Análisis estático

Una cosa que nos gustaría agregar al código es el análisis estático. La configuración básica debería ser bastante sencilla, pero la dejaré fuera del alcance de este artículo. Si quieres hacer un seguimiento de esto, te recomiendo que lo pruebes con:

• ESLint – ya que advierte sobre posibles problemas en el código, o
• Prettier – para hacer cumplir automáticamente el estilo del código.

Nueva secuencia de comandos CI

Con el código que tenemos ahora, necesitamos los siguientes pasos para una ejecución exitosa de CI/CD:

• npm install – obtiene las dependencias del paquete, hecho por defecto por Netlify
• npm run test:ci – nuestro comando de prueba modificado
• npm run build – el comando de compilación original
• implementación – realizada por Netlify

Ahora, queremos que la compilación sea condicional en función de las pruebas: si fallan, la ejecución debería detenerse, y por eso use ‘&&’. Al mismo tiempo, la configuración de Netlify solo tiene una entrada para ejecutar el comando. Podemos abordar esas dos cosas creando un nuevo script dedicado a este caso de uso:

{
  …
  "scripts": {
    …
    "test:ci": "react-scripts test --watchAll=false",
    "ci": "npm run test:ci && npm run build",
    …
  },
  …
}

Ejemplo de ejecución

Al final, los scripts se comportan como se esperaba:

• si fallan las pruebas de compilación, obtendrá una ejecución fallida en su tablero de Netlify
• si todo funciona como se esperaba, la aplicación se implementa

El uso de recursos

En las pocas ejecuciones que hice, apenas hubo impacto de las pruebas en el tiempo de compilación—el recurso que Netlify verifica para controlar el uso del sistema. Por supuesto, esto cambiará cuando su proyecto crezca y añadirá más pruebas a su proyecto. En algún momento, tendrá más sentido invertir en configurar una solución de CI dedicada y usar Netlify solo como alojamiento.

Enlaces

• aplicación implementada
• repositorio de ejemplo

¿Qué harías después?

Ejecutar CI en Netlify es solo una solución temporal. Estoy interesado en saber de ti —¿qué herramienta te gustaría usar a continuación? Házmelo saber en esta encuesta:

Compañera de trabajo diligente

Puedes pensar en CI como un compañero de trabajo diligente que siempre está ahí, esperando para verificar tus cambios antes de fusionarlos con la rama principal. Es una buena idea incluir solicitudes de combinación en su flujo de trabajo cuando CI está en su lugar, incluso si trabaja solo en el proyecto. Sus cambios serán revisados por la máquina, y dejarlos en una rama separada le permite solucionar cualquier problema antes de fusionarse con la rama principal.

Sin CI, todos y cada uno de los desarrolladores son responsables de verificar todos sus propios cambios. Por supuesto, de vez en cuando alguien lo olvidará —tal vez los cambios originales estaban bien, pero ¿qué pasa si después de una reorganización o fusión tienes un problema? Sin CI, permites que tus colegas menos cuidadosos empujen y se olviden de sus cambios, y otros se ven obligados a limpiar después de ellos.

Cómo está estructurado CI

La integración continua comprueba tus confirmaciones. Por cada cambio de código, CI generalmente ejecuta algunas tareas diferentes en un orden definido. Puedes utilizar la salida de un trabajo como entrada en otro; por ejemplo, puedes crear una aplicación en un paso y luego usar el paquete resultante en otro para realizar pruebas. Por lo general, administra CI con un archivo de configuración que se encuentra dentro del repositorio; por lo tanto, tu CI puede evolucionar junto con tu base de código.

Si todas las tareas pasan, entonces el commit será aprobado ; si alguno de ellos falla, entonces el commit será fallo . En una situación ideal, el contenido de confirmación por sí solo determina el resultado de CI: no depende de servicios externos y no hay ningún elemento aleatorio que pueda hacer que falle.

Para cada rama, CI muestra el resultado de la confirmación superior. La rama principal debe estar casi siempre de paso; cualquier problema afectará a todos en el equipo, por lo que solucionarlo debería ser una prioridad si ocurre alguna regresión. Para una rama de características, debe fusionarla solo si ha sido aprobado por el CI.

Tareas que puede delegar a su CI

Puedes configurar cualquier script que se ejecute en tu entorno local en CI. La lista puede ser larga en proyectos grandes, pero echemos un vistazo a las tareas de CI que puede esperar en proyectos de cualquier tamaño.

Construcción

La verificación más básica que puede realizar en su base de código: ¿compila? Es un paso que detectará cualquier dependencia que se instaló, pero no se guardó, cualquier discrepancia de tipo de script mecanografiado que se coló en el commit. Estas son soluciones fáciles mientras el desarrollador está en la tarea, pero esos errores pueden volverse confusos o molestos si se comparten con otros.

Análisis estático

El análisis estático implica verificar su código sin ejecutarlo. En los proyectos frontend, a menudo puede ver herramientas como:

• ESLint
• HTMLHint
• Stylelint

Esos programas son los más útiles cuando se integran con el editor de código. Ejecutarlos en CI es una verificación adicional que puede ayudarlo de dos maneras:

• identificará a cualquier desarrollador que se olvide de ejecutarlos localmente —por lo que se les puede pedir que lo hagan antes de que arruinen una gran cantidad de código
• identificará cualquier desajuste de versión o configuración que pueda ocurrir entre los diferentes entornos de desarrollo

Ejecutando pruebas

Tener un CI implementado y ejecutar pruebas en él es esencial si se toma en serio las pruebas automatizadas en su aplicación. El objetivo de las pruebas automatizadas es ejecutarlas con mucha frecuencia —¿Qué mejor momento para hacerlo que cuando algunos cambios en el código están a punto de hacerse públicos? No hacerlo es una invitación a un escenario en el que:

• un desarrollador introduce la regresión en el código
• otros agregan cambios no relacionados encima
• alguien finalmente ejecuta las pruebas que capturan la regresión original
• pierden el tiempo resolviendo problemas que no causaron, relacionados con cambios de los que potencialmente no están al tanto

En este escenario, el problema principal es que a medida que solucionas el problema, ni siquiera sabes cuándo se presentó; podrías estar en un compromiso anterior, o hace una semana. Podrías usar git blame o git bisect para salir de eso, pero es mucho más fácil saber simplemente el punto en el que las pruebas dejaron de funcionar.

Permíteme enfatizar otra cosa: escribir pruebas es una inversión en garantía de calidad. Es un esfuerzo del día a día. Si estás realizando este esfuerzo diario, tiene sentido dedicar tiempo, solo una vez, a configurar CI para aprovechar al máximo las pruebas que desarrolla.

Desplegando

A menudo verá CI junto con implementación continua (CD), abreviados juntos como CI/CD. Esto se debe a que mientras compila y verifica su código, tiene todo listo para implementar —al menos en el servidor de prueba. Un verdadero CD requeriría que lo entregues a producción, pero esto puede ser más desafiante, especialmente porque expone a los usuarios del proyecto a posibles regresiones.

Desventajas

¿Cuáles son las desventajas de CI?

Configuración complicada

La configuración puede llevar mucho tiempo, especialmente si nunca lo has hecho antes. Incluso los cambios más sencillos en la configuración pueden tardar un tiempo considerable en verificarse, ya que debe ejecutarlos en un servidor externo al que no tienes acceso directo.

Dependencia de un proveedor externo

Si integras Ci en tu flujo de trabajo, dependerás de tu proveedor de CI. Si están caídos, no puede fusionarse —al menos no con toda la red de seguridad a la que estás acostumbrado. Puede ser frustrante, especialmente si sucede con cierta frecuencia.

Costo

Muchos proveedores de CI tienen un plan gratuito que debería ser más que suficiente para ejercicios simples o proyectos de demostración. Para un proyecto en el que las personas trabajan a tiempo completo, es casi seguro que necesitarás un plan de pago, más tiempo adicional para que las máquinas de CI ejecuten sus scripts. El costo probablemente valdrá la pena, incluso si asume que el CI ahorra solo unos minutos por día para cada desarrollador de su equipo.

¿Y tú?

¿Estás interesado en obtener más información sobre cómo configurar CI? ¡Cuéntamelo en la encuesta! Estoy pensando en escribir algunas publicaciones más detalladas sobre la configuración de las herramientas de CI. Al saber qué herramienta te interesa más, puedo crear contenido que coincida con tus expectativas. ¡Así que, por favor, vota en la [encuesta] (https://strawpoll.com/co8pv72pr) a continuación! ⬇️⬇️⬇️️ Tu opinión es muy importante para mí. ¡Gracias!

¿Qué sigue?

Para obtener aún más valor de tu CI, ejecuta pruebas de extremo a extremo (E2E) en él. Configurar E2E en CI es un desafío y lo trataré en otro artículo. Mientras tanto, puedes ver cómo [comenzar con E2E] (https://conoce.dev/como-agregar-pruebas-de-extremo-a-extremo-a-un-proyecto).

Menos archivos JS

Históricamente, la cantidad de archivos JS utilizados por un sitio web era crucial debido a la penalización en el rendimiento de tener muchos archivos pequeños. Los navegadores cargaron cada archivo con una solicitud HTTP separada. Cada solicitud necesitaba una conexión entre el navegador y el servidor, y se necesitaba tiempo para establecerla. Gracias a HTTP/2, la cantidad de archivos es un problema mucho menor ahora. Aun así, tener archivos agrupados tiene sentido. Cada solicitud se almacena en caché por separado, por lo que tener muchos archivos hace que sea más difícil garantizar que el navegador no obtenga código obsoleto del caché.

Además de eso, hasta 2018, muchos navegadores no admitían módulos ES. Simplemente estaba cargando muchos archivos desde el HTML, y todos compartían el mismo alcance global. Los paquetes de JS abordan ambos problemas, ya que

• te permite mantener tu código base en muchos archivos bien definidos y
• agrupar el código en archivos grandes para su implementación.

Fácil importación desde node_modules

Los paquetes te brindan una forma de importar dependencias, que es mucho mejor que cargarlos como módulos ES. Para usar paquetes de node desde el navegador, necesitarías

• implementar node_modules en su servidor de producción, y
• use una ruta relativa desde tuarchivo al archivo que desea importar La ruta relativa es un gran dolor de cabeza porque te obliga a escribir la importación de forma ligeramente diferente dependiendo de qué tan profundo estés en la estructura de carpetas. Entonces, para usar Lodash, tendrías que:

// en ./src/core.js 
var _ = require('../node_modules/lodash/lodash.js');

// en ./src/app/main.js
var _ = require('../../node_modules/lodash/lodash.js');

Los empaquetadores te permiten escribir simplemente:

// en cualquier lugar
var _ = require('lodash');

Importar otros tipos de archivos

Tu código base no es solo JavaScript. Cuando organices tu código por componentes o rutas, cada uno vendrá con su propia plantilla y estilo. Los módulos nativos de ES no le permiten importar tipos de recursos que no sean JS. Esta limitación le haría importar el CSS del HTML, mientras que el resto del componente se importa en JavaScript —lo que le obligaría a mantener sincronizados dos archivos no relacionados. Los paquetes JS solucionan este problema al permitirle administrar todas esas dependencias directamente desde sus archivos JS:

import ‘./core.js’;
import ‘./style.css’;

const template = require(‘./view.html’);

Transpilar código

Una gran cantidad de JavaScript no es JavaScript simple; está escrito en lenguajes como TypeScript y luego compilado en JavaScript. Esta compilación de código a código se llama transpilación. La mayor parte del JavaScript se transpila por varias razones.

Minificación de código

Si estás escribiendo tu código como deberías, estás haciendo lo siguiente:

• dar nombres significativos a las variables
• sangrado del código
• dejando comentarios para otros desarrolladores

Esto agrega desorden que no significa nada para el intérprete. La minificación es el primer paso para reducir el tamaño de la carga útil. Elimina todo lo que no tiene impacto en su aplicación.

Versión anterior para navegadores más antiguos

A medida que el lenguaje recibe nuevas características, existe este período durante el cual

• los desarrolladores ya quieren usarlo, y
• no todos los navegadores lo admiten.

Afortunadamente, este período se está acortando significativamente gracias a los evergreen browsers, pero aún existe la necesidad de un proyecto como Babel. Babel te permite usar la versión de idioma más reciente mientras codifica y transpilarla a una versión que entenderá el navegador anterior.

Sabores de JavaScript

Además del JavaScript simple, puede usar muchos de sus sabores:

• TypeScript
• PureScript
• Elm
• CoffeeScript

Los paquetes de JavaScript pueden manejar incluso la mezcla de diferentes sabores en un proyecto —lo que parece una mala idea hasta que terminas trabajando con código heredado y necesitas mucha flexibilidad para elegir las prioridades correctas.

Construcción separada para diferentes casos de uso

Una vez que comienzas a compilar tu código con un paquete, surgen nuevas posibilidades. Desde el principio, lo más probable es que compiles el código de una forma para la producción y de otra para el desarrollo local. Si escribes pruebas unitarias, tal vez te interese saber qué tan bien cubren tu código. Hay herramientas de cobertura de código que hacen exactamente esto. Requieren una compilación dedicada que incluya herramientas que cuenten las visitas a cada línea de código durante la ejecución de la prueba.

¿Y tú?

¿Qué paquete JS planeasusar en tu próximo proyecto? Házmelo saber en la encuesta, para saber a cuál debería prestar más atención en este blog:

¿Qué sigue?

Puedesconsultar mi artículo sobre el uso de módulos ES nativos, o:

• mi video curso para esbuild
• mi video curso para webpack

¿Qué son las pruebas de extremo a extremo?

Las pruebas E2E son scripts que interactúan con una aplicación de manera similar a como lo haría un usuario. Abren un navegador, cargan una URL, hacen clic en los elementos de la interfaz de usuario (IU), como los botones, y esperan algunos resultados. Las máquinas los ejecutan, y son mucho más rápidos y confiables que los humanos. Nunca se aburren.

El único inconveniente —necesitan instrucciones precisas y, a veces, pueden ser más complicados de programar que la función que intentan probar. Escribir las pruebas es programación, y está acoplado con la aplicación que se prueba, pero es una tarea que a muchos programadores no les entusiasma especialmente. Si te vuelves bueno en eso, podría convertirse en tu habilidad única que te ayude a brillar en el trabajo.

¡Elige tu herramienta!

Hay muchas opciones disponibles para construir una suite E2E:

• Cypress
• Playwright
• Protractor
• Selenium
• TestCafe

Aquí, es lo mismo que con otras decisiones tecnológicas: es bueno investigar bien tus opciones. Cada prueba que escribe está estrechamente relacionada con la plataforma que elija. Es posible migrar de una herramienta de prueba a otra, pero eso sería un proyecto tan grande como reemplazar el marco frontal.

Mi experiencia es principalmente con Protractor, una solución obsoleta centrada en Angular. Actualmente estoy migrando pruebas a Cypress y estoy impresionado con el progreso en las herramientas de prueba en esos años. ¿Qué herramienta E2E le gustaría utilizar en su próximo proyecto? Házmelo saber en la encuesta:

Pruebas simples en la máquina local

Con sus primeras pruebas, manténgalas triviales. Use cualquier URL de prueba local que tenga y simplemente acceda a ella con sus scripts. Ni siquiera necesita verificar ningún flujo de trabajo de la aplicación. Simplemente escriba algunas pruebas, cada una para diferentes rutas, y verifique que los elementos de la interfaz de usuario aparezcan en la página. Por ejemplo, puedes comprobar:

• en /login, si hay campos de entrada para nombre de usuario y contraseña
• en /product/12, si se muestra el nombre del producto
• etc

Incluso con pruebas tan fáciles, puedes probar:

1. que la aplicación se está iniciando y todas las rutas se muestran con elementos clave de la interfaz de usuario
2. que puedes desarrollar pruebas E2E

Y con eso, el E2E está despegando —el equipo tiene algunas pruebas y un miembro (usted) está dispuesto y es capaz de escribir más pruebas.

Pon a tu equipo a bordo

Probablemente no necesitará ser insistente al principio. Solo asegúrese de que todos sepan que hay pruebas E2E disponibles y genere la expectativa de que cada desarrollador debe ejecutarlas antes de fusionar cosas con la rama principal. En esta etapa, notará todas las diferencias entre las configuraciones locales de sus colegas—diferentes dominios o puertos que la gente usa localmente. Puede solucionarlo haciendo que todos usen la misma URL o haciendo que la URL de prueba sea fácilmente configurable, no codificada. Ambos enfoques están BIEN. Simplemente hice que todos usaran la misma URL localhost; en mi caso, casi no hubo rechazo por parte del equipo.

El siguiente paso es probar el camino feliz de un flujo de trabajo—lo que debe hacer la aplicación cuando todo funciona como se esperaba. Escribe pruebas que verifican si el botón "agregar al carrito" realmente agrega productos al carrito, y ese "pago" va a la página del proveedor de pago. Esas pruebas son más complicadas de escribir, pero prueban partes críticas de la aplicación. Deberían ayudar a convencer a sus colegas sobre la utilidad de E2E. Y sus pruebas se están volviendo un poco más sofisticadas.

¿Qué sigue?

Si tiene alguna pregunta o duda sobre E2E, ¡no dude en publicarla en los comentarios! Lo leeré y haré lo mejor que pueda para responder. Puede continuar leyendo sobre administrar código heredado frágil en mi blog.

Hojear el código

Obtén el código y sumérgete un poco en él. Es probable que el código existente sea confuso, que los archivos sean demasiado grandes y que todo parezca un desastre. Al principio, podría concentrarse en la estructura del archivo para encontrar patrones. En un proyecto con una larga historia y poco enfoque en la consistencia, es probable que encuentre diseños de la competencia utilizados de manera aparentemente aleatoria. En este caso, solo trate de averiguar qué tan malo fue y deje la sistematización para más adelante.

README actualización

Después de revisar el código, evaluemos el estado de la documentación. Debería haber algún tipo de archivo README. Tal vez esté criminalmente desactualizado, pero al menos menciona las ideas utilizadas en la creación del código base. Puede intentar actualizar la información a medida que encuentre algunas piezas obsoletas. Un buen lugar para comenzar es integrar lo que recibió en los correos electrónicos y otras comunicaciones sobre el proyecto y asegurarse de que esté reflejado y vinculado desde el README. Además, asegúrese de actualizarlo regularmente para que la próxima persona en el proyecto tenga un comienzo más fácil.

Descubre el proceso de construcción

Recientemente trabajé en un curso de actualización de Angular que recibió su última actualización hace tres años. Los primeros videos estaban en Angular 4—una versión tan antigua que tiene problemas de compatibilidad con las Node.js y procesadores mas actuales. Pasé por una cascada de actualizaciones forzadas antes de poder construirlo en mis máquinas—y eso fue solo en un pequeño proyecto de ejemplo. Un proyecto que heredes en el mundo real probablemente estará en un estado mucho peor.

Con suerte, todo lo que necesita para construir el proyecto con éxito será

1. cubierto por LÉEME u otra documentación,
2. todavía al día, y
3. trabajando como se esperaba.

Lo más probable es que su proyecto no cumpla con esos puntos en el camino, lo que le permitirá resolverlo por su cuenta. Si está fallando, puede buscar el error y ver qué lo está causando.

Si no hay nada útil en la documentación, el siguiente lugar para verificar es package.json. Puede haber algún comando similar a una compilación entre ”scripts”. En el peor de los casos, puede buscar rastros de herramientas de compilación que fueron populares en el pasado y participar en una especie de arqueología de JavaScript:

• grunt
• gulp
• webpack
• browserify
• require.js

Y el despliegue

Eso también puede ser divertido. No saber dónde se ejecutan sus sistemas es bastante frustrante: hace que se preocupe por lo que podría pasar si se estropean. Teníamos un chatbot interno y no pudimos averiguar dónde vivía durante unos meses. Esta información debería estar disponible más fácilmente para más sistemas de misión crítica, pero esas cosas a menudo toman más tiempo de lo esperado.

Descubrir todos los detalles sobre su implementación de producción puede llevar mucho tiempo. Podría detenerse por no tener el usuario correcto, perder credenciales para algunas áreas y tener que verificar todo dos veces para evitar romper cosas. ¡Felicidades! Puede hacer un cambio de código en su máquina que llegue a producción. Tu trabajo puede tener un impacto.

Investigue las medidas de garantía de calidad (QA) existentes:

De manera similar a lo que hizo para la compilación, intente encontrar lo que sea que esté disponible para

• Pruebas de integración,
• Pruebas unitarias, y
• Lint.

Si no está documentado y no está definido en los scripts de package.json, puede buscar algunas herramientas que eran comunes en el pasado.

• Pruebas de integración:
  • protractor
  • selenium
• Pruebas unitarias:
  • jasmine
  • mocha
  • sinon
• Lint:
  • jslint
  • jshint
  • tlint

Si hay rastros de medidas de control de calidad automatizadas configuradas en el pasado, intente reutilizarlas tanto como sea posible. Puede haber un valor real en todas las cosas que configuraron los desarrolladores anteriores, y sería una pena tirarlo todo.

Establecer una prueba de humo

Si está restaurando un motor antiguo, en el primer intento, lo encenderá sin carga para ver si funciona sin quemarse. Esto se llama prueba de humo—todo está bien, siempre y cuando no veamos humo. Lo mismo ocurre con el código heredado: cuando no tiene nada con lo que probar la aplicación a fondo, al menos puede compilarla y ver si la aplicación se inicia correctamente. Hasta que pueda ejecutar pruebas más sofisticadas automáticamente, es mejor que se limite a cambios directos y utilice este mismo procedimiento básico para asegurarse de que todo funcione como se espera.

Comience con pequeños cambios

El proceso de reactivación del proyecto va bastante bien; ahora está listo para comenzar a realizar cambios en el código. Comience con algo pequeño, con cosas que nadie notará. Usted puede

• actualizar la versión del parche de alguna biblioteca,
• cambiar el nombre de algunas variables locales, o
• refactorizar algunos antipatrones molestos en un solo lugar.

Recuerde que su meta es hacer un cambio que casi seguro no tendrá efectos secundarios.

Implementar en producción

Cree el código con sus cambios triviales e impleméntelo en todos los entornos hasta la producción. Su objetivo es hacer un ejemplo de este proceso restaurado—hacer que los cambios de código pasen de su cabeza a las máquinas de los clientes. Es lo suficientemente desafiante por sí solo; es por eso por lo que mantuvimos el alcance de nuestros cambios al mínimo. Su objetivo es brindarle a usted y a las partes interesadas confianza en el proceso.

Agregar pruebas de integración

Lo más probable es que tenga que crear pruebas de integración desde cero. Me refiero a esas pruebas que comprueban que todo está integrado y funciona en conjunto. Otro nombre es extremo a extremo (e2e) porque a menudo se prueban tanto el frontend como el backend juntos. Debes comenzar aquí porque no importa si calculas el IVA correctamente si la aplicación falla cuando inicias una nueva transacción. Al principio, puede tener más sentido desarrollar pruebas simples para muchas páginas en lugar de pruebas precisas solo para unas pocas. Una prueba tan simple como visitar una ruta y verificar si los elementos clave de la interfaz aún están presentes puede proporcionar mucho valor—esto detecta instancias en las que alguna página se rompe por completo.

Configure y comience a agregar pruebas unitarias

Una vez que sepa que la aplicación se está iniciando como se esperaba, puede entrar en los detalles y ver si todas las unidades—clases, funciones, etc.—funcionan como se esperaba. Puede probarlos desde el nivel de la interfaz de usuario, pero las pruebas de extremo a extremo son:

• lento para escribir—obtener los datos correctos en el lugar correcto lleva mucho tiempo
• lento para ejecutar—tener una base de datos, un backend y un navegador en ejecución consume muchos recursos

En lugar de incluir todos los casos extremos imaginables en su configuración de integración, desea tener una configuración de prueba separada para obtener más detalles esenciales. Quiere pruebas unitarias. Ellos:

• son órdenes de magnitud más rápidos de ejecutar que e2e
• están desconectados del backend y la base de datos
• permite probar partes atómicas de su aplicación, independientemente del código y los flujos de trabajo circundantes

¿Quieres aprender más? Aquí puede encontrar mi razón para escribir pruebas unitarias.

Verficar el código con lint

Los linters son análisis estáticos del código destinados a señalar las fuentes de problemas comunes. Es bueno tener un control regular que revise su código y le diga que todo está bien aquí. eslint, un linter popular para JavaScript y TypeScript, permite una gran cantidad de configuraciones. Puede configurar la configuración para detectar solo los problemas más problemáticos, arreglar todo el código base e integrarlo con su editor de código. Para seguir obteniendo más valor de la configuración, puede continuar iterando sobre la configuración, activando o desactivando diferentes reglas y agregando complementos específicos del marco. De esta manera, podrá hacer que su código mejore con el tiempo; y al mismo tiempo, cada paso será pequeño y no te llevará demasiado tiempo a la vez.

Hacer cumplir el estilo de codificación

Cumplir con el mismo formato facilita la lectura del código: de esta manera, no hay lugares con formatos extraños que atraigan su atención por la razón equivocada. La coherencia en el código base aporta una sensación de orden y facilita la confianza en el estado actual del proyecto. El estilo de codificación puede generar muchas discusiones acaloradas. No me importa mucho el formato en particular; Solo quiero hacer lo mismo, sin importar quién y cuándo escribió el código, y me gusta que el estilo se aplique automáticamente. Afortunadamente, en este momento contamos con herramientas obstinadas, como prettier, que pueden formatear proyectos completos en un momento y dejar solo unas pocas opciones para discutir dentro de su equipo. ¡Así que puede subcontratar tanto el formato en sí como las interminables discusiones al respecto a una herramienta externa!

Ir a través de actualizaciones fáciles de librerías

Ahora, hagamos algunas tareas finales de calentamiento. Puede intentar actualizar alguna dependencia de una versión de parche a una más nueva—por ejemplo, de la versión 1.2.3 a la 1.2.4. Su código probablemente esté usando versiones antiguas de todas las bibliotecas de terceros que usa. Actualizarlos requerirá mucho trabajo y es una buena inversión hacerlo: las nuevas versiones generalmente tienen algunas características nuevas, correcciones de seguridad y más materiales disponibles en línea. Incluso una actualización de parche no es un cambio trivial, y con todo el trabajo que hemos hecho aquí, deberíamos esperar uno de dos resultados:

• las cosas fallan después de la actualización, pero son detectadas por una de nuestras capas de verificación, o
• todo funciona bien—tanto en las pruebas como en la producción después de la implementación.

¡Asegúrate de no intentar apresurar esas actualizaciones! Haga uno a la vez, suelte y espere comentarios. Recuerde, le está enseñando a la gente a confiar en sus cambios, y lo último que necesita es una regresión.

Realice la mejora más pequeña y sencilla de cara al usuario

Hasta ahora, su trabajo ha sido casi invisible para los usuarios—a menos que haya logrado interrumpir la producción en algún momento. Con toda la infraestructura en su lugar, ¡está listo para entregar algo de valor! Elija el problema más pequeño y simple que pueda encontrar—un error tipográfico en alguna página o un margen faltante en un botón. Su objetivo es demostrarse a sí mismo y a los demás que puede solucionar problemas y realizar cambios en el código sin romper nada más. No lo arruines tratando de hacer algo impresionante.

Configurar la integración continua (CI)

Vendrán más solicitudes de cambio si el proyecto realmente está volviendo a la vida. En ese caso, tendrá sentido establecer una integración continua. Si está interesado en obtener más información, déjame saber en la encuesta:

¿Qué sigue?

¡Felicidades! Usted es la nueva persona de referencia para el código heredado. Disfrute de la seguridad laboral recién adquirida—el trabajo debe hacerse y no hay cola de personas dispuestas a hacerlo. Puede ser un excelente momento para verificar dos veces si su compensación está a la altura del mercado y cubre el valor que brinda a la empresa——lea más aquí.

Hable sobre el pago con sus compañeros

La forma en que se percibe hablar de dinero depende de la cultura. Crecí en Polonia y hablar de mis ingresos fue como presumir durante mucho tiempo. Podría ver que este es el caso si un especialista bien pagado hablara sobre sus ingresos a las personas que están atrapadas en trabajos de salario mínimo. Por otro lado, para las personas que trabajan en trabajos similares, los posibles resultados son:

• Hay una diferencia mínima en la compensación
• Alguien —tal vez usted —podría darse cuenta de que está mal pagado. Hay algunas razones por las que esto podría suceder:
  • Le falta alguna habilidad técnica que tiene un impacto significativo en el pago
  • Le faltan habilidades de negociación
  • La empresa en la que trabaja no tiene presupuesto para pagar mejor

¿Y las personas que aprenden que les pagan mejor? No pierden nada.

Además del tabú cultural, la única razón para no hablar de dinero sería si estás más interesado en los resultados de la empresa que en tu bienestar y el de tus compañeros. Por ejemplo, este podría ser el caso si su participación en la propiedad de la empresa es más significativa que su parte de la nómina total, o si cree plenamente en la misión de su empleador.

Evaluar el mercado más amplio regularmente

Si eres como yo, tu enfoque en tu carrera fluctúa mucho a lo largo de los años. A veces paso mucho tiempo aprendiendo cosas nuevas, interactuando con comunidades tecnológicas y, a veces, tengo meses en los que no hago nada relacionado con TI además de mi trabajo diario. Siempre hay cambios en el mercado laboral: nuevas tecnologías que ganan popularidad, nuevas empresas en el mercado local que ofrecen mejores condiciones o empresas lejanas que se abren a candidatos remotos. Es una buena idea concertar una cita contigo mismo para comprobar periódicamente esos cambios. Como mínimo, reservar una tarde al año para buscar ofertas de trabajo debería hacerte consciente de cómo van las cosas fuera de tu empresa actual.

No cuentes con la iniciativa de la empresa

La empresa para la que trabaja está interesada en mantener sus operaciones sin interrupciones. Tal vez la evaluación de su gerente dependa de cuántos renuncien a su equipo, pero esto les da solo un pequeño incentivo para mantener su salario en línea con el mercado. Este incentivo será aún menor si les convences de que te gusta tu trabajo y que no estás buscando nada más en este momento. Si la empresa tiene una política de aumentos salariales regulares, lo más probable es que solo coincida con la inflación, no con los cambios del mercado laboral de TI. Si te ascienden a un tramo salarial diferente que viene con un aumento, parece una mejora, pero puede ser que te coloquen en la parte inferior de este nuevo tramo.

Prepárate para la negociación

En 2019 me compré Fearless Salary Negotiation como regalo de cumpleaños. Fue el mejor regalo que he recibido y se pagó solo en poco tiempo. El libro brinda muchos consejos prácticos: guías paso a paso sobre qué hacer antes de negociar el salario. Tratar con una nueva empresa es una gran parte, pero hay muchas cosas que serán útiles en un contexto más general, y un capítulo está dedicado a las promociones y los aumentos de sueldo.

Si tiene un presupuesto limitado, el autor del libro lo ofrece generosamente [también gratis] (https://bit.ly/FearlessSalaryNegotiationFree). Puede obtener su consejo en su sitio web, en el breve artículo: [cómo escribir un correo electrónico a su gerente para iniciar la conversación] (https://bit.ly/FearlessSalaryNegotiationRaise).

¡Pregunta por ello!

Hablar del tema de la compensación con su gerente puede ser estresante. La preparación adecuada debería ayudarlo a lograr su objetivo y ayudarlo con el estrés. Puede verlo desde otra perspectiva: un gerente razonable debería apreciar que hable primero con ellos sobre su problema con el salario, en lugar de ir directamente a la competencia. ¿Y si resultan ser irrazonables? Significará que hablar con otras empresas es una buena idea.

No seas tímido; avisa a tus colegas

Una vez que obtenga su aumento, ¡puede informar a sus colegas! La práctica estándar de la industria de saltar de un trabajo a otro para obtener una mejor compensación significa que su colega experimentado podría ser reemplazado algún día por alguien que no sabe nada sobre su proyecto, lo que le obliga a llevar una carga de trabajo más significativa. Compartir sus buenas noticias puede inspirar a otros miembros del equipo a intentar hacer lo mismo, mejorando la moral y asegurándose de permanecer más tiempo en el proyecto. Al final, esto hará que su trabajo sea más fácil y placentero.

¿Qué sigue?

Es genial que estés reflexionando sobre tu carrera y tratando de conseguir el mejor trato para ti. Ya que llegaste hasta aquí, ¿qué tal averiguar si tu lugar de trabajo actual es adecuado para ti? Aquí tienes una guía para evaluar tu empresa actual. Si tiene preguntas, sigo aceptando personas para tutoría gratuita en JS y programación, ¡no dude en comunicarse conmigo!

Elija un caso de uso simple

El primer paso: no intentes morder más de lo que puedes masticar. Es común que las personas intenten crear cosas como clones de sitios web populares, pero esto da como resultado más funciones de las que uno puede desarrollar de manera realista. Si insiste en inspirarse en productos existentes, intente simplificarlo al extremo:

• si crea un clon de Reddit, cree una lista de enlaces codificados (por ejemplo, los mejores sitios web de programación) donde las personas pueden votar a favor o en contra, O una lista de enlaces donde simplemente agrega enlaces a una lista larga
• si crea un clon de Airbnb, haga solo una lista de propiedades estática, sin reservar ni agregar nuevas propiedades
• si crea un clon de Uber, cree una página de resumen del pedido: un viaje del punto A al punto B

Otro enfoque es trabajar en algunos ejemplos de clichés: una aplicación TODO o una página de blog. Esos pueden parecer repetitivos y aburridos, pero al menos el caso de uso se entiende bien y no debería abrumarlo.

Dibujar la interfaz

Cuando haya seleccionado su caso de uso, tome lápiz y papel y dibuje su interfaz. Debe comenzar con una página o un máximo de dos páginas. Al principio, un boceto en papel es perfecto; su objetivo es iterar rápidamente, y una solución de baja tecnología funciona muy bien para ello. En proyectos colaborativos, las personas usan aplicaciones sofisticadas para los diseños, pero presentan algunos dolores de cabeza—debe instalar es aplicación, aprender su interfaz, etc., lo que lo ralentiza. Su boceto aquí aclara sus pensamientos, y una vez que esté hecho, lo usará para nada más que echarle un vistazo mientras construye la interfaz.

Diseñar el esquema de datos

Según lo que esté mostrando en las distintas pantallas, necesitará tener algunos datos en su aplicación. Asigne cada valor que muestre o use a un campo que tendrá en la estructura de datos. Para nuestros ejemplos anteriores:

• 'Reddit' tendrá publicaciones o enlaces, con 'título', 'URL' y tal vez 'votos' o 'voteCount'.
• 'Airbnb' tendrá propiedades con 'nombre', 'foto', 'descripción', 'precio' y 'ubicación'.
• 'Uber' tendrá viajes con 'desde', 'hasta' y 'costo estimado'.
• La aplicación TODO tendrá tareas con título, descripción.
• El blog tendrá publicaciones con título, cuerpo y fecha de publicación.

Construye la interfaz

Con toda esa preparación completa, está listo para abrir el editor de código. La interfaz de usuario es la parte más tangible y probablemente la más sencilla del proyecto. Creará un archivo HTML y tal vez agregue CSS si tiene ganas de hacer que su aplicación sea algo bonita. Tu objetivo es crear lo que se redactó antes y mostrarlo de la forma más sencilla posible. Especialmente si está agregando estilo, tenga en cuenta que "hecho" es mejor que perfecto —no dedique demasiado tiempo a menos que CSS y el diseño sean sus prioridades de aprendizaje.

Cree datos simulados y actualice la interfaz para usarlos

Cuando haya terminado con HTML con datos codificados, su siguiente paso es crear una interfaz dinámica. En esta etapa, agregará JS a su proyecto. Puede limitarse a Vanilla JS y recrear el HTML con DOM, o puede agregar un marco JS con el que esté familiarizado o quiera aprender. Deberá crear una estructura de datos temporal en una variable y volver a crear el formulario HTML JS en función de los datos de la variable.

Añade algo de lógica

Una vez que muestra datos dinámicos, puede agregar algo de lógica para manipularlos. En nuestro ejemplo simplificado, la lógica será bastante simple —agregar un registro a la lista o actualizar uno o dos valores en los datos existentes. El objetivo principal aquí es asegurarse de que nuestra aplicación esté viva —de modo que el usuario pueda hacer clic en la interfaz y se realicen cambios en lo que aparece en la pantalla. Esto es principalmente una prueba de que puede manipular datos. A medida que continúe trabajando en el ejemplo, la lógica se volverá exponencialmente más complicada. En ese caso, cada función añadida tiene que funcionar con todas las existentes. ¡Disfruta el momento en que es tan simple que se siente sencillo!

Almacene sus datos

El siguiente paso es configurar algún tipo de persistencia para los cambios en sus datos. Puedes considerar las siguientes cosas:

• localStorage o sessionStorage – para pruebas locales rápidas
• almacenamiento simple de terceros – algo como Airtable o Google Sheets
• almacenamiento sin backend – Firebase o un sistema similar
• compilación de backend dedicada – usted mismo para más práctica

Déjame saber en la encuesta o en los comentarios si estás interesado en aprender más sobre cualquiera de esos enfoques. Estoy pensando en crear artículos con ejemplos, y si sé que hay demanda, estaré más motivado para trabajar en ellos.

¡Iterar!

Una vez que siga todos estos pasos, debería tener una aplicación algo utilizable. Estará lejos de ser un producto mínimo viable, pero deberías tener algo que mostrar a las personas que te animan en tus estudios. Si desea continuar trabajando en su proyecto, el siguiente paso es averiguar qué otro caso de uso desea cubrir en su aplicación y comenzar a seguir los pasos nuevamente. Esta vez debería ser más accesible y debería poder omitir algunos pasos.

¿Qué sigue?

¡Siéntete libre de compartir los resultados de tu experimento en los comentarios! Si le gustó el enfoque propuesto aquí, puede continuar con modelado de datos de aprendizaje

fuente

Codificación sin módulos ES

Antes de que tuviéramos módulos Es, todo JS tenía que importarse globalmente. Cada archivo podría acceder a variables previamente definidas y dejar cosas para el código ejecutado mas tarde. El orden de las importaciones importaba, especialmente porque las cosas importadas mas tarde podrían anular los valores anteriores. Las importaciones de la vieja escuela en acción se veían así:

display-data.js:

document.body.innerHTML = "lorem ipsum";

log.js:

console.log("Some test info");

index.html:

<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <title>No modules</title>
    <link rel="shortcut icon" href="#" />
  </head>

  <body>
    <script src="./display-data.js"></script>
    <script src="./log.js"></script>
  </body>
</html>

El ejemplo en acción.

Problemas

Hay dos problemas principales con esta propuesta:

1. Contamina el ámbito global. Si tiene algunos archivos que definen el mismo valor, colisionaran y se anularan entre sí. Buena suerte para encontrar y corregir los errores que puede causar. Ejemplo: data-1.js:

   var data = “lorem ipsum”;
   

   data-2.js:

   var data = “sin dolor”;
   

   index.html:

   <html>
   <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <title>Name collision</title>
    <link rel="shortcut icon" href="#" />
   </head>
   
   <body>
    <script src="./data-1.js"></script>
    <script src="./data-2.js"></script>
    <script>
      document.body.innerHTML = data;
    </script>
   </body>
   </html>
   

   Esto código en vivo. La solución alternativa mas común fue utilizar una expresión de función invocada inmediatamente. Esto aisló bloques de código y evitó la contaminación del alcance global, pero al mismo tiempo, hizo que el código fuera más confuso.

2. Cualquier dependencia tenia que gestionarse y resolverse manualmente. Si tenía un archivo que dependía de otro, entonces tenía que asegurarse de importar esos archivos en el orden correcto. Por ejemplo: log-data.js:

   console.log(data);
   

   data.js:

   const data = ‘some data’;
   

   display-data.js:

   document.html = data;
   

   index.html:

   <html>
   <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <title>File order</title>
    <link rel="shortcut icon" href="#" />
   </head>
   
   <body>
    <script src="./log-data.js"></script>
    <script src="./data.js"></script>
    <script src="./display-data.js"></script>
   </body>
   </html>
   

   Como puedes ver aquí, la parte “display data” (mostrar datos) funciona como se esperaba, mientras que el “logging data” (registro de datos) falla.

Módulos ES en acción

¿Cuál es la diferencia si hacemos lo mismo con los módulos ES? En primer lugar, define las dependencias a nivel de código. Entonces, si en un archivo desea valores de otro, simplemente especifíquelo en el mismo archivo. Este enfoque marca la diferencia, especialmente en la lectura de código: solo necesita abrir un archivo para tener una idea de todo el contexto que está usando con solo leerlo.

Entonces, ¿Cómo usamos los módulos ES?

data.js:

export const data = "lorem ipsum";

display-data.js:

import { data } from "./data.js";

document.body.innerHTML = data;

index.html:

<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <title>Simple modules</title>
    <link rel="shortcut icon" href="#" />
  </head>

  <body>
    <script type="module" src="./display-data.js"></script>
  </body>
</html>

Los principales cambios en este código:

1. Agregando type=”module” a <script> importa en el archivo HTML.
2. Utilizando palabras clave de exportación e importación en los archivos JS para definir y cargar módulos.

Ejemplo de ejecución.

Varios archivos que importan el mismo archivo

Podemos hacer que nuestro ejemplo sea más interesante importando los mismos archivos dos veces. Debido a que necesitamos que cada archivo sea independiente del otro, la importación se agregará dos veces—en cada archivo por separado. Los navegadores gestionan la importación correctamente y cargan el archivo solo una vez.

data.js:

export const data = "lorem ipsum";

display-data.js:

import { data } from "./data.js";

document.body.innerHTML = data;

log-data.js:

import { data } from "./data.js";

console.log(data);

index.html:

<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <title>Shared import</title>
    <link rel="shortcut icon" href="#" />
  </head>

  <body>
    <script type="module" src="./display-data.js"></script>
    <script type="module" src="./log-data.js"></script>
  </body>
</html>

El ejemplo

Carga diferida

La carga diferida retrasa la parte de carga de la aplicación hasta que el código es necesario. Esta es una técnica de optimización más complicada que cargar todo a la vez, pero permite un mayor control sobre qué se carga y cuándo. En el siguiente ejemplo, cargo y visualizo datos después de un retraso de medio segundo:

display-data.js:

setTimeout(
  () =>
    import("./data.js").then(({ data }) => {
      document.body.innerHTML = data;
    }),
  500
);

data.js:

export const data = "lorem ipsum";

index.html:

<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <title>Lazy load</title>
    <link rel="shortcut icon" href="#" />
  </head>

  <body>
    <script type="module" src="./display-data.js"></script>
  </body>
</html>

Ejemplo de carga diferida

¿El módulo ES cubre todo lo que necesitamos en JS moderno?

Aunque los módulos nativos de ES mejoran significativamente los modelos anteriores de inclusión de cosas, carecen de algunas características esenciales para el desarrollo moderno de JavaScript. En este momento, no puede hacer lo siguiente:

1. Importar tipos distintos a JS. Algunos otros archivos están en proceso JSON, pero pasará mucho tiempo antes de que lo tengamos en el navegador.
2. Importe bibliotecas de terceros al estilo de Node.js. Podrías copiar archivos durante la construcción e importarlos desde una ubicación dentro de node_modules, pero se siente mucho más complicado que simplementeimportar la "biblioteca".
3. No hay transpilación. Gran parte del JS moderno está escrito en otros lenguajes, por ejemplo, TypeScript. Incluso JS puro necesita transpilación para admitir navegadores más antiguos o utilizar las funciones de lenguaje más recientes.

Por estas razones, en la mayoría de los proyectos, verá paquetes JS, una especie de compilador que prepara la compilación para las implementaciones. Si está interesado en los paquetes, hágamelo saber en los comentarios y consulte los enlaces.

Enlaces

• [repositorio de ejemplos] (https://github.com/how-to-js/es-modules)
• [todos los ejemplos] (https://how-to-js.github.io/es-modules/)
• [mi curso de video para esbuild] (https://bit.ly/esbuild-course)
• [mi curso de video para paquete web] (https://bit.ly/WebpackCourse)

Resumen

En esta publicación, analizamos casos de uso críticos de módulos ES. El siguiente paso sería configurar algún paquete JS para repasar las limitaciones de los módulos nativos.

Que son las pruebas unitarias

Las pruebas unitarias son scripts simples que verifican si una unidad dada—clase, función, módulo, etc.—está funcionando como se esperaba. Están pensados para ser bastante simples, para cubrir el camino feliz del código más algunos casos extremos. Contribuyen al éxito a largo plazo de un proyecto por las razones que analizo a continuación.

Acelere las pruebas de desarrollo

Cuando empiezas a crear aplicaciones, lo más natural es probar el código con la interfaz de usuario. Puede hacer que este proceso sea más rápido y confiable escribiendo un script que verifique el código por usted. Con las pruebas en su lugar, volver a ejecutarlas todas no le quita energía mental; puede hacerlo con la frecuencia que desee. Esto también conduce a un ciclo de retroalimentación más corto, lo que lo ayudará a mantenerse concentrado y productivo.

Descubra casos extremos

Escribir pruebas unitarias me hace pensar en casos extremos: todas las situaciones que son raras, inesperadas o incorrectas. Cuando escribe la lógica, es normal concentrarse en el camino feliz, o en lo que es normal y se espera que suceda. Cuando escribe pruebas, puede configurar comprobaciones para los casos extremos y definir lo que debería suceder en cada uno de ellos. Esto hace que su código sea más resistente en casos de entradas inesperadas.

Asegúrese de que su código esté compuesto por unidades

Cuando agrega pruebas unitarias a su código, ve qué es fácil de probar y qué no. A medida que su código crece en tamaño y complejidad, las pruebas lo obligarán a dividirlo en partes manejables. Esto es genial porque te ayudará a llevar la calidad de tu código al siguiente nivel. Cada segmento que recibió responsabilidades excesivas requerirá pruebas unitarias exponencialmente más complicadas. En esos casos, es una buena idea detenerse y repensar cómo organiza su lógica.

Documentación interactiva

Tus pruebas se convertirán en un recurso adicional para que la próxima persona que trabaje en el código averigüe qué está haciendo y cómo se supone que funciona. Es una especie de documentación extra, con bonificaciones:

1. A menudo es más preciso que las descripciones escritas en la documentación real.
2. Se pueden ejecutar pruebas con el código actual para asegurarse de que todas las declaraciones sigan siendo válidas; no depende de un humano para leer, comprender y verificar el código.

Red de seguridad para cambios futuros

Las pruebas unitarias se ejecutan tan rápido que es una obviedad ejecutarlas en cualquier actualización, sin importar cuán pequeños parezcan los cambios. Puede configurar su repositorio para ejecutar la integración continua (CI) y aceptar solo los cambios que pasen todas las pruebas. De esta manera, puede garantizar una integración fluida de los cambios sin importar la actualización:

• actualización menor que "no debería romper nada".
• actualización de biblioteca de terceros
• intento rápido y sucio de alguna solución

Las pruebas unitarias protegen la base de código contra todas las regresiones menores que cubren.

Resumen

Las pruebas unitarias son una parte esencial para mantener un código de alta calidad. Puedes verlo como una de las patas de una mesa:

Claro, puede eliminarlo, pero hará que mantener el equilibrio sea más complicado. Escríbalos y le ayudarán a lograr una buena calidad de código y hacer que su aplicación sea más segura.

Enlaces

Publicado originalmente en inglés.