Trabajar con múltiples herramientas implica saltar constantemente entre JIRA, GitHub y tu editor de código. Ese cambio de contexto consume tiempo y genera fricción. Existe una forma más eficiente de gestionar pull requests, revisar código y dejar comentarios sin salir de VSCode, y aquí se explica paso a paso cómo lograrlo.
¿Por qué el cambio de contexto reduce tu productividad?
Cuando una tarea en JIRA se marca como done, eso se materializa en la creación de un pull request en GitHub [00:15]. Para entender qué sucede, necesitas revisar JIRA, luego abrir GitHub para ver los comentarios del pull request, y finalmente volver a VSCode para inspeccionar el archivo completo [00:36]. Cada salto entre herramientas interrumpe tu concentración y ralentiza el flujo de trabajo.
La pregunta clave es directa: ¿no sería más fácil tener todo integrado? La respuesta está en lo que se denomina el flujo moderno en VSCode, que centraliza la revisión de pull requests directamente dentro del editor.
¿Cómo funciona la revisión de pull requests dentro de VSCode?
Al abrir VSCode con las extensiones de GitHub configuradas, el pull request pendiente aparece en la sección waiting for my review [01:02]. Al abrirlo, se muestra exactamente la misma información que verías en GitHub.com, pero integrada en tu editor.
La ventaja principal es que puedes comparar los cambios utilizando el diff nativo del editor, que resulta mucho más potente que el que ofrece un navegador [01:14]. Esto permite:
- Revisar archivos modificados con mayor detalle.
- Detectar errores que podrían pasar desapercibidos en la interfaz web.
- Mantener el foco en un solo entorno de trabajo.
¿Qué es un code mark y cómo se utiliza?
Durante la revisión, puede surgir un error adicional que no estaba contemplado en el pull request original. En el ejemplo práctico, se detecta que el color del footer no cumple con el nuevo estándar corporativo [01:30].
Para señalar este problema se utiliza un code mark, que es un comentario asociado directamente a una línea o sección específica del código [01:40]. Al agregarlo:
- Se visualiza como un rectángulo azul en el editor, marcando la existencia de esa anotación.
- Se sincroniza automáticamente con el pull request en GitHub.
Esto representa una capacidad poderosa: por primera vez puedes agregar un comentario sobre cualquier parte del archivo, incluso si no está directamente relacionada con los cambios del pull request [01:58]. Se abre así la puerta a revisiones más completas y contextuales.
¿Cómo se sincroniza la revisión con GitHub?
Una vez redactado el comentario, se regresa a la sección conversation dentro de VSCode para verificar que el mensaje aparece correctamente [02:10]. Desde ahí se hace submit para incorporarlo a la revisión.
Al cerrar la revisión, todo vuelve a su estado anterior sin necesidad de cambiar de branch ni gestionar un stash [02:22]. Lo que estabas haciendo antes de la revisión permanece exactamente como lo dejaste. Esta es una diferencia crucial frente al flujo tradicional, donde revisar un pull request suele implicar interrupciones en tu trabajo local.
Al volver a GitHub.com, se confirma que todo el trabajo realizado desde VSCode está reflejado en el pull request [02:32].
¿Qué ventaja tiene adoptar el flujo moderno aunque trabajes solo?
Un punto importante es que no necesitas que todo tu equipo adopte este flujo para obtener beneficios [02:40]. Aunque seas la única persona utilizando la integración directa en VSCode, la ganancia en eficiencia es inmediata:
- Reduces el tiempo invertido en cambiar entre aplicaciones.
- Realizas revisiones más profundas con las herramientas nativas del editor.
- Mantienes tu entorno de desarrollo intacto durante y después de la revisión.
Esa ventaja competitiva se nota cuando comparas tu velocidad y precisión con la del resto del equipo que sigue el flujo tradicional. Integrar pull requests, comentarios y revisiones en un solo lugar transforma la manera en que gestionas tu código día a día.
¿Ya probaste este flujo en tu equipo? Comparte tu experiencia en los comentarios.
