DEV Community: Conoce dev

Cómo empezar a hablar un nuevo idioma

Marcin Wosinek — Wed, 24 Aug 2022 05:22:00 +0000

Hay una situación muy habitual en el aprendizaje de un idioma: lo estudias durante un tiempo, meses o años, pero te cuesta hablar hasta de lo más sencillo. Pero si tenemos en cuenta cómo es una clase típica, no debería sorprendernos.

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!

Cómo escribir pruebas unitarias

Marcin Wosinek — Wed, 27 Apr 2022 04:54:57 +0000

Como programador principiante, a menudo escucharás que es conveniente probar tu código. Es un buen consejo - ¡veamos cómo puedes empezar a hacerlo!

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:

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.
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.
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.
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:

Configuración de los mocks
Ejecución del código que se quiere comprobar
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.

Trucos para impresionar con tu tarea para una entrevista

Marcin Wosinek — Wed, 20 Apr 2022 05:30:16 +0000

Echemos un vistazo a cómo hacer que la interfaz de tu próxima tarea para una entrevista tenga la mejor pinta posible.

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!

Cómo trabajar con tu mentor de programación

Marcin Wosinek — Wed, 13 Apr 2022 05:41:17 +0000

El acceso a un programador más experimentado que quiera ayudarte a crecer profesionalmente puede acelerar tu progreso. Puede ser:

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:

Realizas la primera implementación por tu cuenta
Tu mentor te da sugerencias y comentarios
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!

Cómo hacer que los pequeños pasos recorran un largo camino

Marcin Wosinek — Wed, 09 Mar 2022 08:13:47 +0000

A veces, intentamos asumir tareas más importantes de las que podemos cumplir—esto se deriva directamente a nuestra incapacidad humana para evaluar tareas complejas correctamente. Veamos cómo puedes abordar esto en tu viaje de TI.

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.

Cómo acelerar tu progreso con retroalimentación

Marcin Wosinek — Wed, 02 Mar 2022 06:34:27 +0000

Un bucle de retroalimentación es una parte esencial de todos los sistemas de control, excepto los más sencillos. Y si te preocupas por conseguir algún objetivo, como, por ejemplo

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:

Después de leer un ticket, explicalo a alguien que entienda bien de qué se trata. Si no lo entendiste bien, podrán corregirte.
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.
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!

Cómo usar Netlify como tu integración continua

Marcin Wosinek — Wed, 23 Feb 2022 05:59:12 +0000

Netlify es un proveedor de alojamiento que puedes utilizar para sitios web estáticos o aplicaciones web. El plan gratuito viene con 300 minutos de tiempo de compilación, lo que debería ser suficiente para configurar la implementación continua (CD) para un proyecto que no recibe muchas confirmaciones. Te mostraré cómo usar esos recursos para agregar una integración continua (CI) simple a su compilación.

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

¿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.

Integración continua (CI) y cómo puede ayudarte

Marcin Wosinek — Wed, 16 Feb 2022 05:48:41 +0000

La integración continua (CI) es un proceso mediante el cual verificamos nuestro proyecto en cada cambio que ocurre en la base de código. ¿Qué es exactamente la integración? Depende de cómo configure el proceso: puede ser tan simple como instalar las dependencias y compilar el proyecto o tan complicado como ejecutar muchos scripts diferentes para determinar si el código base está en un estado aceptable.

Compañera de trabajo diligente

Puede pensar en CI como un compañero de trabajo diligente que siempre está ahí, esperando para verificar sus 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 tiene un problema? Sin CI, permite que sus 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. Puede utilizar la salida de un trabajo como entrada en otro; por ejemplo, puede 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 —su CI puede evolucionar junto con su base de código.

Si todas las tareas pasan, entonces la confirmación es pasando; si alguno de ellos falla, entonces la confirmación está fallando. 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 está pasando el CI.

Tareas que puede delegar a su CI

