Una refactorització urgent rarament comença amb una decisió elegant. Sol aparèixer quan cada canvi petit triga massa, una part del sistema es trenca en tocar-ne una altra, el rendiment cau, l’equip evita certes zones del codi o el negoci comença a notar el deute tècnic.
La resposta instintiva sol ser “reescrivim-ho tot”. De vegades cal. Moltes vegades és l’opció més perillosa. Una refactorització útil comença per aïllar riscos i recuperar capacitat de canvi, no per perseguir una arquitectura ideal.
Punts clau
- El deute tècnic es torna urgent quan afecta desplegaments, conversió, seguretat o velocitat de negoci.
- Reescriure-ho tot pot duplicar el risc si no hi ha proves, mapa de dependències ni pla de migració.
- La prioritat ha de sortir de l’impacte: què es trenca més, què canvia més i què fa més mal.
- Una refactorització sana combina estabilització, tests, observabilitat i canvis per etapes.
- L’objectiu no és “codi bonic”, sinó reduir cost de canvi i risc operatiu.
Senyals que no convé ignorar
| Senyal | Què sol indicar |
|---|---|
| Cada desplegament fa por | Manca de proves, acoblaments o procés feble |
| Canvis petits triguen dies | Arquitectura rígida o coneixement concentrat |
| Pàgines crítiques carreguen lentes | Deute de frontend, imatges, tercers o servidor |
| Bugs repetits a la mateixa zona | Mòdul fràgil o contracte mal definit |
| Ningú vol tocar cert codi | Risc no documentat i ownership difús |
| Dades comercials inconsistents | Integracions sense validació o regles duplicades |
Deute tècnic com a cost financer
El deute tècnic no és només una incomoditat de desenvolupadors. Té cost financer quan:
- retarda campanyes;
- impedeix provar hipòtesis;
- apuja el cost de manteniment;
- redueix conversió per lentitud o errors;
- bloqueja integracions;
- augmenta dependència d’una persona concreta;
- obliga a refer feina ja pagada.
Auditoria abans de reescriure
Abans de decidir una refactorització gran, faria una auditoria breu:
- Mapa de zones crítiques: plantilles, mòduls, APIs, formularis, checkout, CRM, automatitzacions.
- Historial de canvis: quins arxius o mòduls es toquen més.
- Errors recurrents: bugs, logs, incidències, tickets de suport.
- Performance: Core Web Vitals, pes JS, consultes lentes, tercers.
- Proves existents: unitàries, integració, visuals, smoke tests.
- Dependències: llibreries sense manteniment, plugins, APIs externes.
- Risc comercial: quina part afecta leads, vendes o reputació.
El resultat hauria de ser una llista prioritzada, no un document decoratiu.
Refactoritzar per etapes
Un pla prudent:
| Fase | Objectiu | Exemple |
|---|---|---|
| Estabilitzar | Reduir risc immediat | Tests smoke, backups, logs, feature flags |
| Aïllar | Separar zona crítica | Extreure mòdul de formularis o checkout |
| Simplificar | Eliminar duplicació i contractes ambigus | Unificar validació de dades |
| Substituir | Canviar peça fràgil per una de mantenible | Refer un component o integració |
| Mesurar | Comprovar impacte | Menys bugs, desplegaments més ràpids, millor LCP/INP |
La refactorització més segura sol ser incremental. Si cal reescriure, convé fer-ho amb migració per rutes, mòduls o plantilles, no amb un “big bang” sense pla de rollback.
Quan sí que consideraria una reescriptura
Una reescriptura completa pot tenir sentit si:
- el stack impedeix complir requisits essencials;
- no hi ha cap manera raonable d’aïllar mòduls;
- les dependències crítiques estan abandonades;
- el cost de mantenir supera clarament el cost de reconstruir;
- el producte ha canviat tant que l’arquitectura actual ja no representa el negoci.
Fins i tot llavors, la reescriptura ha de conviure amb el sistema actual durant un temps i tenir criteris de sortida clars.
Què no tocaria al principi
En una intervenció urgent evitaria barrejar refactorització amb redisseny visual, canvi de CMS, migració d’analítica i noves funcionalitats comercials al mateix temps. Cada eix afegeix incertesa. Si el negoci necessita seguir captant leads o venent, el primer objectiu ha de ser reduir risc operatiu, no obrir tots els fronts possibles.
També evitaria refactoritzar zones que no canvien, no fallen i no afecten conversió només perquè “es veuen antigues” al codi. El deute que no impacta en cost de canvi pot esperar. La prioritat hauria d’estar en peces calentes: formularis, plantilles amb trànsit, integracions, checkout, automatitzacions i mòduls que bloquegen l’equip sovint. Aquest focus ajuda que l’equip vegi progrés en producció sense esperar mesos a una promesa de reescriptura perfecta.
Checklist de decisió
- Quin problema de negoci resol la refactorització?
- Quina part del sistema fa més mal?
- Què es pot mesurar abans i després?
- Hi ha proves mínimes per no trencar el que ja existeix?
- Quina zona es pot aïllar primer?
- Quines dependències convé retirar?
- Qui serà owner tècnic?
- Quin és el pla de rollback?
- Què no es tocarà encara?
Lectures relacionades
- Performance i conversió: com llegir Core Web Vitals
- Arquitectura de components en vanilla JS
- Plugins de WordPress el 2026: quan instal·lar i quan desenvolupar
Conclusió
Refactoritzar no és embellir codi. És recuperar capacitat de canvi. Quan el deute ja afecta el negoci, la millor resposta no és córrer cap a una reescriptura total, sinó mesurar, aïllar, estabilitzar i avançar amb un pla que redueixi risc des de la primera setmana.
Preguntes freqüents
- Una refactorització urgent implica reescriure tota la web?
- No. En molts casos és més segur aïllar riscos, estabilitzar mòduls crítics, afegir proves i refactoritzar per etapes que iniciar una reescriptura completa.
- Quan el deute tècnic es converteix en risc de negoci?
- Quan frena desplegaments, provoca errors freqüents, impedeix mesurar conversió, empitjora el rendiment o fa que cada canvi petit sigui imprevisible.
- Què s'ha de mesurar abans de refactoritzar?
- Freqüència de bugs, temps de desplegament, temps de càrrega, parts del codi més tocades, dependències crítiques, cost de manteniment i risc comercial de cada àrea.