Software de sangre fría
- En 2004, mientras el autor, estudiante de informática, asistía a una clase de historia natural, el profesor mostró una cría de tortuga pintada congelada.
- Esta tortuga es una de las pocas especies que pueden sobrevivir en estado de congelación, ya que es un animal de sangre fría capaz de regular su metabolismo a bajas temperaturas.
- Al observar durante la clase cómo la tortuga se movía lentamente y recuperaba la vida, profundizó su comprensión de los animales de sangre fría.
La dicotomía de los proyectos de software
- Los proyectos de software también pueden dividirse en proyectos de sangre caliente y de sangre fría.
- Los proyectos de sangre caliente requieren actividad continua, y cuando esa actividad se detiene, aparecen problemas.
- Los proyectos de sangre fría pueden retomar el trabajo incluso después de periodos de inactividad y continuar de inmediato desde donde se quedaron.
El software de sangre fría del blog
- El software que impulsa el blog del autor es software de sangre fría.
- Este proyecto, iniciado hace 12 años, es simple, no depende de servicios externos y todas las dependencias están incluidas en el repositorio del proyecto.
- Salvo algunas pequeñas mejoras, ha funcionado bien sin cambios y se espera que siga funcionando durante los próximos 12 años.
Opinión de GN⁺
- El concepto de software de sangre fría influye de forma importante en la sostenibilidad y mantenibilidad de un proyecto.
- Este texto ofrece una perspectiva sobre cómo la elección del stack tecnológico afecta la longevidad de un proyecto.
- La experiencia del autor deja una lección para los desarrolladores de software sobre cómo construir sistemas estables a largo plazo.
1 comentarios
Opiniones de Hacker News
En el ecosistema de Node y JavaScript existe el framework web Express. Su rama principal actual, la versión 4.x.x, tiene más de 10 años y se descarga más de 17 millones de veces por semana. Aunque le faltan algunas funciones y no ofrece el mejor rendimiento, muchos desarrolladores lo prefieren porque permite desarrollar de forma rápida y estable, y hacer planes a largo plazo sin preocuparse por cambios en la API o falta de parches de seguridad. Go ofrece una estabilidad aún mejor gracias a su amplia biblioteca estándar y a su promesa de compatibilidad, lo que permite ejecutar programas de más de 10 años.
Si un software funciona bien sin actualizaciones, normalmente es porque fue hecho correctamente desde el principio. El software de uso personal es relativamente más fácil, porque los gustos no cambian tanto. Pero al escribir software que usan otras personas, los requisitos pueden ser distintos y pueden surgir problemas inesperados. Por ejemplo, podría fallar al procesar archivos grandes, y corregirlo podría requerir reescribir la mitad del software. Este es el principal contraargumento a la idea de que el software que no cambia con frecuencia necesariamente es mejor.
Python es un mal ejemplo debido a sus cambios continuos que rompen compatibilidad. En cambio, Go o Java hacen que incluso código de hace 10 años funcione bien con herramientas modernas. Perl es un ejemplo todavía mejor: incluso código de hace 30 años sigue funcionando bien.
Trabajo con mainframes de IBM (
z/OS). IBM es, por mucho, la mejor en mantener compatibilidad hacia atrás. Microsoft (Windows) va en segundo lugar, y el ABI de Linux (kernel) en tercero. En la mayoría de los demás sistemas, este es un problema común en el OSS, que normalmente no quiere invertir tiempo en mantener compatibilidad.Las dependencias pueden hacer que una app sea de “sangre caliente”, pero Docker o la contenerización pueden resolver parcialmente estos problemas. Cuando elijo bibliotecas para un proyecto, investigo lo suficiente para decidir si son bibliotecas de “sangre fría”.
Muchos ingenieros, al buscar una biblioteca en GitHub, revisan la fecha del último commit. Suponen que mientras más reciente sea el commit, mejor mantenido está el proyecto. Pero encontrar un proyecto archivado, estable por mucho tiempo y sin bugs, es como hallar una joya escondida en una tienda de segunda mano.
Doy mantenimiento a mi proyecto personal paralelo. Lo empecé hace 12 o 13 años y lo reescribí con PHP, Laravel y Symfony. Ha sido muy valioso para aprender cómo mantener un proyecto a largo plazo. Por ejemplo, busco oportunidades para simplificarlo: pasar de Vagrant a Docker, y de Vue + Axios + Webpack a Htmx. Recientemente lo actualicé a PHP 8.2 y Symfony 7, e integré funciones basadas en ChatGPT.
Estoy harto de que las apps móviles de los últimos años requieran horas de trabajo en parches. El autor describe su generador de sitios estáticos como de “sangre fría”; corre sobre Python 2, pero cada vez es más difícil instalar Python 2.
Un SDK que escribí en 1994-95 siguió usándose hasta que dejé la empresa en 2017. Estaba escrito en ANSI C, y algo que escribí en PHP (5) también funciona bien en PHP 8.2. Pero estas cosas son aburridas y tienen poco factor de moda.
Además de lo mencionado en el artículo, también es importante tener un modelo de amenazas intrínsecamente seguro. Por ejemplo, un sitio web completo es inherentemente de “sangre caliente” porque debe responder de forma constante a atacantes, bots de spam, etc. En cambio, una página estática como Tiddlywiki es mucho mejor porque no necesita publicarse en la web y el navegador es una plataforma muy estable.