Llevar una tarea hasta producción
La diferencia más visible entre alguien que recién empieza y alguien con un par de años no es la calidad del código: es dónde considera que termina su trabajo. «Ya hice mi parte» y «está funcionando para los usuarios» son dos definiciones muy distintas de terminado.
Dos personas hacen la misma tarea. La primera escribe el código, abre el cambio para revisión y pasa a lo siguiente. La segunda hace lo mismo, y además verifica en producción que el caso real funciona, revisa que no haya empezado a aparecer un error nuevo en los registros y le avisa a quien lo pidió que ya está disponible.
El código puede ser idéntico. La segunda persona tiene ownership y la primera no, y la diferencia se nota en la cantidad de cosas que quedan a medias en un equipo.
Dónde termina una tarea
| Definición de terminado | Qué queda sin cubrir |
|---|---|
| «Escribí el código» | Que funcione integrado, que alguien lo revise, que llegue a los usuarios |
| «Pasaron los tests» | Que los tests cubran el caso real; el comportamiento con datos de producción |
| «Está aprobado» | Que se haya desplegado y que efectivamente funcione ahí |
| «Está en producción» | Que el caso de uso real funcione y que quien lo pidió lo sepa |
| «Funciona para los usuarios y quien lo pidió lo sabe» | Nada: eso es terminado |
Antes de decir que está listo
La lista mínima
- Probaste el caso real, no sólo el feliz. Qué pasa si el campo viene vacío, si el usuario no tiene permisos, si el servicio externo tarda.
- Miraste tu propio cambio antes de que lo mire otro. Leer el diff completo antes de pedir revisión encuentra la mitad de los comentarios que ibas a recibir: código de depuración olvidado, un archivo que no correspondía, un nombre que quedó mal.
- El cambio se puede entender sin vos. Una descripción que diga qué problema resuelve y cómo probarlo. Quien revisa no tiene el contexto que tenés vos.
- Sabés cómo verificarlo en producción. Qué vas a mirar para saber que funcionó: una pantalla, un registro, una métrica.
- Sabés cómo volver atrás. Si rompe, qué se hace. Aunque sea «se revierte el despliegue».
Antes de seguir, predecí
Después de desplegar
Los primeros minutos después de que algo sale son los más informativos del proceso entero, y casi nadie los usa:
- Probá el caso real vos mismo, con datos reales si podés, o con una cuenta de prueba.
- Mirá los registros de errores unos minutos. Un error nuevo que aparece justo ahora casi siempre es tuyo.
- Avisá a quien lo pidió, con una frase de qué cambió y cómo verlo. Es lo que hace que la próxima vez te consulten a vos.
- Si algo está raro, decilo antes de que pregunten. Avisar vos de un problema propio vale mucho más que ser descubierto.
Una ayuda que no parece de comunicación
Buena parte de la dificultad de llevar algo hasta producción se resuelve antes, eligiendo el tamaño del cambio:
| Cambio de tres días | Cambio de medio día | |
|---|---|---|
| Revisión | Nadie quiere empezarla; queda dos días esperando | Se revisa en la hora |
| Riesgo al desplegar | Si algo falla, hay que buscar entre muchos cambios | Si algo falla, se sabe qué fue |
| Volver atrás | Se pierde todo el trabajo junto | Se revierte una pieza chica |
| Sensación de avance | Tres días sin cerrar nada | Algo terminado cada día |
Dónde termina la tarea
Escenario · 1 decisión como mínimo
El cambio está aprobado y desplegado. ¿Terminaste?
Arreglaste un error por el que los pedidos de más de diez ítems no se podían confirmar. El cambio está aprobado, mezclado y desplegado hace veinte minutos. ¿Qué hacés?
Tres días después, quien reportó el error vuelve a escribir: sigue sin poder confirmar.
DesenlaceEl cambio estaba bien y la configuración de producción tenía un límite distinto. «Está desplegado» es una afirmación sobre el sistema de despliegue, no sobre el problema de la persona que lo reportó.
Avisás. A la hora te responden que sigue igual.
DesenlacePeor que no avisar: quedó dicho que estaba resuelto y no lo estaba. Conviene el orden inverso, que además cuesta lo mismo: comprobar y después avisar.
Probás y funciona. ¿Y ahora?
Al día siguiente aparece un pico de errores en el cálculo de envío.
DesenlaceEstaba relacionado, y se descubrió veinte horas más tarde, cuando ya nadie asociaba las dos cosas. Los diez minutos de mirar los registros después de desplegar son los que hacen barata esa conexión.
No hay errores nuevos. Quedan dos cosas por hacer. ¿Cuál priorizás?
El ticket queda cerrado. Quien lo reportó se entera dos semanas después, de casualidad.
DesenlaceEl estado del ticket es información para el equipo, no para quien tenía el problema. Una tarea que empezó con una persona reportando algo termina cuando esa persona sabe que ya puede hacer lo que quería hacer.
Agregás el test y pasa.
DesenlaceBien hecho, y falta el aviso. La diferencia entre las dos personas del principio no está en el código: está en la cantidad de cosas que quedan a medias alrededor del código.
Le avisás, le decís cómo probarlo, y agregás el test en el mismo rato.
DesenlaceVerificado en producción, registros mirados, avisado a quien lo pidió y cubierto para que no vuelva. Todo eso suma unos quince minutos sobre el trabajo que ya estaba hecho, y es exactamente la diferencia entre que un equipo acumule cosas a medias o no.
El código estaba listo en el primer paso. Todo lo demás es lo que separa una tarea entregada de una terminada.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica