Cuando trabajamos en repositorios compartidos, siempre llega ese momento obligatorio: revisar código ajeno antes de aprobar una pull request (PR).
En esos momentos se nota mucho cómo reaccionamos cada uno. Algunos revisan el código rápidamente, otros se detienen más. No suele haber alguien específico encargado de mejorar continuamente el código, así que cada persona decide cómo actuar.
Según mi experiencia, podemos distinguir cuatro tipos de personas según cómo gestionan esta situación:
Grupo 1 🙄
La mayoría revisa la PR superficialmente, aprueba el código si cumple con los requisitos más básicos y pasa a otra tarea, ignorando pequeños problemas o posibles mejoras. Es decir, cumplen sus objetivos pero dejan deuda técnica acumulada que en el futuro alguien tendrá que resolver.
Grupo 2 🫥
Revisan el código, aprueban la PR y de vez en cuando realizan pequeños ajustes o sugerencias para evitar que el código empeore. Van un paso más allá para garantizar que el sistema no quede peor de lo que lo encontraron.
Grupo 3 🙃
Un grupo más pequeño aprovecha la PR para arreglar problemas técnicos, pero solo cuando estos bloquean o afectan directamente su propio trabajo o futuras tareas inmediatas.
Grupo 4 🤩
Un reducido grupo de developers utiliza activamente cada PR para mejorar proactivamente la calidad global del código, refactorizando o sugiriendo mejoras incluso cuando no son estrictamente necesarias para su trabajo a corto plazo o cuando no les afectan directamente.
La métrica de la PR
La “métrica de la PR” es una forma de evaluar nuestro impacto: ¿Somos capaces de identificar áreas de mejora y actuar sin que nadie nos lo pida?
A veces cuesta imaginar cómo se puede mejorar algo en tu trabajo. Pero si te fijas bien, hay muchas cosas que se pueden mejorar.
Aquí te propongo una forma de evaluar tu impacto:
-
Grupo 1: (por debajo de las expectativas): cumple únicamente con sus tareas inmediatas, dejando deuda técnica acumulada.
-
Grupo 2: (cumple expectativas): realiza sus tareas asegurándose de no empeorar el código existente.
-
Grupo 3: (cumple expectativas): mejora el código, pero solo cuando le afecta directamente.
-
Grupo 4: (supera expectativas): busca activamente mejorar el sistema para beneficio colectivo, incluso cuando no es directamente su responsabilidad o beneficio inmediato.
Ahora piensa en tu día a día y pregúntate:
¿En qué grupo encajo yo?
Déjame abajo un comentario diciendo con qué grupo te identificas. 👇