Reparación de software: cómo limpiar un sistema antiguo para que vuelva a funcionar

🔍 Paso 1: Auditoría de código: entender qué hay antes de tocar

El primer paso de cualquier proceso de reparación de software es la auditoría: un análisis técnico profundo del sistema existente. No se trata de juzgar si el código es "bueno o malo" sino de entender qué hay, cómo funciona, dónde están los riesgos y qué puede repararse versus qué debe reemplazarse.

Una auditoría técnica bien hecha responde las siguientes preguntas:

• ¿Qué tecnologías usa el sistema y qué tan obsoletas están? ¿Hay versiones que ya no tienen soporte de seguridad?
• ¿Cuáles son los módulos más críticos y cuáles son los más problemáticos?
• ¿Existe documentación del código? ¿Hay comentarios, archivos de especificación, instrucciones de instalación?
• ¿Cuánta deuda técnica acumulada hay? ¿Cuántos parches sobre parches tiene el código?
• ¿La base de datos tiene integridad referencial? ¿Los datos son confiables?
• ¿Hay pruebas automatizadas? ¿Cómo se verifica que el sistema funciona correctamente?

Este diagnóstico toma entre 2 y 5 días dependiendo del tamaño del sistema, y es la base de todo lo que viene después. Sin auditoría, cualquier intervención es cirugía a ciegas.

🧹 Paso 2: Refactorización: limpiar sin romper

La refactorización es el proceso de mejorar el código interno de un sistema sin cambiar su comportamiento externo. Es decir: el sistema sigue haciendo lo mismo, pero por dentro funciona mejor, es más legible, más seguro y más fácil de mantener.

¿Cómo se hace esto en la práctica? Algunas intervenciones típicas en sistemas de Pymes chilenas:

• Eliminar código muerto: funciones que ya nadie usa, módulos desactivados hace años, variables que se asignan pero nunca se leen. El código muerto no es inocente: confunde, ocupa espacio y puede ocultar bugs reales.
• Simplificar lógica duplicada: es común encontrar el mismo proceso escrito de tres formas diferentes en distintas partes del sistema. Consolidarlo reduce errores futuros.
• Separar responsabilidades: en sistemas viejos, es habitual que una sola función haga diez cosas distintas. Separarlas hace el código más fácil de probar y modificar.
• Actualizar dependencias de seguridad: librerías con vulnerabilidades conocidas que nadie ha actualizado porque "total, funciona".

La regla de oro de la refactorización es: nunca hacerla sin pruebas. Cada cambio debe verificarse antes de pasar al siguiente.

💾 Paso 3: Migración de base de datos: los datos son lo más valioso

En sistemas viejos, la base de datos suele ser el componente más crítico y también el más problemático. Los datos acumulados de años tienen un valor enorme: son el historial de clientes, de transacciones, de inventario. Perderlos sería devastador.

Pero esas mismas bases de datos muchas veces tienen problemas estructurales serios:

• Tablas con nombres crípticos que nadie recuerda qué significan.
• Datos duplicados o inconsistentes por falta de validaciones.
• Estructura diseñada para un negocio que era diferente hace diez años y que ya no representa la realidad actual.
• Tecnología obsoleta: MySQL 5.x, SQL Server 2008, Access. Versiones que ya no reciben actualizaciones de seguridad.

La migración de base de datos tiene tres etapas: primero se analiza la estructura actual y se identifica qué datos son válidos y cuáles no. Luego se diseña la nueva estructura, optimizada para el negocio actual. Finalmente se migran los datos, con validaciones que garantizan que nada se pierde ni se corrompe en el proceso.

Este es el paso más delicado y el que más planificación requiere. Hacerlo mal puede significar pérdida de datos. Hacerlo bien deja al sistema con una base sólida para los próximos diez años.

📄 Paso 4: Documentación: que el próximo que llegue no empiece de cero

Uno de los problemas más comunes en sistemas viejos es la ausencia total de documentación. El programador original se fue, o lo desarrolló de memoria sin escribir nada. Resultado: nadie sabe bien qué hace cada parte del sistema, y cualquier cambio tiene que hacerse con mucho cuidado porque las consecuencias son impredecibles.

La documentación que debe generarse después de una reparación incluye:

• Manual técnico: arquitectura del sistema, descripción de módulos, instrucciones de instalación y configuración.
• Documentación de la base de datos: qué contiene cada tabla, qué significa cada campo, cuáles son las relaciones entre tablas.
• Manual de usuario: cómo usar cada función del sistema, qué hace cada botón, cómo resolver los problemas más comunes.
• Registro de cambios: qué se modificó, cuándo y por qué. Indispensable para que el próximo desarrollador que llegue entienda la historia del sistema.

✅ Paso 5: Testing: verificar que todo funciona antes de volver a producción

Antes de devolver el sistema reparado al uso diario, debe verificarse que funciona correctamente. El testing en un sistema heredado tiene dos dimensiones:

• Pruebas de regresión: verificar que todo lo que funcionaba antes sigue funcionando después de los cambios. Parece obvio, pero es el error más común: arreglar algo y romper otra cosa sin darse cuenta.
• Pruebas de los módulos reparados: validar que los problemas específicos que se identificaron en la auditoría están efectivamente resueltos.

Idealmente, este testing se hace en un entorno de pruebas separado del sistema en producción, para que si algo falla no afecte la operación del negocio.

⚖️ ¿Cuándo conviene reparar y cuándo reemplazar?

La reparación no siempre es la respuesta correcta. Hay situaciones donde el sistema está tan deteriorado que repararlo costaría más que construir uno nuevo. Estas son las señales que indican que el reemplazo es la mejor opción:

• El costo estimado de reparación supera el 70% del costo de construir el sistema desde cero.
• La tecnología base del sistema ya no existe o no tiene soporte: no hay forma de actualizarla sin reescribir todo.
• Los requerimientos del negocio cambiaron tanto que el sistema actual ya no representa cómo funciona la empresa hoy.
• La base de datos tiene corrupción de datos grave que no puede resolverse sin pérdida de información.

En cambio, la reparación tiene sentido cuando el sistema tiene una base estructural sólida, cuando los datos son valiosos y están en buen estado, y cuando los problemas son de deuda técnica acumulada más que de diseño incorrecto desde el origen. En esos casos, reparar es más rápido, más barato y menos disruptivo para el negocio que reemplazar.