El teu deute tècnic té solució (i no és reescriure)

El teu producte funciona. Els usuaris el fan servir, el negoci genera ingressos, l'equip llança funcionalitats. Però cada nova feature triga més del que hauria. Els bugs apareixen on ningú no els espera.

Hi ha parts del codi que ningú vol tocar perquè no se sap ben bé què fan ni per què.

Això és deute tècnic. I si et sona familiar, no estàs sol. Segons dades de Stripe, els equips de desenvolupament dediquen de mitjana un 33% del temps a gestionar deute tècnic en lloc de construir coses noves. No és un problema més petit.

La reacció natural quan s'acumula el deute és pensar a reescriure. Començar de zero, fer-ho "bé aquesta vegada". Però les reescriptures completes són una de les decisions més arriscades que pot prendre un equip de producte. Triguen més del previst, costen més del pressupostat i, mentrestant, el producte que genera ingressos es congela.

Hi ha una altra manera de fer-ho.

Què és el deute tècnic (i què no és)

El terme el va encunyar Ward Cunningham el 1992, i l'analogia financera continua sent la millor manera d'entendre'l. Igual que pots demanar un préstec per avançar més ràpid i després tornar-lo amb interessos, en desenvolupament pots prendre dreceres tècniques per lliurar abans a canvi d'un cost futur.

El problema és quan aquest cost futur no es paga. Els interessos s'acumulen: el codi és més difícil d'entendre, més fràgil, més lent de modificar. El que abans feia un dia comença a fer una setmana.

Però no tot codi antic o imperfet és deute tècnic. Convé distingir:

Deute deliberat. Es va prendre una drecera conscientment per complir un termini, amb la intenció d'arreglar-ho després. És legítima si es gestiona.

Deute accidental. L'equip no sabia que estava creant deute. Faltava experiència, context o simplement les coses es van fer de pressa. És la més comuna.

Deute dentorn. Les dependències es queden obsoletes, els frameworks evolucionen, les bones pràctiques canvien. Codi que era correcte fa tres anys pot ser deute avui sense que ningú hagi fet res malament.

Codi simplement dolent. No és deute, és un defecte. La diferència importa perquè la solució és diferent.

Identificar quin tipus de deute tens és el primer pas per decidir com actuar.

Com saber si el teu deute tècnic és un problema real

Tota base de codi té una mica de deute. És inevitable i, fins a cert punt, acceptable. La qüestió no és si existeix, sinó si està frenant el negoci.

Hi ha senyals clars:

Les noves funcionalitats triguen cada cop més. Si fa un any una feature mitjana trigava dues setmanes i ara en triga sis, alguna cosa està passant. I poques vegades és que l'equip treballi menys.

Els bugs es multipliquen a zones inesperades. Toques un mòdul i se'n trenca un altre que aparentment no tenia relació. Això sol indicar dependències ocultes, manca de tests o acoblaments que ningú va documentar.

L'onboarding de nous desenvolupadors és lent. Si un desenvolupador sènior necessita més d'un mes per ser productiu a la base de codi, el deute està actuant com a barrera d'entrada.

Hi ha parts del codi que ningú no vol tocar. El famós “això funciona, no ho toquis”. Quan un equip evita activament modificar certes àrees, és senyal que el deute en aquesta zona és alt i el risc percebut també.

L'equip tècnic demana “aturar per refactoritzar”. Si l'equip sent que no pot avançar sense netejar primer, el deute ja està afectant la moral i la velocitat.

Si reconeixes tres o més d'aquests senyals, el deute tècnic probablement ja t'està costant diners. No pas en abstracte: en hores de desenvolupament que es perden, en features que no es llancen i en talent que es frustra.

Per què reescriure gairebé mai és la resposta

Quan el deute es torna insuportable, la temptació és llençar-ho tot i començar de zero. Joel Spolsky, cofundador de Stack Overflow, el va anomenar "el pitjor error estratègic que pot cometre una empresa de programari". Potser exagerava, però no gaire.

Les reescriptures completes fallen per diverses raons:

Subestimen la complexitat del sistema actual. El codi existent, per lleig que sigui, conté anys de decisions, correccions de bugs i casos límit que ningú no recorda. Reescriure vol dir redescobrir tot això.

Paralitzen el producte. Mentre l'ordinador reescriu, el producte actual no avança. Els competidors sí. Els usuaris s'impacienten. El negoci s'estanca.

Triguen molt més del previst. És un patró gairebé universal: la reescriptura que trigaria sis mesos acaba trigant divuit. I quan s'acaba, els requisits han canviat.

Creen el seu propi deute. Un equip que reescriu sota pressió comet els mateixos errors que va cometre la primera vegada, o errors nous. El deute no desapareix: es reinicia.

