Refactoritzar o reescriure: la decisió que pot bloquejar el teu roadmap

El roadmap diu una cosa. La realitat tècnica diu una altra.

L'equip de producte vol llençar tres funcionalitats aquest trimestre. L'equip de desenvolupament diu que, tal com està el sistema, amb sort en trauran una. La conversa sempre acaba al mateix punt: “és que la base de codi no ens deixa avançar”.

En aquell moment apareixen dues opcions sobre la taula. Refactoritzar: millorar el sistema actual sense parar-lo, netejant i reestructurant allò que frena. O reescriure: començar de zero amb una nova arquitectura que resolgui els problemes d'arrel.

Totes dues sonen raonables. Totes dues tenen defensors a l'equip. I totes dues poden ser la decisió correcta o un error costós, depenent de les circumstàncies. El problema és que moltes vegades s'escull per intuïció, per frustració o per pressió, en lloc de per anàlisi.

Aquest article no et dirà quin triar. Et donarà els criteris perquè la decisió sigui teva però informada.

Què significa cada cosa

Convé començar pel bàsic, perquè aquests termes es fan servir de forma ambigua.

Refactoritzar és canviar l'estructura interna del codi sense canviar allò que fa. L'usuari no nota res. El que canvia és com s'organitza per dins: més llegible, més mantenible, més fàcil d'estendre. Es treballa sobre el sistema existent, de manera incremental.

Reescriure és descartar la base de codi actual i construir-ne una de nova des de zero que compleixi les mateixes funcions (i, normalment, incorpori millores). És un projecte en si mateix, amb el seu propi timeline, pressupost i equip.

Entre tots dos extrems hi ha un espectre. No és sempre “una cosa o l'altra”. Però entendre les diferències de fons ajuda a prendre decisions millors.

Els senyals que obren el debat

Ningú no es planteja reescriure un sistema que funciona bé. El debat apareix quan el dolor és real. Aquests són els senyals més habituals:

El temps de desenvolupament ha estat multiplicat. El que abans trigava dies ara triga setmanes. No pas perquè l'equip sigui pitjor, sinó perquè cada canvi requereix entendre i esquivar capes de complexitat acumulada.

Els bugs són impredictibles. Toques un mòdul i se'n trenca un altre. Les dependències entre components són tan opaques que ningú no pot anticipar l'efecte d'un canvi.

La tecnologia de base és obsoleta. El framework ja no té suport, el llenguatge no rep actualitzacions de seguretat, o l'arquitectura impedeix fer coses que el negoci necessita (escalat horitzontal, integracions amb API modernes, desplegament continu).

L'onboarding és etern. Els nous desenvolupadors triguen mesos a ser productius. Hi ha massa coneixement implícit, poca documentació i moltes “trampes” que només coneixen els veterans.

L?equip està desmoralitzat. Els bons desenvolupadors no volen treballar amb codi que els frustra. Si estàs perdent talent perquè el stack tècnic és un llast, el cost ja no és només tècnic.

Si reconeixes diversos d'aquests senyals, tens un problema real. La pregunta és quina solució encaixa.

Quan refactoritzar

Refactoritzar gairebé sempre és l'opció més segura. No pas perquè sigui la millor en tots els casos, sinó perquè el risc és molt menor. Estàs treballant sobre un sistema que ja funciona, amb usuaris reals i un historial de comportament conegut.

El sistema fa el que ha de fer, però costa mantenir-lo. Si el problema és la qualitat interna del codi –acoblament excessiu, manca de tests, noms confusos, mòduls massa grans– però la funcionalitat és correcta i la tecnologia és viable, refactoritzar és la resposta lògica.

Els problemes estan localitzats. No tot el sistema és un desastre. Hi ha zones que funcionen bé i zones que no. Pots atacar les zones problemàtiques sense tocar-ne la resta.

No pots aturar el producte. Si el negoci depèn que el sistema segueixi funcionant i evolucionant mentre es millora, una reescriptura paral·lela pot ser inviable. Refactoritzar permet millorar sense aturar el desenvolupament del producte.

L'equip coneix el sistema. Refactoritzar exigeix ​​entendre bé què hi ha. Si l'equip original segueix i coneix les decisions que es van prendre i per què, té el context necessari per millorar sense trencar.

El pressupost o el termini són limitats. Refactoritzar és incremental. Podeu dedicar un 20% de l'esprint a millores tècniques i obtenir resultats graduals. Una reescriptura exigeix ​​una inversió concentrada i un compromís a llarg termini.

Quan reescriure

Reescriure és l'opció de més risc, però de vegades és l'única que resol el problema de debò. Hi ha situacions en què millorar el que hi ha és posar pegats sobre una estructura que no es pot sostenir.

La tecnologia és un atzucac. Si el framework no té suport, el llenguatge està en declivi, la base de dades no escala o l'arquitectura no permet el que el negoci necessita, cap refactoring no ho resoldrà. Canviar els fonaments requereix tornar a construir.

El cost de mantenir supera el cost de construir. Si cada feature nova costa tres vegades més del que hauria i cada acord introdueix dos bugs nous, mantenir el sistema existent pot sortir més car que començar de zero. Però cal fer els comptes reals, no els optimistes.

Els requisits han canviat radicalment. El sistema es va dissenyar per a un model de negoci que ja no existeix. El que era una web per a 100 usuaris ara necessita servir-ne 100.000. El que era un monòlit ara necessita ser una plataforma amb API. Si el gap entre allò que el sistema és i el que necessita ser és massa gran, adaptar-lo pot ser més costós que reconstruir-lo.

