Entrar en el código de otro desarrollador sin tumbar lo que está al aire
El sistema ya tiene clientes usándolo y dinero pasando. Cómo tomarlo sin romper nada, y por dónde empiezo.
El que llega después hereda el sistema y la culpa
Buena parte de lo que hago no empieza en una carpeta vacía. Empieza en un sistema que ya está al aire, con clientes usándolo, a veces con dinero pasando, y con el desarrollador anterior fuera del juego.
Es un trabajo distinto a escribir desde cero, y la trampa más grande es tratarlo como si fuera igual. El que llega y reescribe todo no entrega más rápido: entrega un segundo sistema roto al lado del primero.
Primer día: no tocar nada
El primer día es de lectura. Levanto el proyecto local, lo corro, e intento reproducir el camino principal completo: registro, login, la operación que genera dinero y lo que pasa después de ella.
Mientras tanto voy anotando dos listas. La primera es lo que no entendí. La segunda es lo que me asustó. La segunda es la que importa: de ahí sale el orden del trabajo.
El error que no aparece es el más caro
El patrón que más encuentro en sistema heredado no es código feo. Es error tragado: la ruta hace el trabajo, alguna etapa falla a mitad de camino, y la respuesta vuelve como si todo hubiera salido bien.
Pasa por una razón fácil de entender. Alguien, en algún momento, se cansó de ver errores en pantalla y envolvió el trecho en un bloque que captura todo y sigue adelante. El sistema deja de reclamar y todos creen que mejoró.
Solo que ahora el problema cambió de lugar: en vez de aparecer al instante, aparece a fin de mes, en la conciliación, cuando el número no cuadra. En una pasarela de pago eso es la diferencia entre un bug y una pérdida.
Cómo lo encuentro
Busco tres cosas, en ese orden. Primero, todo lugar que captura una excepción y no hace nada con ella: ahí es donde el error está enterrado. Segundo, toda respuesta de éxito que no verifica si la etapa anterior realmente ocurrió. Tercero, logs: si no existen, el sistema es una caja negra y cualquier arreglo es adivinanza.
Antes de corregir, hago que el error aparezca. Log estructurado con el identificador de la operación, y la falla subiendo en vez de desaparecer. Suele ser incómodo, porque de repente el sistema empieza a gritar cosas que venían pasando en silencio hace meses.
Cerrar la fuga antes de refactorizar
Las ganas de reordenar todo son grandes y es el momento equivocado. Primero cierro lo que se fuga: las rutas que mienten, el dato que entra sin validación, el dinero que cambia de estado sin registro.
La refactorización viene después, y viene por partes, siempre detrás de algo que ya funcione y esté probado. El cliente no paga por código bonito, paga por un sistema que deja de dar problemas.
Reescribir desde cero casi nunca es la respuesta
Todo desarrollador que toma código ajeno siente ganas de proponer la reescritura. Yo la sentí, y algunas veces la propuse mal.
El sistema feo que está al aire carga años de reglas de negocio que nadie documentó, y buena parte está escondida en una condición rara a mitad de una función. Reescribir significa redescubrir todo eso a costa de pérdidas, un cliente enojado a la vez.
La reescritura compensa cuando la tecnología impide el próximo paso, no cuando el código es feo. Lo feo se arregla por partes, sin apagar la luz.
Cómo trabajo en esto
Entro con acceso propio y ambiente separado del que ya existe, para no mezclar lo mío con lo del otro desarrollador. Levanto la lista de riesgos, cierro lo que se fuga, y recién después sigo hacia lo que quieres construir.
Si tienes un sistema al aire y el desarrollador desapareció, ese es exactamente el servicio. Escríbeme y te digo qué se puede salvar.
¿Tienes un sistema al aire sin dueño?
Tomo lo que otra persona empezó, cierro lo que se fuga y sigo desde ahí.