Hi ha excepcions. Si la tecnologia de base està completament obsoleta –un framework sense suport, un llenguatge sense comunitat, una arquitectura que no permet escalar de cap manera–, reescriure pot ser l'única opció. Però fins i tot en aquests casos, una migració progressiva acostuma a funcionar millor que un big bang.

L'alternativa: reducció progressiva

Si reescriure no és la solució, què ho és? Un enfocament incremental. Reduir el deute de forma contínua, integrat a la feina diària, sense parar el desenvolupament de producte.

No és tan èpic com una reescriptura, però funciona.

Identifica on fa més mal

No tot el deute té el mateix impacte. Un mòdul legacy que ningú toca i que funciona és deute, però no és urgent. Un mòdul que l'equip modifica cada setmana i que genera bugs constantment és deute que ara està costant diners.

Prioritza per impacte en el negoci, no pas per elegància del codi. La pregunta no és "quina part del codi és més lletja?" sinó “quina part del codi ens està frenant més?”.

Estableix un pressupost de deute

La regla del 80/20 funciona bé com a punt de partida: el 80% del temps de lequip es dedica a features i producte, el 20% a reduir deute tècnic. Alguns equips usen un esprint complet de cada cinc per a tasques de refactoring. Altres reserven un dia a la setmana.

El més important és que sigui explícit. Si la reducció de deute no està en el pla, no passarà. Les bones intencions no sobreviuen a la pressió d'un mapa de mapatge.

Refactoritza en context

La forma més eficient de reduir deute és fer-ho juntament amb el treball de producte. modificaràs un mòdul per afegir una feature: aprofita per netejar el que trobis. No necessites un tiquet separat de refactoring. No cal demanar permís.

És el que Martin Fowler anomena la "regla del boy scout": deixa el codi una mica millor del que el vas trobar. No perfecte. Una mica millor. Multiplicat per desenes de commits al mes, l'efecte acumulat és enorme.

Afegeix tests on no n'hi ha

El deute tècnic sense tests és deute cec: no saps què es trencarà quan el toquis. Abans de refactoritzar una zona crítica, escriu tests que cobreixin el comportament actual. No necessites un 100% de cobertura: necessites els tests suficients per saber que no estàs trencant res.

Això és especialment important en sistemes legacy on la documentació és escassa o inexistent. Els tests actuen com a documentació viva del comportament esperat.

Modernitza les dependències de manera contínua

No deixis que les dependències es quedin tres versions major per darrere. Actualitzar una llibreria quan porta un release de retard és senzill. Actualitzar-la quan fa quatre anys que no es toca és un projecte en si mateix.

Eines com Dependabot o Renovate automatitzen la detecció d'actualitzacions i generen pull requests que podeu revisar i mergejar amb baix risc. És manteniment preventiu: poc glamurós però molt efectiu.

Documenta les decisions, no només el codi

Molt deute tècnic ve de decisions que tenien sentit en el seu moment però el context del qual s'ha perdut. Per què es va triar aquesta arquitectura? Per què aquest mòdul es va fer així? Sense aquest context, el desenvolupador següent que el toqui no sap si està davant d'una decisió deliberada o un error.

Els ADR (Architecture Decision Records) són una forma lleugera de documentar aquestes decisions. No cal escriure un assaig: només cal explicar què es va decidir, per què i quines alternatives es van descartar.

Quan sí que necessites ajuda externa

La reducció progressiva funciona quan lequip té capacitat per absorbir-la. Però hi ha situacions en què l'equip està tan ocupat mantenint el sistema a la superfície que no té marge per millorar res.

És l'equivalent tècnic d'estar tan endeutat que no pots ni pagar els interessos. En aquests casos, un equip extern amb experiència en refactoring i modernització de sistemes pot desbloquejar la situació: avaluar el deute, prioritzar les intervencions i executar-les sense parar el desenvolupament de producte.

No és cap luxe. És una decisió de negoci. El cost de no actuar —features que no es llancen, desenvolupadors que se'n van, incidents que es repeteixen— sol ser més gran que el cost de la intervenció.

El que importa de veritat

El deute tècnic no és un fracàs. És una conseqüència natural de construir programari en un entorn on els terminis existeixen, els requisits canvien i els recursos són finits. Tota empresa amb un producte digital té deute tècnic. La diferència és com la gestiona.

Ignorar-la és car. Reescriure és arriscat. El que funciona és una mica menys vistós però més sòlid: visibilitzar el deute, mesurar-lo, prioritzar-lo i reduir-lo de forma constant.

No cal parar-ho tot per arreglar la teva base de codi. Necessites incorporar la reducció de deute com a part de la feina, no com una excepció. I si el forat ja és massa gran per al teu equip, demanar ajuda a temps és més intel·ligent que esperar que la situació sigui irreversible.