¿Debería reescribir el código heredado en C#? Una mirada más profunda a la opinión de Derek Comartin

El principio de "nunca reescribir el código"

Derek comienza reconociendo el viejo consejo que se suele dar en el desarrollo de software: Nunca reescribas código desde cero. Este sentimiento proviene de una famosa entrada de blog de Joel Spolsky titulada "Cosas que nunca deberías hacer", que advierte enérgicamente contra la reescritura de sistemas heredados.

En el minuto 0:32, Derek señala la idea más importante del artículo de Spolsky:

"Cometieron el peor error estratégico que puede cometer una empresa de software: Decidieron reescribir el código desde cero."

Derek explica que lo más importante es lo siguiente: cuando se empieza de cero, no hay razón para creer que se hará necesariamente un trabajo mejor que el que se hizo la primera vez. Especialmente en sistemas grandes y complejos, es fácil subestimar el valor oculto de la implementación actual.

La ilusión de la simplicidad

En el minuto 1:07, Derek reflexiona sobre sus primeros días como desarrollador junior. Como muchos otros, a menudo quería reescribir grandes partes de un sistema simplemente porque pensaba que el código era malo. Pero más tarde se dio cuenta de que esta creencia a menudo se debía a que no entendía el código, no a que el código en sí fuera intrínsecamente deficiente.

Comparte una verdad relatable:

"Empezar algo desde cero es más fácil que tener que profundizar en el código base, toda su complejidad, los casos extremos... es realmente difícil"

En esencia, lo que parece un "incendio de neumáticos" podría ser simplemente lógica mal entendida envuelta en años de evolución y parches. Los desarrolladores suelen confundir la falta de familiaridad con un mal diseño.

Cuándo puede estar justificada la reescritura

Aun así, Derek no dice que las reescrituras sean siempre malas. Alrededor del minuto 1:44, empieza a introducir matices. Para los equipos que llevan años trabajando con la misma base de código, que comprenden toda la complejidad del dominio y las limitaciones del sistema, la reescritura puede ser una opción válida.

"Si llevas mucho tiempo en un sistema... y ahí es donde entran los matices. Se puede decir que sí, que esto es una lata y nos está frenando. Quizá sea conveniente hacer una reescritura "

"Peor es mejor" y la regla del 80/20

Derek introduce el concepto de "cuanto peor, mejor" en el minuto 2:01, relacionándolo con el Principio de Pareto (regla 80/20). Sostiene que, a menudo, el 80% del valor del sistema procede de solo el 20% del código base. Por tanto, a la hora de reescribir, el objetivo no debe ser replicarlo todo, sino centrarse en el núcleo que realmente aporta valor.

"Hay un punto en el que menos funcionalidad -peor- es la opción preferible"

Explica que la sencillez y el sentido práctico suelen tener más peso que la exhaustividad. Un sistema limitado pero utilizable y mantenible puede ser más útil que una plataforma heredada extensa pero difícil de mantener.

Evaluación de costes y beneficios

En el minuto 2:47, Derek sugiere que la decisión final a menudo se reduce al análisis coste-beneficio. Nunca está justificado reescribir por reescribir. Pero si el coste de mantener el código antiguo o estar limitado por la tecnología antigua es mayor que reconstruir, entonces la ecuación puede inclinarse a favor de una reescritura.

Hace referencia a situaciones en las que tu ventaja competitiva se ve obstaculizada porque estás atascado en plataformas o herramientas obsoletas. En estos casos, la propia brecha tecnológica se convierte en una razón válida para reconstruir.

Una lección de Greg Young

Derek menciona un brillante post de Greg Young en el minuto 3:12, en el que se reescribió un prototipo que accidentalmente llegó a producción. La reescritura duró 9 meses. ¿Cuál es el resultado?

"Después de nueve meses de hermoso trabajo de arquitectura y código, ganábamos aproximadamente 10.000 dólares más al mes"

Greg llegó a la conclusión de que les habría ido mejor construyendo 30 prototipos nuevos para probar nuevas estrategias que invirtiendo a fondo en reconstruir aquel. A Derek le encanta esta conclusión porque desafía la suposición de que la perfección técnica es siempre el objetivo.

A veces, el software que es "suficientemente bueno" gana, especialmente cuando ya está aportando valor empresarial.

El sesgo "viejo frente a nuevo"

En el minuto 4:20, Derek aborda la idea común de que lo viejo es malo y lo nuevo es bueno. Ofrece un ejemplo personal: él se integra con dos servicios de terceros que sirven para lo mismo. Una de ellas utiliza JSON moderno y probablemente esté construida en Python. El otro, sorprendentemente, devuelve XML y probablemente se construyó en ColdFusion en la década de 1990.

"Ambos son equivalentes. Son estables. Aportan el mismo valor para mí y para mis clientes "

Esto pone de manifiesto que lo nuevo no siempre es mejor. La estabilidad, la fiabilidad y la utilidad a menudo importan mucho más que la pila tecnológica.

Experiencia personal de Derek en la reescritura

Finalmente, Derek comparte su propia historia en el minuto 5:31. Participó en una reescritura a gran escala después de pasar más de seis años en el dominio del sistema original. La reescritura duró unos 14 meses, debido principalmente a una laguna tecnológica que limitaba la capacidad del sistema para integrarse con herramientas modernas de comercio electrónico y servicios en línea.

"Realmente teníamos que reconstruir algo nuevo para este fin"

No se trataba simplemente de un caso de "código defectuoso": el sistema era fundamentalmente incapaz de evolucionar, por lo que la reconstrucción era el único camino viable.

Reflexiones finales

Al final del vídeo, alrededor del minuto 6:11, Derek refuerza que la respuesta no es simplemente "sí" o "no"

"No creo que la respuesta clara sea no. Creo que hay que ser prudente a la hora de tomar esa decisión porque el contexto importa, y hay muchos matices"

Puede ser necesario reescribir código C# heredado, pero sólo cuando el contexto, el conocimiento del dominio, la entrega de valor y las limitaciones técnicas apoyen esa decisión.

Conclusión

El vídeo de Derek Comartin es una visión equilibrada y basada en la experiencia de uno de los temas más debatidos del desarrollo de software: ¿Hay que reescribir el código heredado? Sus consejos no son dogmáticos, sino reflexivos, fundamentados y llenos de ideas personales.

Al reflexionar sobre las lecciones históricas, las historias del mundo real y la trampa de "lo nuevo es mejor", Derek ayuda a los espectadores a desarrollar un marco maduro para tomar una de las decisiones más importantes en la arquitectura de software.

Si te enfrentas a una elección similar en tu propio proyecto de C#, vuelve a ver el vídeo de Derek y sopesa bien el contexto. A veces, el código heredado no es el enemigo, simplemente se malinterpreta.

Puedes ver más vídeos de Derek en YouTube Channel. Visite CodeOpinion.com para ver más contenidos de Derek.