Revisar código no tiene por qué implicar procesos largos ni herramientas adicionales. Con el feedback request de CodeStream, cualquier cambio en tu editor puede empaquetarse y enviarse a un revisor en segundos, sin commits previos ni solicitudes formales. Este flujo simplifica la colaboración y genera documentación útil de forma orgánica.
¿Qué diferencia al feedback request del pull request?
El feedback request elimina la formalidad del pull request tradicional [0:14]. No necesitas crear una solicitud formal ni invocar herramientas externas que se encadenan después. Simplemente decides que el estado actual de tus cambios —incluso aquellos que no han sido guardados localmente— puede presentarse al revisor de acuerdo a tus indicaciones.
Esto significa que el código antes del commit ya es revisable. Puedes incluir trabajo en progreso, commits parciales o modificaciones sin guardar. La flexibilidad es total.
¿Cómo se inicia un feedback request desde CodeStream?
Desde la sección de issues en CodeStream, seleccionas el ticket correspondiente —en el ejemplo, "agregar ciudad al formulario de registro" [1:16]. El flujo permite mover el ticket a in progress, crear un feature branch con nombre automático mediante un template y notificar al equipo por Slack.
Una vez editado el código en VSCode, en lugar de hacer un commit tradicional, accedes a la sección Work in Progress de CodeStream y haces clic en el botón Feedback Request [1:46]. Se abre un diálogo donde:
- Asignas un título al pedido, reutilizando el del ticket con la opción current ticket.
- El revisor se sugiere automáticamente gracias a git blame, que identifica al autor original del código [2:10].
- Puedes agregar commits o incluir solo el trabajo en progreso sin proceso formal.
Al hacer clic en el archivo modificado, aparece el diff con todo el contexto del editor, permitiendo entender exactamente qué cambió [2:46].
¿Cómo recibe y actúa el revisor?
El revisor —Gustavo en el ejemplo— recibe una notificación toast [3:12]. Al hacer clic en open, ve los detalles directamente en su editor. Un punto crucial: aunque Gustavo esté trabajando en un branch diferente o tenga modificaciones locales sin commit, puede ver los cambios sin perturbar el estado de su editor [3:26].
Al revisar el diff, Gustavo detecta que el campo ciudad no está marcado como requerido. Selecciona el texto, hace clic en Add comment y escribe su observación [3:48]. Luego selecciona la opción Change request, que convierte el comentario en un pedido formal de modificación.
¿Cómo se resuelve un pedido de cambio sin salir del editor?
Del lado de Marcelo, aparece otra notificación toast de Gustavo [4:14]. Al abrirla, CodeStream lo lleva directamente al feedback request y puede saltar a la línea exacta donde debe aplicar el cambio. El comentario de Gustavo aparece en un bloque azul sobre el código.
Estos comentarios se transforman en documentación viva: explican por qué se realizaron los cambios y en qué momento [4:40]. No es documentación adicional que alguien deba escribir aparte; surge naturalmente del proceso de revisión.
Marcelo implementa la corrección y, una vez más, sin necesidad de un commit, presenta sus cambios mediante el botón amend [4:56]. En el diálogo, marca que el cambio solicitado fue resuelto.
¿Cómo se aprueba el resultado final?
Gustavo recibe la notificación del cambio realizado, revisa el nuevo diff donde el campo ciudad ahora es requerido y, satisfecho, aprueba el cambio [5:16]. El trabajo queda completado y aprobado en un flujo continuo.
Los beneficios concretos de este flujo moderno son claros:
- Revisión de código más ágil e informal.
- Menos pasos comparado con el pull request tradicional.
- Documentación automática que puede compartirse con toda la organización.
- El revisor nunca pierde el contexto de su propio trabajo.
¿Ya utilizas feedback requests en tu equipo o sigues con el flujo tradicional de pull requests? Comparte tu experiencia y cómo ha cambiado tu proceso de revisión.
