5 sugerencias para enfrentar una revisión de código
Pull requests, desde la comodidad de tu sofá
En el equipo de desarrollo de Get on Board tenemos la práctica de que nada pasa a producción sin un Pull Request que haya sido aprobado por otrx miembrx del equipo. Si bien esto partió simplemente como una manera de reducir los bugs en producción, con el tiempo han aparecido un montón de enseñanzas adicionales que tienen mucho potencial para enriquecer las relaciones personales y el desarrollo técnico.
Esta es una lista con algunas de las cosas que se han vuelto importantes para mí a la hora de enfrentarme a una revisión de código y que buscan ir un poco más allá de la simple revisión de errores:
1 Revisar el código final y también su historia
Suele ser una tentación pasar directo desde la descripción del PR a la pestaña Files changed, donde se puede revisar el resultado final del nuevo código propuesto. Ten en mente que quedarse sólo con esta parte es dejar fuera el camino que siguió el o la autora del trabajo.
Para aprender sobre esa historia y saber cómo fue enfrentado el problema paso a paso, puedes revisar el historial de commits en sentido cronológico. Con esto puedes aprender de tus compañerxs sobre su manera de resolver un problema y probablemente entender por qué utilizó una solución en vez de otra. Un beneficio concreto de esta práctica es poder comentar con mayor contexto e incluso ahorrarse preguntas que se pueden explicar entendiendo el camino seguido.
2 Entender el problema
El editor de un libro no sólo se preocupa de que haya precisión ortográfica y gramatical, también debe velar por que exista un relato interesante, bien estructurado y que explique lo que se quiere comunicar de la mejor manera posible.
Revisar un PR es lo mismo. También es una responsabilidad editorial sobre lo que se está agregando en el proyecto. No estamos sólo revisando código, estamos revisando un producto que será utilizado por usuarios. Es por esto que cuando revisamos un PR podemos ser mucho más útiles en sugerir mejoras si entendemos bien cuál es el problema que se está intentando solucionar.
Además, cuando entendemos bien qué hay detrás del código, se vuelve muchísimo más fácil responder preguntas como:
- ¿Hemos solucionado este tipo de problemas antes? ¿Qué enseñanzas obtuvimos del pasado?
- ¿Es esto una prueba de concepto o estamos mejorando una parte madura del proyecto?
- ¿Necesita soportar el uso de muchísimxs usuarios o es algo interno que utilizarán sólo unos pocos?
- ¿Es una solución para un caso aislado o algo que podría ser reutilizado?
- ¿Qué tan urgente es despachar esta solución?
3 Calidad ≠ Estilo
# Code on the PR
function doSomething() {...}# I suggest to do it like this
const doSomething () => {...}
¿Por qué sugerir un cambio a una función de flecha? ¿Lo sugiero para que se lea/entienda mejor? ¿Para ahorrar escribir return? ¿Estoy considerando cuándo será invocada?
Todas son posibilidades válidas, pero cuando el motivo es: “Porque es más moderno”, puede que no sea una sugerencia tan relevante. Trata de siempre entender por qué sugieres algo y ojalá puedas argumentar de manera objetiva que mejoras introduce tu sugerencia.
También existe un área gris donde los argumentos no son respaldados por datos duros, pero que pueden ser igualmente válidos. Un ejemplo de esto es decir: “sugiero escribir esto de X manera porque me parece que es más fácil de leer para los devs del mañana”. Es algo absolutamente discutible, pero totalmente válido y aplicable.
4 Utiliza sugerencias de Github
Una funcionalidad que ahorra un montón de tiempo son las sugerencias de Github. Si encuentras un error de ortografía (por ejemplo), es una gran pérdida de tiempo dejar el comentario y esperar por un nuevo commit por parte del autor/a. Si haces una sugerencia, el/la autor/a podrá agregar este código desde la misma interfaz de manera súper fácil.
No olvides acompañar la sugerencia de un comentario explicativo en caso de ser necesario. Así la persona que sea autora del PR entenderá los motivos y podrá decidir mejor si iniciar un debate o agregar el código directamente.
5 Comunicación respetuosa y empática
El lenguaje escrito no es sencillo, especialmente cuando estás revisando el trabajo que probablemente le costó mucho a otra persona.
Es muy fácil que un comentario escrito sin precisión se interprete como una crítica o agresión. En un equipo que busca potenciar las capacidades de sus integrantes es importante que nos sintamos apoyados y entender que las críticas deben estar motivadas por lograr un mejor resultado y no por desacreditar el trabajo de otro integrante.
Es importante que las personas del equipo sientan confianza, se atrevan a opinar y no sientan miedo a la crítica. Un buen lenguaje es clave para potenciar esta cultura.
¿Algo para concluir?
Todas estas prácticas están enfocadas en que todxs entendamos mejor el software como un espacio de colaboración colectivo donde se crean soluciones para usuarixs reales. En estas instancias existe la oportunidad de entender un poco mejor que detrás del equipo de desarrollo y de lxs usuarixs existen personas reales. No pierdas de vista que las personas tienen historias y aprendizajes que casi siempre son muy relevantes.