Puede configurar cualquier script que ejecute en su 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 la confirmación. 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 soluciona el problema, ni siquiera sabe cuándo se presentó el problema; podría estar en un compromiso anterior, o hace una semana. Podrías 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ítanme 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á 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 ha 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 tiene acceso directo.

Dependencia de un proveedor externo

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

Costo

Muchos proveedores de IC 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á un plan 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 usted?

¿Está 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 le interesa más, puedo crear contenido que coincida con sus expectativas.
¡Así que, por favor, vota en la encuesta a continuación! Tu opinión es muy importante para mí. ¡Gracias!

¿Qué sigue?

Para obtener aún más valor de su CI, ejecute 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, puede ver cómo comenzar con E2E.

¿Por qué usamos empaquetadores de JavaScript?

Marcin Wosinek — Wed, 09 Feb 2022 06:18:06 +0000

JavaScript es un lenguaje intérprete y no necesita compilación. Su navegador puede ejecutar el mismo código que usted escribe. Entonces, ¿por qué usamos empaquetadores de JavaScript?

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

le permite mantener su base de código dividida 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 le 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ía

implementar node_modules en su servidor de producción, y
use una ruta relativa desde su archivo 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:

// 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

Su base de código no es solo JavaScript. Cuando organice su 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á escribiendo su código como debería, está 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 al navegador evergreen, pero aún existe la necesidad de un proyecto como Babel. Babel le 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 comienza a compilar su código con un paquete, surgen nuevas posibilidades. Desde el principio, lo más probable es que compile el código de una forma para la producción y de otra para el desarrollo local. Si escribe pruebas unitarias, tal vez le interese saber qué tan bien cubren su 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 usted?

¿Qué paquete JS planea usar en su próximo proyecto? Házmelo saber en la encuesta, para saber cuál debería llamar más la atención en este blog.

¿Qué sigue?

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

Cómo agregar pruebas de extremo a extremo a un proyecto

Marcin Wosinek — Wed, 02 Feb 2022 05:23:11 +0000

Felicidades. La configuración de extremo a extremo (E2E) es un tema bastante avanzado y puede aportar mucho valor a su proyecto. Tiene la posibilidad de detectar posibles problemas antes de fusionar los cambios en la rama principal—mucho antes de acercarse a la implementación en producción. Cuanto antes encuentre el error, más fácil será solucionarlo. E2E le permite realizar pruebas exhaustivas tan pronto como los cambios estén disponibles.

¿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:

que la aplicación se está iniciando y todas las rutas se muestran con elementos clave de la interfaz de usuario
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.

¿Cómo administrar el código heredado frágil?

Marcin Wosinek — Wed, 26 Jan 2022 06:06:50 +0000

¡Bienvenido al mundo real! Después de hacer todos los ejemplos de aprendizaje simplificados, ha comenzado su primer trabajo de TI. Es muy probable que después de realizar algunas tareas de preparación, te des cuenta de que hay un código antiguo desagradable en el proyecto en el que estás trabajando. Si tienes suerte, hay alguien en tu equipo que intenta protegerte para que no te aventures demasiado en esa zona oscura, pero puedes estar seguro de que no durará para siempre. Deberá enfrentarse a la realidad en algún momento—gran parte de su trabajo diario consistirá en mantener una base de código heredada. Veamos cómo puedes hacer que esta experiencia sea lo más manejable posible.

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á

cubierto por LÉEME u otra documentación,
todavía al día, y
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í.

Cómo obtener un aumento de sueldo en TI

Marcin Wosinek — Wed, 19 Jan 2022 16:54:01 +0000

Todos sabemos que la tecnología es una carrera bastante buena en cuanto a dinero. Aun así, puede perjudicarse a sí mismo al ceñirse a un salario más bajo que el que podría ofrecer una empresa. Incluso una pequeña diferencia en el pago se convierte en una cantidad impresionante cuando la multiplicas por 12 meses en un año y todos los años que estarás trabajando. Asegurémonos de que no se pierda ninguna oportunidad financiera.

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. 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.

¡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!