Mi experiencia haciéndome cargo del proyecto de un compañero

Cuanto más tiempo pasas en este sector, más probable es que llegue el momento de hacerse cargo del proyecto de un compañero.

Todavía recuerdo la primera vez que recibí formalmente el traspaso del proyecto de un compañero que iba a dejar la empresa. Lo que hice fue:

Clonar el proyecto, copiar el archivo env, configurar la IP de la base de datos, intentar levantar el servicio y apañármelas para que funcionara el entorno local de Python (hasta entonces apenas había trabajado con Python, y el proyecto estaba hecho con Django). Después escuché cómo mi compañero me explicaba cómo conectarme a los servidores de producción y de pruebas, y cómo realizar los despliegues manualmente.

Básicamente, escuchaba todo lo que me explicaban, tomaba notas lo más rápido posible y hasta grababa las sesiones de traspaso para poder volver a escucharlas más adelante si necesitaba confirmar alguna información.

Más adelante me tocó hacerme cargo de otro proyecto. Esta vez no era un servicio web, sino un pipeline de procesamiento de datos. Mi compañero me proporcionó las IP de las distintas máquinas del pipeline, las tareas de las que se encargaba cada una, el panel de control para supervisar si los procesos se habían completado correctamente, el panel para administrar las máquinas, etc.

En esencia, era la “presentación oficial” del proyecto.

A medida que fui adquiriendo más experiencia como desarrollador, empecé a tener otra perspectiva. En este nuevo traspaso, comencé a buscar información de forma más activa:

• Si surge un problema, ¿cómo lo depuras? ¿Por dónde empiezas a mirar? ¿Por el panel de monitorización? ¿Por las alertas de los servicios en la nube?

• ¿Qué tipo de problemas ocurren con más frecuencia? ¿Cada cuánto suceden? ¿Cómo suelen manifestarse? ¿Es un cliente quien avisa de que la web no funciona o lo detectáis vosotros mismos?

• Siguiendo con la pregunta anterior: ¿cómo lo resolviste la última vez?

• ¿Qué incidencias están actualmente a medio resolver? ¿Quién informó del problema? ¿Cuál crees que es la causa? ¿Hasta qué punto se ha investigado? ¿Cómo puedo comprobar más adelante si realmente está solucionado?

• Si quiero ejecutar pruebas por mi cuenta, ¿qué conjunto de datos puedo utilizar sin afectar a nadie más?

Todos estos puntos podrían resumirse como hacer preguntas imaginando el proyecto desde la perspectiva de quien va a desarrollarlo y mantenerlo.

También me gustaría añadir algo más. Durante un traspaso, es muy fácil centrarse demasiado en el propio proyecto. Sin embargo, en mi experiencia: Todo lo que se puede encontrar en el código es lo menos importante. Lo realmente importante es lo que no está en el código, incluyendo:

• ¿Con qué servicios externos se integra el proyecto? ¿Tienen esos servicios algún panel de administración? Si lo tienen, ¿cuáles son las cuentas y credenciales necesarias?

• El desarrollo siempre requiere validaciones. Algunas funcionalidades dependen de sistemas externos. Por ejemplo, al desarrollar características relacionadas con plataformas de comercio electrónico, suele ser necesario disponer de una tienda online destinada específicamente a pruebas de desarrollo. Allí se instala el servicio que se está desarrollando para poder realizar las verificaciones necesarias.

  (Tengo que reconocer el mérito de Shopify. Su ecosistema y la experiencia para desarrolladores son impresionantes: puedes crear una tienda de pruebas con un solo clic y además te genera datos de ejemplo automáticamente).

“Lo que no está dentro del proyecto es lo más importante”. Pongo un ejemplo:

Imaginemos que el entorno de producción y el entorno de pruebas comparten la misma clave de acceso de un servicio externo (por ejemplo, un servicio de envío de correos electrónicos; pongamos Brevo como ejemplo). En teoría, producción y pruebas son entornos independientes. Sin embargo, desde la perspectiva de Brevo, ambos están utilizando la misma cuenta. Eso significa que comparten el mismo conjunto de datos. Como consecuencia, pueden aparecer todo tipo de situaciones extrañas: errores al crear registros duplicados, listas de correo que tienen identificadores independientes dentro de cada entorno pero que acaban entrando en conflicto dentro de Brevo, y otros comportamientos inesperados de ese estilo.

En fin, estas son algunas de las lecciones que he aprendido con el tiempo. Espero que os resulten útiles.