Heredar un producto es quedarte a cargo de un software que construyó otra persona: el desarrollador se fue, la agencia terminó el contrato, o el código pasó por tantas manos que ya nadie sabe con certeza qué hace. Tienes un producto que funciona —o que funciona a medias— y ninguna forma confiable de saber qué tan sano está por dentro. Una auditoría de código es la respuesta a esa pregunta antes de gastar el primer dólar en cambios: alguien lee lo que hay, lo contrasta con lo que tu negocio necesita y te entrega un veredicto escrito sobre qué conservar, qué reparar y qué reescribir. Escribo esto porque es la mitad de mi trabajo y porque la decisión que se toma sin auditoría casi siempre es la cara.
TL;DR
- Antes de pedir funcionalidades nuevas sobre un producto heredado, necesitas saber qué tienes. Eso se responde con una auditoría del código y la arquitectura que termina en un documento, no en una conversación.
- La auditoría no revisa solo el código: revisa quién es dueño de las cuentas, qué tan caro es sostener el producto y qué riesgos ya están activos. Varios de los hallazgos más urgentes nunca son técnicos.
- "Reescribir todo desde cero" es la recomendación más frecuente de quien llega nuevo y la más cara para ti. Casi siempre hay un núcleo que se conserva y tres cosas concretas que se reparan.
Qué significa heredar un producto
Los casos llegan casi siempre en una de estas formas:
- El desarrollador se fue. Trabajaba solo, tenía todo en la cabeza y dejó un repositorio sin documentación. A veces sigue respondiendo mensajes por un tiempo; a veces no.
- La agencia terminó y desapareció. Entregó una versión que funcionaba el día de la entrega. Seis meses después nadie contesta y el contrato no dice qué pasa con las cuentas.
- El código se desordenó con los años. Nadie se fue: el producto acumuló cambios pequeños y urgentes hasta que cada modificación nueva rompe algo viejo y ya nadie se atreve a tocar ciertas partes.
- Compraste el producto. Adquiriste una empresa o una aplicación y el software vino incluido, sin que nadie de tu lado lo haya revisado nunca.
En los cuatro el punto de partida es el mismo: existe un producto que tus usuarios usan y tu equipo no puede responder preguntas básicas sobre él. Cuánto cuesta mantenerlo al mes. Qué pasa si se cae un martes a las nueve de la noche. Si los datos de tus usuarios están donde deberían. Cuánto trabajo real hay detrás de la funcionalidad que quieres agregar el mes que viene.
No saber esas respuestas no es una falla de gestión. Es el estado normal de un producto que cambió de manos sin traspaso. Lo que sí es una falla es seguir construyendo encima sin resolverlo.
Por qué lo primero no es programar
La reacción natural cuando heredas un producto es pedir lo que te hace falta: arreglar el error que reportan los usuarios, agregar la pantalla que te pidió un cliente, publicar la versión nueva. Es razonable y casi siempre sale mal, por tres motivos.
No sabes lo que estás tocando. En un código que no conoces, un cambio de veinte líneas puede ser de veinte líneas o de tres semanas. Nadie puede cotizarte de verdad sin haber leído lo que hay, y quien te dé un precio sin leerlo lo está adivinando.
No sabes qué está en riesgo ahora mismo. Las cosas que más urgen en un producto heredado rara vez son las que se ven desde afuera. Una llave de acceso publicada en el repositorio, una base de datos sin copias de respaldo o un servicio que dejó de recibir actualizaciones de seguridad no aparecen en la lista de pendientes de nadie, y cualquiera de las tres puede costarte el producto entero.
No sabes si conviene seguir con eso. A veces la respuesta honesta es que el código no vale lo que cuesta mantenerlo, y esa es una decisión de negocio que necesitas tomar con información, no después de haber invertido seis meses en mejorarlo.
Una auditoría cuesta una fracción de lo que cuesta el primer mes de desarrollo a ciegas. Ese es todo el argumento.
Sigue leyendo
Hasta aquí la primera mitad. El recorrido completo — con el resto de la implementación, las decisiones de diseño y lo que solo aparece en producción — está en mi blog:
Lee el artículo completo en ramonchancay.me →
Publicado originalmente en www.ramonchancay.me/es/blog/auditoria-de-codigo-producto-heredado.
Top comments (0)