Una empresa ens truca amb una petició clara: «necessitem afegir una nova secció a l'aplicació, quant trigaríeu?». Sobre el paper, dues setmanes de feina. En obrir el codi, dues setmanes es converteixen en dos mesos. No perquè la nova secció sigui difícil, sinó perquè el terreny on s'ha de recolzar està molt pitjor del que ningú s'imaginava.
Aquesta situació es repeteix cada cop més amb la irrupció de la IA. El producte funciona, els usuaris l'utilitzen cada dia i, per fora, tot va bé. Per dins, en canvi, cada canvi costa una mica més que l'anterior. És aquí on té sentit parar i mirar de debò què hi ha a sota.
Què és una auditoria tècnica (i què no és)
Una auditoria tècnica és una revisió a fons de l'estat real d'un producte de programari: com està construït, sobre què es recolza, quines parts són sòlides i quines estan a punt de donar problemes. No és una opinió sobre si el codi és «bonic», és un diagnòstic sobre si aguanta el que vols construir a sobre.
El resultat no és una llista de queixes. És un mapa: què està bé, què cal vigilar, què cal arreglar abans de continuar i, sobretot, quin risc té cada decisió que prenguis a partir d'ara.
Què s'analitza
Cada producte és diferent, però hi ha un conjunt d'àrees que gairebé sempre expliquen la veritat sobre l'estat d'un projecte. Es revisen les dependències (les llibreries externes de què depèn el programari), l'arquitectura (com estan organitzades les peces i si aquesta organització aguanta el creixement), la base de dades, la seguretat, la cobertura de tests i la documentació que existeix, o que falta.
Cap d'aquestes àrees és un detall menor. Són, precisament, les que determinen si afegir el següent costarà dues setmanes o dos mesos.
Les sorpreses que apareixen gairebé sempre
Hi ha troballes que es repeteixen projecte rere projecte, sense importar el sector ni la mida de l'empresa:
Deute tècnic acumulat. Dreceres que en el seu moment tenien sentit per arribar a temps, però que ningú va tornar a tocar. Cadascuna, per separat, és inofensiva. Juntes, converteixen qualsevol canvi en una operació delicada.
Dependències obsoletes. Llibreries que fa anys que no s'actualitzen, de vegades amb vulnerabilitats conegudes, de vegades simplement abandonades per qui les mantenia. El dia que necessites actualitzar-ne una, descobreixes que n'arrossega deu més.
Codi que ningú sap què fa. Cada cop més apareix codi generat amb IA que es va acceptar perquè «funcionava», però que ningú va arribar a entendre del tot: blocs enormes, repetitius i sense una lògica clara al darrere. Mentre tot va bé no molesta; el problema arriba el dia que cal tocar-lo i descobreixes que no hi ha ningú (ni persona ni document) que pugui explicar per què està fet així.
Arquitectura que no escala. Decisions que funcionaven perfectament amb cent usuaris i comencen a cruixir amb deu mil. No estaven malament: estaven pensades per a un altre moment.
Manca de documentació. El coneixement del projecte viu al cap d'una persona que potser ja no hi és. Sense documentació, cada incorporació a l'equip triga setmanes a entendre una cosa que hauria d'estar escrita.
Per què fer-la abans de continuar construint
La temptació, quan un producte ja funciona, és continuar afegint coses a sobre. Més funcionalitats, més pantalles, més integracions. El problema és que cada capa nova es recolza en l'anterior, i si la base no està sana, l'únic que fas és construir més amunt sobre una cosa que ja tremolava.
Fer una auditoria abans d'aquest pas següent et dóna una cosa que normalment no es té: informació per decidir. De vegades el resultat és «tot bé, endavant». Altres vegades és «arregla això primer, t'estalviarà mesos». En tots dos casos, deixes d'avançar a cegues.
El problema no sempre és afegir; de vegades és saber
És fàcil pensar que avançar significa sempre construir més. Però hi ha moments en què el pas més rendible no és afegir ni una sola línia de codi, sinó entendre amb precisió en quin estat està el que ja tens.
Saber on ets no frena el projecte: és el que et permet avançar amb la seguretat que no s'enfonsarà tot en el pitjor moment.
A Liquid fem aquest tipus d'auditories sobre productes que no hem construït nosaltres. No per reescriure-ho tot, sinó per donar-te un diagnòstic honest i un pla clar de què fer a continuació.
