Gestionar un milió de línies de codi i la paradoxa de Jevons
Resum ràpid
Mantenir un software adaptat al llarg del temps exigeix reduir tant la quantitat de codi com les incidències que genera. L’ús de Voyager ha reduït a la meitat les línies necessàries per desenvolupar webs integrades amb Tryton, però la paradoxa de Jevons fa que una tecnologia més eficient també n’ampliï l’ús. L’article repassa l’evolució de les incidències, la importància dels tests i les decisions d’infraestructura orientades a oferir un servei estable.
Autor
Albert Cervera i Areny
Cofundador de Tryton i NaN·tic
Continguts
Hola,
fa molt que no escric i avui ho faig per explicar-te el focus més important que hem tingut 2024 que s'acaba.
El nostre objectiu és que totes les empreses puguin tenir un software adaptat a les seves necessitats.
Perquè no ens enganyem, totes les empreses voldrien tenir el software a mida, però és una qüestió de costos que s'ho puguin permetre o no o fins a quin nivell poden arribar en la personalització.
Un factor vital perquè això sigui econòmicament possible és ser capaç de mantenir el software al llarg del temps.
I això implica, intentar tenir el mínim d'incidències possibles i gestionar ràpida i eficientment les que sorgeixin.
El número d'incidències es pot pensar com a número de línies codi multiplicat pel número d'incidències per cada línia de codi.
I per tant, millorarà sempre que redueixis un d'aquests dos paràmetres.
Reduïm el número de línies
Per exemple, fa uns mesos t'explicava que hem creat Voyager una nova tecnologia per desenvolupar pàgines web (com botigues online o extranets per clients) integrades a Tryton que reduia a la meitat el temps de desenvolupament comparat amb la tecnologia anterior.
Doncs bé, ara que ja hem desenvolupat alguns projectes amb Voyager veiem que també hem reduït el número de línies de codi a la meitat.
A més, hi ha altres iniciatives que estem prenent per mirar d'anar reduint el número de línies de codi.
Globalment, entre la part més estàndard del software i totes les personalitzacions de tots els clients, a NaN-tic responem d'unes 800.000 línies de codi actualment.
Però Albert! Aquí em parles de 800.000 línies de codi i que feu coses per reduir-les. Ja m'has tornat a colar un títol al més pur estil pescaclics! (la versió catalana del que en anglès coneixen com a clicbait).
Bé... sí... i no.
Encara que treballem per mirar de simplificar i reduir el número de línies de codi, el que passa en tecnologia (i altres àmbits) és que a mesura que fas una tecnologia més eficient, la demanda creix per sobre del nivell original.
Aquesta paradoxa s'anomena la Paradoxa de Jevons.
Seguint amb l'exemple del Voyager, ens hem trobat que des que la vam començar a desenvolupar (fa una mica més de sis mesos), ja hem pràcticament enllestit una botiga online, en tenim una altra a més del 50% i hem desenvolupat una aplicació per la gestió de magatzems per mòbil. A més, tenim en cua almenys un parell de projectes més on en farem ús.
És inevitable que ens preparem pensant que el número de línies de codi que haurem de gestionar tendirà a acostar-se al milió, encara que continuem els esforços per reduir-les.
Reduïm el número d'incidències per línia de codi
Alguns articles apunten que aproximadament 15 bugs per cada 1000 línies de codi arriben a client. Sovint podràs veure la unitat de mesura KLOC, de l'anglès Kilo Lines of Code = Miler de Línies de Codi).
Altres referències, per exemple, preguntant a ChatGPT, diu que en projectes madurs el número d'incidències pot baixar a entre 0,5 i 3 per cada kloc.
Així que no és senzill conèixer quin és el número d'incidències que es poden "esperar" per cada línia de codi.
Sense anar més lluny, la forma d'escriure codi a Tryton, genera aproximadament un 20% menys de línies de codi que l'estàndard de Python (veure black).
Així que es podria esperar que el número d'incidències per cada 1000 línies fos superior a Tryton.
Així que en primer lloc tenim aquesta qüestió de l'estil: parlar de línies de codi seria com parlar del número de línies en un text sense haver-nos posat d'acord abans en la mida de paper, la tipografia ni la mida de la lletra.
Aquest 2024 a NaN-tic hem creat 1259 incidències. Són números aproximats, per exemple, dins d'aquestes dades hi ha algunes incidències que han estat duplicades. Per altra banda, hi pot haver incidències que no s'hagin introduït per qüestions d'urgència.
1259 / 800 kloc = 1,6 incidències per cada 1000 línies de codi
Si ho comparem amb l'any passat (1434 incidències) hem reduït un 12% el número d'incidències totals generades.
Està bé, però no és espectacular.
És clar que cal tenir en compte algunes coses que ho fan una mica més interessant:
- Hem incrementat el número de clients i el número de línies de codi nou que mantenim respecte l'any anterior.
- Aquest 2024 hem fet un 28% més de canvis de versions que l'any passat. Tal com he explicat en algun altre correu estem incrementant el ritme de pas a noves versions del programa. Estem treballant molt per reduir el número d'incidències que es produeixen en aquests canvis, que són, no ens enganyem, font d'errors.
- Una part gens menyspreable de l'esforç que invertim en reduir el número d'incidències són per millores a llarg termini. Per exemple, les millores que hem fet al sistema de tests, i l'increment de la cobertura de tests que estem portant a terme no és quelcom que tingui efectes immediats.
Ens prenem molt seriosament reduir al màxim les incidències en el software perquè mantenim el nostre objectiu de poder oferir un SLA (Acord de Nivell de Servei) pels clients amb les màximes exigències i no ho farem de qualsevol manera.
Escriure codi i entregar software més ràpid és un dels nostres objectius principals com t'explicaré en propers correus però sabem que només és un bon objectiu si simultàniament reduïm el número d'errors per línia de codi.
Més que línies de codi
Aquí només hem parlat de línies de codi de les que som responsables més directament però hi ha molta més tecnologia de la qual responem, com el sistema operatiu, docker, proxis, enviaments de correus electrònics, sistemes d'autenticació o el servidor de bases de dades PostgreSQL.
Tots ells requereixen decisions que hem triat perquè ens faciliten la gestió, donen estabilitat i faciliten el manteniment de la infraestructura: minimitzen el número d'incidències.
Com l'any... ja acabo.
Només vull desitjar-te una molt bona entrada d'any!
Salut!
Preguntes freqüents
Quin és l’objectiu principal en mantenir el software al llarg del temps?
Fer que el software adaptat sigui sostenible econòmicament, reduint tant el nombre d’incidències com el temps i l’esforç necessaris per gestionar-les.
Com ha contribuït Voyager a reduir el codi?
En els projectes desenvolupats fins ara, Voyager ha reduït a la meitat les línies de codi necessàries per crear pàgines web integrades amb Tryton.
Què és la paradoxa de Jevons en aquest context?
Vol dir que, quan una tecnologia esdevé més eficient, la demanda pot créixer per sobre del nivell inicial. Per això, encara que es redueixin les línies per projecte, el volum total de codi a gestionar pot continuar augmentant.
Per què els tests són importants encara que els seus efectes no siguin immediats?
Perquè l’augment de la cobertura i les millores del sistema de tests ajuden a reduir incidències a llarg termini, especialment mentre augmenten els clients, el codi mantingut i el ritme d’actualitzacions.
Articles relacionats
Desenvolupador
Python i Tryton
Python has grown rapidly because it is simple, open source, compatible with other languages, and highly modular. Tryton has been built on Python since its creation in 2008, combining both technologies to provide a robust, adaptable ERP with strong technical capabilities.
Tryton
Tryton, ara encara més equipat
A la Tryton Unconference 2019 es van presentar Shine, Papyrus i Printer, tres eines desenvolupades per ampliar les possibilitats de Tryton. Shine integra el treball amb dades, càlculs, gràfics i informes dins l’entorn de gestió, mentre que Papyrus i Printer automatitzen la inspecció i la incorporació d’informació de factures i albarans.
ERP i Negoci
Servei d'Alta Disponibilitat
El Servei d’Alta Disponibilitat de NaN-tic registra els canvis de l’ERP en temps real i distribueix les còpies entre discos, servidors i centres de dades diferents. Això permet reduir les interrupcions del servei i restaurar la base de dades en un moment concret després d’una caiguda, un error humà o una fallada de maquinari.