Un camino, cuatro formas de recorrerlo
Todo cambio sigue el mismo camino: lo describes, se elige un comando, se construye, se revisa y se vuelve un commit. Cómo pido un cambio recorre ese camino una vez.
Lo que cambia es cuánto de él usa realmente tu petición. Abajo están los cuatro tipos con los que te vas a topar, cada uno recorrido desde la frase que escribes hasta el commit, para que sepas de antemano dónde se va a detener el tuyo a preguntarte algo.
Algo pequeño y ya resuelto
Una etiqueta que dice algo equivocado. Una frase en una pantalla. Un espaciado, un color, el orden en que van dos elementos.
Dices qué debe decir y en qué pantalla. Aquí no se decide nada: no hay estado que distinguir, ni regla que salga de una forma para un registro y de otra para el siguiente, ni una segunda respuesta razonable entre la cual elegir.
Por eso se salta el paso de investigación. Lo que lo reemplaza es una sola lectura: se abre la pantalla que nombraste para confirmar que tiene lo que dijiste que tiene, y se busca en todo el proyecto lo que se va a cambiar para confirmar que no se lee en algún lado que no nombraste. Si sí se lee — el mismo texto apareciendo en otras dos pantallas —, la petición deja de ser de este tamaño y toma la ruta larga, porque alguien estaría leyendo algo que nadie decidió cambiar.
Después se construye, cada archivo que escribió pasa por el analizador y, si el resultado se ve en una pantalla, alguien la abre y la mira. Un commit. Esta es la ruta más rápida y la que toman casi todas las peticiones.
Lo que parece pequeño y no lo es. Una columna agregada a una lista, un filtro, un campo traído de otro lado. Se leen como peticiones de una línea, pero cambian lo que la pantalla trae, y ese es el cambio que más fácil la vuelve lenta — así que toman la ruta larga, y su velocidad se mide antes y después.
Algo que se ve
Una pantalla, un componente, un flujo, un control, datos mostrados.
La misma ruta que el tipo de petición al que pertenezca entre los otros tres. Lo que cambia es la prueba.
Un cambio que una persona ve nunca lo prueba el comando que lo escribió. Se le entrega al comando de verificación, que abre un navegador real, recorre lo prometido punto por punto y reporta un resultado por punto más un solo veredicto — sin aprobados a medias. Se recorre en cada estado que el plan distingue, no solo el que tu base de datos tenga en ese momento, y se recorre otra vez después del último paso que escribió datos, porque la validación misma puede mover un flujo a un estado que la primera pasada nunca vio.
Lo que se revisa no es que la página haya cargado. De cada elemento se revisa que se vea completo y sin nada encima; de un modal, que abra sobre la página, que haga scroll dentro de sí mismo y que no deje atrás ni fondo ni scroll trabado al cerrarse. Cada resultado nombra la pantalla y el elemento.
Una pasada que falla produce una corrección, no una excusa. La verificación escribe ella misma la corrección, en el mismo plan y lista para construirse, y el ciclo corre otra vez — tres construcciones en total. Después de eso lo que hay que revisar es el plan, y se te dice en lugar de dejarte ver un cuarto intento.
Algo complejo
Decide algo. Alcanza varios lados. O todavía no está claro qué debería hacer.
Este es el que se planea antes de construirse. Si de todos modos pediste que se construyera, la corrida se detiene antes de tocar un archivo, te entrega juntos todos los huecos que encontró y te dice que lo planees — no abre la planeación por ti y no contesta la mitad de las preguntas aquí y la otra mitad allá.
La planeación lee lo que el proyecto ya documenta, explora el código por lo que eso deja abierto, te pone todo el alcance de una sola vez y te pregunta solo lo que leer no puede resolver. Después revisa contra el código cada afirmación que hace el plan antes de escribirlo, para que una decisión apoyada en algo falso se atrape antes de volverse trabajo. También lee el código que el cambio alcanza, así que las elecciones técnicas que cambian el riesgo o el costo se preguntan ahora y no a mitad de la construcción, y el plan termina con un plan técnico: por dónde pasa el cambio y los riesgos a cuidar. Cuando el cambio es algo que vas a ver, se te muestra un dibujo de la pantalla como está y como quedaría, y apruebas el diseño antes de que se construya nada.
Lo que recibes de vuelta es un plan escrito, guardado en tu proyecto para que sobreviva a la conversación. El paso de construcción lo sigue en lugar de improvisar, trata sus decisiones como resueltas y no las reabre a mitad del camino. Su plan técnico es la única parte que se sigue como guía: donde el código resulta distinto, la construcción lo corrige y sigue sin preguntarte, salvo que la corrección cambie lo que el plan pide. Si el código termina contradiciendo algo de lo que el plan partía, la corrida se detiene y lo regresa a planeación en vez de adivinar — porque todo lo que se construyó encima de esa afirmación se construyó sobre algo falso.
Planear antes de construir cubre qué te pregunta y qué deja escrito.
Algo urgente y roto
Ayer funcionaba. Hoy no. Hay gente esperando.
Di que está roto y di qué ves: la pantalla, qué hiciste, qué pasó y a quién le pasa. Si solo falla para un rol o para un tipo de registro, dilo también.
Lo primero que pasa es que se reproduce. Antes de modificar un solo archivo, se llega a la falla por donde de verdad se ejercita — la pantalla para lo que ves, el comando o el job para lo que no — y en los estados que nombraste. Un defecto que no se reproduce se detiene ahí y te pregunta, en lugar de recibir un arreglo especulativo: un arreglo apuntado a algo que no está pasando es un cambio que nadie puede verificar.
Una vez que se reproduce, el arreglo es el más pequeño que hace funcionar el comportamiento confirmado. El comportamiento existente fuera del defecto se conserva, y un rediseño, una reescritura o una mejora de pasada no es lo que un defecto compra — a menos que lo hayas pedido.
Si el cambio urgente se tiene que planear, di que es urgente cuando la planeación lo pregunte. Esa respuesta tiene un efecto concreto: un proyecto sin visión de producto escrita normalmente tiene que escribirla antes de que empiece la planeación, y una tarea urgente sigue sin ella y se le dice que la visión igual vale la pena después; ve Escribir la visión del producto.
Qué no se salta por tener prisa. El analizador sigue corriendo sobre cada archivo que se escribió, hasta que salen limpios. Lo que se ve sigue abriéndose en un navegador y recorriéndose punto por punto. No se hace push, no se crea rama, y nada que ya funcionaba se arranca para hacerle lugar al arreglo. La urgencia cambia qué se investiga, nunca qué se prueba.
Sigue por aquí
- Cómo pido un cambio — el camino completo de una pasada, con el diagrama.
- Planear antes de construir — la bifurcación de la que depende la ruta compleja.
- Qué hace cada comando — el comando detrás de cada una de estas rutas.