Comprender antes de cambiar
Investigación de comportamiento heredado, relaciones de datos, rutas de acceso y causas raíz antes de realizar cambios controlados.
Cambiar un sistema existente requiere comprender qué depende ya de él.
En Minu, parte de mi trabajo consistía en dar soporte a un portal web heredado y aplicaciones más antiguas que habían acumulado reglas de negocio, relaciones de datos y comportamiento a lo largo del tiempo.
Algunos problemas no eran causados por un único defecto evidente. El comportamiento observado podía ser resultado de cómo interactuaban la lógica de aplicación, estructura de base de datos, flujos de usuario y reglas de negocio.
Antes de cambiar algo, necesitaba comprender cómo se producía el comportamiento y qué otras partes del sistema podían verse afectadas por el cambio.
El problema visible a menudo era solo el primer síntoma.
Algunos incidentes parecían simples desde fuera: información incorrecta, funcionalidad rota, comportamiento inesperado o usuarios que accedían a datos que no deberían haber podido consultar.
El desafío real era determinar dónde el sistema se desviaba por primera vez del comportamiento esperado. La causa podía estar en la lógica de aplicación, la consulta, los datos subyacentes o la relación entre distintas partes del sistema.
Corregir solo el síntoma visible podía dejar intacto el problema subyacente o introducir un nuevo problema en otra parte de la aplicación.
Parte de la información mostrada por la aplicación no provenía de la fuente correcta o era producida por consultas que no representaban la relación de negocio prevista.
Las funcionalidades existentes podían fallar por datos inesperados, lógica de aplicación o problemas de compatibilidad entre distintas partes del sistema.
Algunas rutas de la aplicación permitían a usuarios acceder a datos que no deberían haber podido consultar. Estas rutas debían identificarse y cerrarse.
En algunos casos, la forma en que los datos se modelaban o presentaban no coincidía con cómo la aplicación realmente los utilizaba.
Investigo el sistema desde el síntoma hasta la causa.
Cuando se reportaba un problema, seguía el comportamiento a través de las distintas capas involucradas en lugar de asumir que el primer problema visible era la causa real.
La investigación combinaba comportamiento de la aplicación, información de base de datos, contexto de negocio y relaciones entre las áreas afectadas.
Reproducir el comportamiento reportado y comprender exactamente qué sucede en lugar de depender solo del reporte original.
Revisar los datos subyacentes, su origen y las relaciones involucradas para determinar si el problema inicia antes de llegar a la aplicación.
Seguir la lógica de aplicación e identificar dónde el comportamiento real difiere de lo que se espera que haga el sistema.
Cuando es necesario, conversar sobre el comportamiento con las personas involucradas en el proceso para entender qué debe representar realmente el sistema.
Buscar otras pantallas, procesos, consultas o flujos que puedan verse afectados por la misma causa subyacente.
Una vez comprendida la causa, determinar el cambio efectivo más pequeño y si otras áreas afectadas deben corregirse al mismo tiempo.
Una vez clara la causa, el objetivo era cambiar el sistema sin crear un problema distinto.
Después de identificar la causa raíz, evalué qué áreas estaban afectadas y determiné el alcance apropiado del cambio. El objetivo no era reescribir el sistema, sino corregir el comportamiento preservando las partes que ya funcionaban.
Cuando varios problemas relacionados podían abordarse juntos, los corregía como parte del mismo esfuerzo cuando la capacidad lo permitía. De otro modo, priorizaba el problema más importante y coordinaba o delegaba el trabajo restante.
Aplicar el cambio donde se origina el comportamiento incorrecto en lugar de añadir otra solución temporal alrededor del síntoma.
Revisar funcionalidad y flujos de datos relacionados para entender si el cambio podía afectar otras partes del sistema.
Cuando el mismo problema subyacente afectaba múltiples áreas, abordar los casos relacionados en vez de dejar inconsistencias conocidas.
Evitar cambios innecesarios al comportamiento estable y limitar el alcance a lo requerido para resolver el problema identificado.
Una corrección solo está completa cuando el sistema vuelve a comportarse correctamente.
Después de realizar un cambio, verifiqué que el comportamiento reportado se hubiera corregido y revisé la funcionalidad afectada para asegurar que el cambio no hubiera introducido problemas nuevos.
El objetivo no era solo cerrar incidentes individuales, sino mejorar la confiabilidad del sistema y reducir el número de problemas recurrentes que llegaban al equipo de desarrollo.
El problema original se verificó contra el comportamiento de negocio esperado después de implementar el cambio.
Abordar las causas subyacentes en lugar de síntomas aislados ayudó a reducir el número de incidentes similares reportados.
Comprender las dependencias antes de cambiar el sistema redujo el riesgo de corregir un área y afectar involuntariamente otra.
Cada investigación incrementó la comprensión del comportamiento de la aplicación, las relaciones de datos y las reglas de negocio.
Corregir el problema inmediato importa, pero comprender por qué ocurrió hace que los cambios futuros sean más seguros y predecibles.
Los sistemas heredados rara vez son difíciles porque el código es viejo. Son difíciles porque el sistema ya tiene historia.
Los sistemas existentes contienen decisiones, dependencias, reglas de negocio y suposiciones que pueden no ser visibles desde una sola pieza de código. Cambiarlos de manera segura requiere comprender esa historia antes de decidir qué debe cambiar.
Esta experiencia reforzó algo que aplico más allá de los sistemas heredados: comprender el problema y su contexto es parte del trabajo de ingeniería, no un paso que ocurre antes de él.