Gestionar un millón de líneas de código y la paradoja de Jevons
Albert Cervera i Areny
Hola,
hace mucho que no escribo y hoy lo hago para explicarte el foco más importante que hemos tenido este 2024 que termina.
Nuestro objetivo es que todas las empresas puedan tener un software adaptado a sus necesidades.
Porque no nos engañemos, todas las empresas querrían tener el software a medida, pero es una cuestión de costes que puedan permitírselo o no, o hasta qué nivel pueden llegar en la personalización.
Un factor vital para que esto sea económicamente posible es ser capaz de mantener el software a lo largo del tiempo.
Y esto implica intentar tener el mínimo de incidencias posibles y gestionar rápida y eficientemente las que surjan.
El número de incidencias se puede pensar como número de líneas código multiplicado por el número de incidencias por cada línea de código.
Y por tanto, mejorará siempre que reduzcas uno de estos dos parámetros.
Reducimos el número de líneas
Por ejemplo, hace unos meses te contaba que hemos creado Voyager una nueva tecnología para desarrollar páginas web (como tiendas online o extranets para clientes) integradas en Tryton que reducía a la mitad el tiempo de desarrollo comparado con la tecnología anterior .
Pues bien, ahora que ya hemos desarrollado algunos proyectos con Voyager vemos que también hemos reducido el número de líneas de código a la mitad.
Además, existen otras iniciativas que estamos tomando para tratar de ir reduciendo el número de líneas de código.
Globalmente, entre la parte más estándar del software y todas las personalizaciones de todos los clientes, en NaN-tic respondemos de unas 800.000 líneas de código actualmente.
Pero Albert! Aquí me hablas de 800.000 líneas de código y que hacéis cosas para reducirlas. ¡Ya me has colado de nuevo un título al más puro estilo ciberanzuelo! (la versión castellana de lo que en inglés conocen como clicbait).
Bueno... sí... y no.
Aunque trabajamos para tratar de simplificar y reducir el número de líneas de código, lo que ocurre es que a medida que haces una tecnología más eficiente, la demanda crece por encima del nivel original.
Esta paradoja se llama la Paradoja de Jevons.
Siguiendo con el ejemplo de Voyager, nos hemos encontrado que desde que la empezamos a desarrollarla (hace algo más de seis meses), ya hemos prácticamente terminado una tienda online, tenemos otra a más del 50% y hemos desarrollado una aplicación para la gestión de almacenes con el móvil. Además, tenemos en cola al menos un par de proyectos más en los que haremos uso.
Es inevitable que nos preparemos pensando que el número de líneas de código que deberemos gestionar tenderá a acercarse al millón, aunque sigamos los esfuerzos por reducirlas.
Reducimos el número de incidencias por línea de código
Algunos artículos apuntan a que aproximadamente 15 bugs por cada 1000 líneas de código llegan a cliente. A menudo podrás ver la unidad de medida KLOC, del inglés Kilo Lines of Code = Miles de Líneas de Código.
Otras referencias, por ejemplo, preguntando a ChatGPT, dice que en proyectos maduros el número de incidencias puede bajar a entre 0,5 y 3 por cada kloc.
Así que no es sencillo conocer cuál es el número de incidencias que se pueden "esperar" por cada línea de código.
Sin ir más lejos, la forma de escribir código en Tryton, genera aproximadamente un 20% menos de líneas de código que el estándar de Python (ver black) .
En consecuencia cabría esperar que el número de incidencias por cada 1000 líneas fuera superior en Tryton.
Así que en primer lugar tenemos esta cuestión del estilo: hablar de líneas de código sería cómo hablar del número de líneas en un texto sin habernos puesto de acuerdo antes en el tamaño de papel, la tipografía ni el tamaño de la letra.
Este 2024 en NaN-tic hemos creado 1259 incidencias. Son números aproximados, por ejemplo, dentro de estos datos hay algunas incidencias que han sido duplicadas. Otras puede que no se hayan introducido por cuestiones de urgencia.
1259 / 800 kloc = 1,6 incidencias por cada 1000 líneas de código
Si lo comparamos con el pasado año (1434 incidencias) hemos reducido un 12% el número de incidencias totales generadas.
Está bien pero no es espectacular.
Aún así hay que tener en cuenta algunas cosas que lo hacen algo más interesante:
- Hemos incrementado el número de clientes y el número de líneas de código nuevo que mantenemos respecto al año anterior.
- Este 2024 hemos realizado un 28% más de cambios de versiones que el año pasado. Tal y como he explicado en algún otro correo, estamos incrementando el ritmo de paso a nuevas versiones del programa. Estamos trabajando mucho para reducir el número de incidencias que se producen en estos cambios, que son, no nos engañemos, fuente de errores.
- Una parte nada despreciable del esfuerzo que invertimos en reducir el número de incidencias son por mejoras a largo plazo. Por ejemplo, las mejoras que hemos realizado en el sistema de tests, y el incremento de la cobertura de tests que estamos llevando a cabo no es algo que tenga efectos inmediatos.
Nos tomamos muy seriamente reducir al máximo las incidencias en el software porque mantenemos nuestro objetivo de poder ofrecer un SLA (Acuerdo de Nivel de Servicio) para los clientes con las máximas exigencias y no lo haremos de cualquier manera.
Escribir código y entregar software más rápido es uno de nuestros objetivos principales como te contaré en próximos correos pero sabemos que sólo es un buen objetivo si simultáneamente reducimos el número de errores por línea de código.
Más que líneas de código
Aquí sólo hemos hablado de líneas de código de las que somos responsables más directamente pero hay mucha más tecnología de la que respondemos, como el sistema operativo, docker, proxis, envíos de correos electrónicos, sistemas de autenticación o el servidor de bases de datos PostgreSQL.
Todos ellos requieren decisiones que hemos elegido para que nos faciliten la gestión, den estabilidad y faciliten el mantenimiento de la infraestructura: minimicen el número de incidencias.
Como el año... ya termino.
¡Sólo quiero desearte una muy buena entrada de año!
¡Salud!