La seguretat és irrecuperable. Si el sistema té vulnerabilitats estructurals que no es poden apedaçar sense refer-ho des de la base, la reescriptura deixa de ser una opció i passa a ser una necessitat.

Les preguntes que t'hauries de fer

Més enllà dels senyals i els criteris, hi ha un conjunt de preguntes concretes que us ajuden a prendre la decisió:

Quant del sistema és rescatable? Si el 70% del codi és sòlid i el problema és en un 30%, refactoritza. Si el 70% és problemàtic, la balança es comença a inclinar cap a reescriure.

Pots definir amb precisió què ha de fer el sistema nou? Una reescriptura sense requisits clars és una recepta per al desastre. Si no podeu especificar què ha de fer el sistema nou millor que l'actual, no estàs preparat per reescriure.

Quant de temps pots sobreviure amb el sistema actual? Si el sistema aguanta 12-18 mesos més amb millores incrementals, tens marge per refactoritzar. Si està al límit i qualsevol pic de trànsit o canvi regulatori el pot trencar, la urgència és una altra.

Què passa amb el producte mentrestant? Una reescriptura pot trigar 12, 18 o 24 mesos. Durant aquest temps, el producte actual es congela o avança a una velocitat mínima. El teu negoci s'ho pot permetre? Els teus competidors esperaran?

Tens l'equip per fer-ho? Una reescriptura necessita desenvolupadors experimentats que entenguin tant el sistema actual com l'arquitectura objectiu. Si no tens aquest equip, externalitzar una reescriptura completa és una aposta de molt alt risc.

La tercera via: el strangler fig

Hi ha una opció que moltes vegades es passa per alt i que combina el millor dels dos enfocaments: la migració progressiva, també coneguda com a strangler fig pattern .

El nom ve de la figuera estranguladora, una planta que creix al voltant d'un arbre existent fins que el reemplaça del tot. En programari, la idea és la mateixa: construeixes les noves peces al voltant del sistema actual, les vas connectant gradualment i, amb el temps, el sistema nou reemplaça l'antic sense que hi hagi hagut una “gran apagada”.

A la pràctica, funciona així: identifiques un mòdul o funcionalitat del sistema actual, el reconstrueixes amb la tecnologia nova com un servei independent, i redirigeixes el trànsit o les trucades cap al nou component. El sistema antic continua funcionant per a tota la resta. Repeteixes el procés mòdul a mòdul.

Els avantatges són clars. No pares el producte. Cada nou component es pot provar i desplegar de manera independent. Si alguna cosa falla, només afecta la part migrada, no tot el sistema. I l'equip no ha de mantenir dos sistemes complets en paral·lel durant mesos.

No és una bala de plata. Requereix una bona definició de les fronteres entre mòduls i funciona millor en sistemes amb certa modularitat (o on es pot introduir una capa de routing). Però per a molts projectes és l'opció més pragmàtica.

Els errors més comuns en decidir

Decidir per frustració. "Estic fart d'aquest codi, el reescriurem" no és una anàlisi: és una emoció. Les reescriptures motivades per la frustració solen subestimar la complexitat del sistema actual i sobreestimar com de fàcil serà el nou.

Subestimar el que el codi actual “sap”. Cada línia de codi en producció conté decisions, correccions de bugs i casos límits que es van descobrir amb el temps. Reescriure vol dir redescobrir tot això. Si no ho teniu en compte, el sistema nou repetirà els mateixos errors.

No involucrar el negoci. La decisió de refactoritzar o reescriure no és només tècnica. Té implicacions en terminis, pressupostos, funcionalitats i risc. Si l'equip tècnic decideix sol, podeu triar l'opció tècnicament elegant però empresarialment inviable.

Compareu el sistema actual amb el sistema nou ideal. És fàcil que la reescriptura guanyi quan la compares amb la versió perfecta que tens al cap. Però aquesta versió no existeix. Compara el sistema actual amb el que realment podràs construir amb els recursos i terminis que tens.

No definir criteris dèxit abans de començar. Com sabràs que la refactorització ha funcionat? Com mesuraràs que la reescriptura ha complert el seu objectiu? Sense mètriques concretes -temps mitjà de desenvolupament d'una feature, nombre d'incidències per mes, temps d'onboarding- no podeu avaluar si la decisió va ser correcta.

Un framework per decidir

Si necessiteu una guia ràpida, aquestes són les preguntes en ordre:

La tecnologia de base té futur? Si no, reescriu (o migra progressivament). Si sí, segueix.

Els problemes estan localitzats o són sistèmics? Si estan localitzats, refactoritza. Si són sistèmics, segueix.

Pots definir clarament els requisits del sistema nou? Si no, no estàs preparat per reescriure. Refactoritza mentre clarifiques. Si sí, segueix.

Tens equip, pressupost i temps per a una reescriptura? Si no, refactoritza. Si sí, valoreu el strangler fig abans del big bang.

No és un algorisme perfecte, però obliga a respondre preguntes incòmodes abans de prendre la decisió. I això, en si mateix, ja millora el resultat.

El que importa de debò

La pitjor decisió no és triar refactoritzar quan calia reescriure, ni reescriure quan n'hi havia prou de refactoritzar. La pitjor decisió és no decidir. Seguir arrossegant un sistema que frena l'equip, que frustra el negoci i que acumula risc cada dia que passa.

Si el teu roadmap fa mesos que xoca amb la realitat tècnica, el problema no es resoldrà sol. Analitza, decideix i actua. I si no tens clar quina opció encaixa, busca algú que hagi passat abans. L'experiència de qui ha vist les dues opcions funcionar (i fallar) val més que qualsevol framework teòric.