No hay límite para lo malo que puede llegar a ser el código
There's No Limit to How Bad Code Can Get
El autor, con experiencia en un código heredado de Amazon, critica las metáforas comunes como 'barco que se hunde' para describir la deuda técnica. Argumenta que el software, a diferencia de un edificio, no tiene un punto de colapso físico: siempre puede empeorar. La empresa puede hundirse antes de que el código alcance un 'suelo' hipotético, y la deuda técnica no tiene quiebra ni reinicio limpio. El artículo insta a reconocer que no hay un límite natural que obligue a abordar la deuda técnica, por lo que mantener la calidad del código requiere un esfuerzo constante.
El software está en el dominio de lo abstracto. No es como un edificio o un puente, que están en el ámbito físico donde puedes ver y sentir la naturaleza de la cosa. Si sigues añadiendo pisos y habitaciones a un edificio para siempre, se derrumbará. El software no enfrenta tal restricción. El código siempre puede empeorar. Siempre puede haber una nueva capa de indirección o una reducción en el rendimiento.
- ChrisMarshallNY
Uno de mis primeros trabajos fue como ingeniero de mantenimiento en una base de código de más de 100KLoC de FORTRAN IV de finales de los 70.
Sin comentarios.
Sin subrutinas (lo que ahora llamamos "funciones").
Ningún nombre de variable de más de 4 caracteres.
Divertido. La herramienta de depuración más efectiva era una tabla ouija. Me convirtió en un experto en adivinar.
Fue la razón principal por la que hoy soy tan maniático con la calidad del código. Nunca quiero someter a nadie más a eso.
Por cierto: con los LLM de hoy, realmente no hay excusa para el código mal documentado o mal formateado. Puedes escribir mil líneas de espagueti de grado comercial y decirle al LLM que lo formatee y documente.
- lukasgelbmann
Artículo perspicaz. El autor hace grandes observaciones sobre la dinámica de la deuda técnica en las organizaciones.
Creo que un barco que se hunde es una metáfora bastante buena, aunque un barco hundido es un resultado horrible y terrible.
En la metáfora, una base de código está hundida cuando ya no es viable seguir usándola. La organización deja de trabajar en ella y ya no la ejecuta. En ese punto, el código es completamente inútil para el negocio, como un barco en el fondo del océano. Es cierto que teóricamente se podría imaginar que el código empeora, pero en realidad simplemente se quedará ahí pudriéndose.[0] El negocio podría intentar una reescritura o simplemente discontinuar el producto.
Es posible, pero no garantizado, que un negocio se hunda con una de sus bases de código. Esto también puede pasar con un barco, si el negocio depende mucho de él.
- blevinstein
> La deuda técnica no tiene bancarrota, ni reinicio limpio
Definitivamente existe una opción de bancarrota para la deuda técnica.
Puedes dejar de usar un código o tecnología en particular, por ejemplo reemplazándolo (con código nuevo, o una solución de terceros/proveedor), o re-arquitecturando un sistema o proceso de negocio para que la función del código ya no sea necesaria.
Esto es exactamente lo que significa la metáfora de la deuda técnica. Los sistemas de corta vida pueden acumular mucha deuda técnica sin tanta preocupación, porque planeas declarar bancarrota (deprecar y desmantelar) el código pronto de todos modos; los sistemas de larga vida deben planear pagar su deuda técnica en el plan de pagos habitual.
- socalgal2
2 cosas
1. En mi experiencia, un LLM puede arreglar esto. Un LLM, especialmente los más modernos, tiene mucha más memoria a corto plazo que la mayoría de los humanos (o al menos mucha más que yo). Pueden profundizar en este tipo de código y encontrar todos los casos límite, escribir pruebas, sugerir varios caminos para mejorar las cosas y luego ejecutar esos caminos. Si se lo pides, felizmente configurarán sistemas de desarrollo, sistemas de staging, lo que sea necesario para que la transición sea segura. Al menos esa es mi experiencia. Pueden profundizar mucho más de lo que yo jamás haría.
2. Aparte de, o quizás separado del arreglo con LLM, este patrón de deuda técnica creo que es casi inevitable, al menos con humanos. En un mundo perfecto, cada humano y cada revisor sabe exactamente qué arquitectura escribir y qué pruebas para transmitir todas las reglas y suposiciones, porque no importa qué, la gente se va a ir. Nunca he visto esa base de código. Así que las reglas y suposiciones están, en el mejor de los casos, medio escritas, quizás en algunos comentarios o documentos, comentarios o documentos que la próxima persona que edite esa parte de la base de código puede o no ver. Y así sigue.
Trabajo en una base de código que corre en Windows, Mac, Linux, Android, iOS. Esos sistemas operativos cambian con el tiempo, sus requisitos cambian, sus APIs cambian, el mundo cambia y se necesitan nuevas APIs para cosas nuevas que la gente hace, y nuestras elecciones originales para soluciones multiplataforma ya no encajan perfectamente. Necesitamos seguir avanzando y publicando, y no podemos simplemente detener el mundo y re-arquitecturar. Además, como dice el autor del artículo, ni siquiera...
- cebert
Si has trabajado con contratistas offshore de bajo costo, sabes que esto es cierto...