Ningún inicio comienza con un probador. Luego, 2 años después, esa startup no puede lanzar una nueva función para su mayor cliente a menos que reescriban todo con fuerza. Es doloroso ver esto una y otra vez. Hay cosas simples que puede hacer para mantener la calidad higiénica de nuestro software, para que no termine en esta situación. Primero, abraza tus miedos. Los ingenieros son personas valientes y no admitiremos fácilmente que tenemos preocupaciones. Pero lo hemos hecho, y cuanto antes admitamos y compartamos esas preocupaciones, antes nos prepararemos para enfrentarlas. Cómo construimos software hoy Tenemos tanta prisa que siempre llegamos tarde. No hay tiempo para pruebas. No hay tiempo para pruebas unitarias. No hay tiempo para refactorizar. Bueno, nunca habrá suficiente tiempo para hacerlo bien mientras sigamos saboteándonos a nosotros mismos como equipos de ingeniería. Nos preguntan cuánto tiempo llevará, y seguimos excluyendo de nuestras estimaciones las pruebas unitarias, las pruebas manuales e incluso las pruebas API y la refactorización. Así que construimos software como este: Rápido y sucio No rápido, todavía sucio Camino diagonal rápido y feliz probado Todo lo demás se considera un caso extremo. (No existe tal cosa como un caso extremo). Pocos de nosotros somos aún más valientes para decir no a lo rápido o sucio y construir software rápido y estable. Lo que debe eliminar de sus estimaciones es el alcance, no la calidad. ¿Qué sabes sobre la calidad de ese componente en el que estás trabajando? Sabes que es frágil, pero no quieres tocarlo porque es muy frágil. Has hecho esto hace mucho tiempo, apenas lo tocas, debería funcionar. No sabes que es frágil. No hay pruebas ni nadie para probar y exponer lo frágil que es en realidad. ¿Eres feliz lidiando todos los días con este software sucio? ¿Está contento de hacer compromisos con la calidad de su trabajo todos los días, sabiendo que está lejos de ser bueno? Lidiar con "no tenemos tiempo para limpiar" y aún así llegar tarde porque está sucio y no puedes seguir adelante sin limpiarlo. que estás en tu próxima entrevista de trabajo. ¿De qué te jactarás en tu trabajo actual? ¿Que puedes actuar bajo presión y hacer arreglos nocturnos? Te amarán por eso, pero también te preguntarán por qué no hiciste algo al respecto. Tal vez no era tu trabajo. Imagina Hubo líderes de equipo y gerentes de ingeniería para tomar esas decisiones. Si fuera por ti, habrías hecho algo. Les dijiste que el código necesita refactorización y que necesitas planificar tiempo para el departamento de tecnología en cada retro, y nadie escuchó. Bueno, adivina qué, no necesitas permiso. La calidad de tu trabajo depende solo de ti. Nadie puede obligarte a escribir un código de mierda. La presión del tiempo es una excusa a corto plazo. Las soluciones rápidas y sucias retrasan todo el proyecto y cuestan más que si lo haces bien la primera vez. Nunca lo arreglarás más tarde ¿Estás dispuesto a hacer esa diferencia? Entonces, esto es lo que debe hacer: ser disciplinado. Lo siento, pero no hay otra forma de evitarlo. Y debe ser en todos los niveles. ¿Cuáles deberían ser sus primeros pasos para crear código con mayor calidad? Implementar registro y alertas Hay toneladas de herramientas para registrar y alertar. Esto es lo primero que debe hacer. Su software se está bloqueando y usted no se da cuenta. Encuentre una solución que le permita crear fácilmente tickets a partir de las alertas de excepción y marcarlos como "conocidos" o agruparlos una vez que se informen. Cree una rutina de equipo para ver y reportar las alertas Si crees que es aburrido, déjame preguntarte: ¿Estás en la zona profunda durante toda tu jornada laboral? Después de todas las reuniones y el pesado trabajo de programación, necesitas relajar un poco tu concentración. Bueno, navegar por el canal de alertas es mucho mejor que navegar por cualquier otro canal. Simplemente haga clic en el botón "Informar un ticket" o en el botón "Marcar como conocido". Y si te intriga, probablemente arreglarías uno o dos. Aquí viene el mayor argumento: podemos corregir un par, pero estamos escribiendo pruebas que alguien debe confirmar, debemos implementar y esto genera más trabajo no planificado para el equipo. El primer ministro nos gritará que no estamos trabajando en los elementos de alta prioridad, sino en pequeñas alertas doradas. El equipo con todos los roles "M" está de acuerdo con eso. Publique una regla general: "Si parece pequeño y de bajo riesgo, y no hay absolutamente ningún otro trabajo en progreso, simplemente hágalo y arréglelo. Podemos manejar una o dos alertas pequeñas corregidas "fuera del alcance" por Sprint , junto con los previstos". Eso es todo, muy simple. Comience a limpiar los registros y alertas uno por uno Además de las correcciones ocasionales, planifique la limpieza adecuadamente. Tenga en cuenta que por planificación me refiero a asignar tiempo diario/semanal para corregirlos, . Perderá más tiempo evaluando su prioridad que arreglando los primeros 5. Entonces, simplemente comience a arreglar. independientemente de su gravedad o prioridad Asegúrese de que haya una alerta para cada desarrollador, o si está acosando la mayor parte del tiempo, establezca un intervalo de tiempo diario para las alertas. Y lo haría a primera hora de la mañana porque de lo contrario, nunca lo harás. Una vez más, no es una característica nueva, y puede parecer que consume el tiempo de sus prioridades críticas, pero sus prioridades críticas ya están retrasadas debido a esos problemas ocultos. ¡Ya llegas tarde! ¡Elimine todas las declaraciones Try-Catch vacías y deje que se bloquee! Si bien las alertas y el registro expondrán mucho, no podrán registrar lo que oculta. Así que deja de esconder tus problemas debajo de la alfombra. Lo que se estrelló hace 2 años, y no sabías por qué, es completamente diferente hoy. Deja que se bloquee y arréglalo. Probablemente ni siquiera se bloquee de la misma manera, o ni siquiera se bloquee, por lo que, de una forma u otra, su código estará en mejor forma sin ellos. Comience a escribir pruebas unitarias ahora mismo Lo digo en serio. Estás trabajando en algún código ahora mismo. Entonces nada te impide escribir una prueba unitaria. ¡Ah, claro! No hay infraestructura lista para pruebas unitarias, ¿verdad? ¡Vamos! Vas a retrasar esa función de aspirante de todos modos. No necesita más de un día para configurar el marco de pruebas unitarias y su CI para ejecutar las pruebas. Hazlo. Iniciar TDD para corrección de errores "No sabemos cuál es el problema y cómo lo solucionaremos. No podemos escribir pruebas para un código que aún no existe". Mi querido desarrollador, el propósito de las pruebas es verificar una hipótesis. Eso es válido para las pruebas en general, no solo para las pruebas de software. Entonces, lo que necesita para escribir una prueba no es el código. Necesita el comportamiento y el resultado esperados. Ahora, si las historias de los usuarios son vagas y poco claras y no está listo para comenzar a escribir pruebas contra las historias de los usuarios, también tengo una solución para esto, pero antes de eso, comience a escribir el código de prueba primero para detectar errores. Hay un componente de la descripción del error llamado "Resultado esperado", y los pasos para reproducir son su caso de prueba. Así que ya tienes el caso de prueba frente a ti. Ahora, codifíquelo primero antes de comenzar a codificar la solución. El desarrollo basado en pruebas está escribiendo una prueba que valida que ha hecho el trabajo correcto, no que lo haya hecho bien. Las pruebas unitarias verifican si lo has hecho bien. Dibujar una hoja de ruta de cobertura La automatización de pruebas y la deuda tecnológica tienen destinos trágicos similares: nunca se inician porque "nunca podemos cubrirlo todo, nunca podemos limpiarlo todo, son demasiados gastos generales. No tenemos tiempo para eso". Escúchame: ¡no tienes que automatizar todo! Pero definitivamente debe automatizar sus elementos de misión crítica: casos de uso de alta prioridad, infraestructura crítica y funcionalidades principales. Llámelo como quiera, pero el negocio depende del 20 % de su código e infraestructura, y sus clientes utilizan el 20 % de sus funciones. Ves a dónde voy con esto. Ni siquiera necesita comenzar a escribir pruebas automatizadas para estas funciones en este momento. Lo primero que debes hacer es priorizarlos. Reúnase como equipo frente a sus diagramas de arquitectura de alto y bajo nivel. No hay ninguno, ¿verdad? ¿O las que existen son una foto de una pizarra tomada hace 2,5 años? Lo sé. Sí, necesita pasar medio día y actualizarlos. La buena noticia es que existen herramientas divertidas para ayudarlo, por lo que no necesitará mantenerlo manualmente. Investiga un poco. Después de todo, sois un equipo de I+D, ¿no? No apunte a una cobertura completa: apunte a un riesgo bajo y una confianza alta en su lugar Mientras diagrama su arquitectura e infraestructura actualizadas, agregue notas o círculos, o pinte en negrita o rojo todos los lugares que son: Misión crítica para su negocio y software Necesita desesperadamente una refactorización, o seguirá posponiendo esa otra característica de misión crítica todo el tiempo. Romper y comer constantemente su tiempo para arreglarlos es prácticamente en vano porque se romperán nuevamente en un par de días. Cuando los dibujos estén listos, siéntese con su equipo y haga una lluvia de ideas sobre lo que necesita probarse para todos estos componentes encerrados en un círculo. No caiga en la trampa de "¡esto es demasiado! ¡Debemos dejar de trabajar para cubrir todo esto!" No tienes que cubrir todo esto a la vez. Pero necesitas un plan. Ahora, abra otro tablero y comience a escribir sus objetivos de prueba. Ejemplos: Cubra todas las solicitudes de API de recuperación de datos para el éxito y el fracaso para que sepa que no envía solicitudes incorrectas y, si falla, falla debido al proveedor. Resuma el recorrido del usuario de misión crítica. Divídelo en unidades. Escribe las pruebas unitarias. Cuando se inventó la pirámide de prueba, una unidad significaba un componente, no un método, por lo que cubría la funcionalidad, no los métodos y las clases. Identifique los atascos y decida cómo los va a desenredar. Planea hacerlo bien. Su código rápido y sucio permanecerá sucio con pruebas sucias. Utilicé intencionalmente un Mapa de cobertura y no la Pirámide de prueba porque... en esta etapa, cuando no tiene ninguna prueba, manual o automatizada, no está listo para la Pirámide. Muchos equipos tienen la impresión equivocada de que primero tienen que lograr una cobertura de prueba unitaria del 96% y luego pasar a las pruebas de integración y así sucesivamente. El problema con la cobertura de pruebas unitarias modernas es que probamos Métodos y Clases, no funcionalidades. Incluso más equipos comienzan con la automatización de la interfaz de usuario, lo cual es igualmente incorrecto. Eso es en realidad lo peor que puedes hacer, y está condenado al fracaso. Por lo tanto, no comience desde la parte superior o inferior de la pirámide, sino que construya un mapa de riesgos. Algunas funciones pueden necesitar pruebas de integración exhaustivas, otras funciones pueden necesitar pruebas de interfaz de usuario exhaustivas, y la siguiente parte podría ser una función central de la que todo depende (sin embargo, otra señal de alerta), y debe cubrirla de arriba a abajo por completo. O es un servicio de recopilación de datos y debe centrarse en el rendimiento de las API, por ejemplo. Cree un mapa de los puntos de acceso de su software que necesitan pruebas exhaustivas. Luego, piense en cómo puede automatizar esas pruebas. No puedes progresar en arenas movedizas y solo tú puedes salir de allí Terminemos: no hay pruebas, el código está en mal estado y no tienes tiempo. Sigues haciendo concesiones porque "no tienes tiempo". No eres del todo feliz, o al menos eres bastante ignorante: ellos pagan, es su decisión y no es tu decisión. Si no están contentos, pasarás a la siguiente empresa. Bueno, las cosas cambiaron mucho el año pasado, ¿no? Debe ser un desarrollador destacado para seguir contratado. Las empresas aprendieron que podían deshacerse de las personas independientemente de su contribución. Aún así, hay ingenieros que una empresa hará todo lo posible para mantener. Para ser uno de ellos, debe impulsar el cambio y demostrar constantemente que el negocio depende de personas como usted. Todo el mundo puede escribir software de mala calidad, pero los realmente buenos no solo escriben software excelente con alegría, sino que también inspiran a otros y difunden la cultura de la calidad del código. No puedes progresar en arenas movedizas, y solo tú puedes salir.

Read My Stories

Say "Hi!"

Buy Me a Coffee

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Making security fun one episode at a time

Nunca lo arreglarás más tarde: cómo sacar a tu equipo de las arenas movedizas

Demasiado Largo; Para Leer

Hris Koleva

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

Nunca lo arreglarás más tarde: cómo sacar a tu equipo de las arenas movedizas

Demasiado Largo; Para Leer

Hris Koleva

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

HISTORIAS RELACIONADAS