Heredaste un producto: la auditoría de código antes de seguir

Heredar un producto significa asumir la responsabilidad de un software creado por otra persona, ya sea por un desarrollador que se fue, una agencia que terminó el contrato, o un código que pasó por varias manos y nadie sabe más o menos cómo funciona. Computar un producto funciona - o solo funciona parcialmente - y no hay forma confiable de saber qué tan saludable está por dentro.

Una auditoría de código es la respuesta a esta pregunta antes de gastar el primer dólar en cambios: alguien lee lo que hay, lo compara con lo que tu negocio necesita y te proporciona un informe escrito sobre qué conservar, qué reparar y qué reescribir. Este es el punto de partida de casi todo lo que hace mi trabajo y es por eso que la decisión tomada sin una auditoría casi siempre es la peor.

TL;DR Antes de solicitar nuevas funcionalidades en un producto heredado, primero es necesario conocer qué tienes. Esa información se obtiene a través de una auditoría del código y la arquitectura, que da lugar a un informe, no a una conversación. La auditoría no se limita al código, también considera quién es el dueño de las cuentas, cuánto cuesta mantener el producto y los riesgos que ya existen.

La recomendación más común es reescribir todo desde cero, pero eso suele ser el más costoso. En general, siempre hay un núcleo que se conserva y tres cosas específicas que necesitan ser reparadas. Hacerse cargo de un producto heredado se puede presentar en varias formas comunes: el desarrollador se fue, trabajaba solo y dejó todo en la cabeza sin documentación; la agencia se terminó y desapareció, entregando una versión que funcionaba en el momento de la entrega y luego dejó sin responder; o el código ha estado desordenado durante años, con pequeñas modificaciones que rompen cosas viejas y nadie se atreve a tocar ciertas partes.

Cuando compras un producto, compras una empresa o una aplicación con software incluido, sin que nadie de tu equipo lo haya revisado nunca. El costo mensual de mantenerlo, lo que pasa si falla un martes a las nueves de la noche y si los datos de los usuarios están donde deberían estar son preguntas fundamentales. No saber estas respuestas no es culpa de tu gestión; es el estado normal de un producto tras cambiar de manos sin un traspaso adecuado.

Lo peor es seguir construyendo encima sin resolver estos problemas. Por eso, la programación no es lo primero que debes hacer. La reacción natural es comenzar a arreglar errores, agregar nuevas funciones o publicar nuevas versiones. Es razonable, pero casi siempre falla por tres razones: no sabes lo que estás tocando, no sabes qué está en riesgo ahora mismo y no sabes si vale la pena seguir adelante.

Una auditoría es mucho menos costosa que comenzar a desarrollar a ciegas desde el principio. Por lo tanto, vale la pena invertir en una auditoría antes de empezar cualquier otro proceso. El resto de la implementación, decisiones de diseño y lo que solo se ve en producción está en mi blog: lee el artículo completo en ramonchancay.me.