Front.id

Lunes por la mañana, hoy toca proyecto nuevo. Haces una reunión de grooming, con los gestores de proyecto, el equipo entero, el CTO y todo el que se quería apuntar.

Empezamos un proyecto nuevo (BIENNNNNNN) pero el proyecto es heredado (OUCHHHH).

Tu sentido arácnido de desarrollador está saltando todas las alarmas, vas con una mezcla de ilusión y miedo. El proyecto es muy chulo, pero ... ¿por qué el cliente ha decidido cambiar de proveedor?

Después de la reunión en la que te han contado "todo" y llega el momento de la verdad, ya te han dado acceso al repositorio, te lo clonas en local y ... empieza la fiesta.

Esta historia nos suena a muchos, y muchas veces continúa con unos días en los que tirando de git blame encuentras nombres de personas. Te gustaría preguntar a esas personas qué se les pasaba por la cabeza cuando hicieron lo que hicieron y en casos extremos los buscas en facebook para ponerles cara.

No se puede juzgar la calidad de un equipo de desarrollo solo por el resultado final de su trabajo, eso sería muy injusto. No se sabe las circunstancias de presión, las instrucciones que siguen, incluso si tenían subcontratado un desarrollador en Sierra de Fuentes, que hacía los commits en nombre de alguien del equipo y le pagaban en negro (perdonad la exageración, pero estoy buscando casos extremos y absurdos para ilustrar la idea).

Lo que si es cierto es que hay algunos hábitos que evitan que pasen cosas como la que voy a describir a continuación.

Cazando fantasmas

Estamos mirando un proyecto de otra persona y nos encontramos un módulo llamado chupimodule_news y hay una sección de noticias en la web.

• Nos ponemos a estudiar como funciona y hay cosas que no entedemos bien.
• Nos ponemos a hacer una traza con el depurador y no se para nunca.
• Limpiamos las cachés.
• Revisitamos la web como admin, con otro navegador, con tokens raros en la URL....
• Aquello no se para.
• Haces de todo y de repente te das cuenta de que el módulo no está ni activado.

¿Cómo se llegan a desplegar estas cosas a producción?

Puede ser por diversos motivos, pero uno de los que más me he encontrado es el siguiente.

Amador el Programador (nombre ficticio de un desarrollador cualquiera) se enfrenta a su tarea y comienza a hacer un módulo, un plugin, lo que sea. A mitad de su tarea, coincide con Ana María LaInformática y hablan del asunto. Ana María le cuenta a Amador que ella hizo algo parecido en otro proyecto y solo era activar tal configuración en otro lado. Amador lo prueba y funciona, con lo que termina su tarea y está todo contento.

Hace su commit, hace su push, pone el ticket a revisar, lo aceptan y listo, a por otro.

¿Qué problema había?

Pues que empezó el ticket sin hacerse una rama nueva he hizo su commit directamente en master (o cualquier otra rama común a todo el mundo) por lo que tenía que acordarse de borrar el módulo que estaba escribiendo. Estaba tan emocionado con la solución que había encontrado que se olvidó de borrarlo.

Al hacer los commits directamente en master no puedes hacerte un Pull Request (o Merge Request si eres de gitlab) y nadie, ni él mismo ni otra persona que revisara su código pudo preguntar "¿qué hace este módulo aquí si se ha resuelto activando un checkbox?"

Ese módulo se queda ahí por los siglos de los siglos y como no molesta, porque Amador conoce el proyecto y sabe que no vale para nada, nadie lo borra, simplemente está ahí.

Por todo esto un consejo

Siempre que empieces a hacer algo, hazte una rama para ese algo y después no hagas el merge o el rebase directamente a la rama de la que suelen salir todos los tickets, utiliza los Pull Request, Merge Request o simplemete un diff para poder revisar todo lo que estás a punto de meter en el repositorio común.

Aunque no te lo vaya a revisar nadie, tu código se merece que tu mismo le des una pequeña revisión por encima antes de darlo por terminado.

Imágenes:

 - Beverly Hills Cop III - Paramount pictures

 - Stickers de telegram "la Cosa"

 - Games of Thrones  - HBO