- Et aldrende produkt kan endres der det står, eller bygges på nytt ved siden av det gamle.
- Fire spørsmål avgjør hvilken vei: hva som fortsatt fungerer, hva som hindrer endring, hvor lenge plattformen støttes, og hva teamet ditt kan bære.
- Ingen av veiene er den trygge i seg selv. Den riktige er den svarene dine peker mot.
Før eller senere havner hvert produkt som har levd en stund, i det samme møtet. Noe har blitt vanskelig å endre, og noen spør om det ville vært bedre å begynne på nytt. Rommet deler seg gjerne i to leirer. Den ene sier at koden er et rot, og at bare en ny start kan rette det opp. Den andre sier at en ombygging er måten gode produkter går tapt på.
Begge leirene har iblant rett. Spørsmålet er ikke hvilken leir som høres klokest ut, men hvilken situasjon du står i. Denne guiden gir fire spørsmål som skiller de to situasjonene fra hverandre. Svar ærlig på dem, så avgjør beslutningen seg som regel selv.
Hva fungerer fortsatt?
Begynn med det produktet gjør godt, ikke med det som er galt med det.
Spør dem som bruker det, ikke bare dem som vedlikeholder det. Hvilke brukerreiser stoler kundene på uten å tenke over det? Hvilke skjermbilder hører kundeservice aldri noe om? Hvilke rapporter stoler økonomiavdelingen på? Et produkt som i det stille gjør det meste av jobben sin, bærer mye kunnskap i koden, og mye av den kunnskapen ble aldri skrevet ned noe annet sted.
Hvis det meste av det brukerne trenger fortsatt fungerer, taler det for å endre produktet der det står. Du beholder det som er riktig, og retter det som ikke er det. Hvis lite av det fungerer, eller det som fungerer er det ingen trenger lenger, er det mindre å beskytte, og en ombygging taper mindre.
En ombygging må ta med seg atferden ingen dokumenterte, og det er der ombygginger gjerne går galt. Vi skrev om det i Legacy rebuilds fail at the edges (på engelsk), så vi gjentar det ikke her. Les den før du bestemmer at lite er verdt å beholde.
Hva hindrer endring?
Sett deretter navn på det som gjør endring vanskelig. Vær konkret: ikke «koden er gammel», men «en endring i prisingen berører filer over hele koden» eller «vi kan ikke legge til et felt i kunderegisteret uten å ødelegge eksporten».
Se så på hvor disse hindringene sitter.
Sitter de på noen få steder du kan peke på, kan de tas én om gangen mens resten av produktet fortsetter å fungere. Det taler for å endre der det står. Går de gjennom fundamentet, slik at nesten enhver endring møter den samme veggen, kan det hende at å jobbe seg rundt dem én etter én aldri når slutten av listen. Det taler for å bygge om.
En nyttig test: Hvis du fjernet de tre verste hindringene, ville produktet føles annerledes for dem som endrer det? Hvis ja, ser du sannsynligvis på endring der det står. Hvis det ærlige svaret er «det ville stått tre nye bak dem», bør du se nærmere på den andre veien.
Hvor lenge støttes plattformen?
Hvert rammeverk og hver kjøretid har noen som lager dem, og som bestemmer hvor lenge de publiserer rettelser for hver versjon. Det skriver de på sine egne sider. Dette er det eneste spørsmålet i denne guiden som har en dato som svar.
To eksempler, hvert fra prosjektets egen side. Vues eget repository oppgir at Vue 2 nådde End of Life 31. desember 2023 og ikke lenger får nye funksjoner, oppdateringer eller rettelser. Utgivelsesplanen for Node.js oppfører Node.js 20 som End-of-Life fra 30. april 2026. Vår kalender over når rammeverk når slutten på støtten (på engelsk) samler flere slike datoer, hver lenket til kilden sin.
At støtten tar slutt, avgjør ikke i seg selv valget mellom de to veiene. Det som betyr noe, er hva som ligger på den andre siden. Finnes det en nyere, støttet versjon av den samme plattformen, og produktet kan bringes over til den, er det endring der det står: en stor en, kanskje, men produktet beholder formen sin. Har plattformen selv ingen støttet framtid, eller er steget til neste versjon så stort at lite av den gamle koden overlever det, har grensen mellom å oppgradere og å bygge om allerede blitt utydelig, og en ombygging fortjener en rettferdig vurdering.
Hva kan teamet ditt bære?
Det siste spørsmålet handler om mennesker, og det er det som oftest hoppes over.
Å endre der det står, ber teamet ditt holde produktet i drift mens det endres under dem. Hver endring går ut til ekte brukere, så de trenger trygghet på det de leverer, og en måte å vite at det som fungerte i går, fortsatt fungerer i dag.
Å bygge om ber om noe annet. En periode finnes det to produkter: det gamle, som fortsatt betjener kundene og fortsatt trenger rettelser, og det nye, som vokser fram ved siden av. Noen må holde det gamle oppe, noen må bygge det nye, og noen må bestemme når byttet skjer. Et team som allerede strekkes av ett produkt, vil kjenne på to.
Ingen av delene er lett. Spør hvilken byrde teamet ditt kan bære, ved siden av alt annet på veikartet.
Vei svarene sammen
Ingen enkeltsvar avgjør det. Et produkt som stort sett fungerer, med hindringer du kan peke på, på en plattform med en støttet framtid, og et team som kan bære jevn endring, peker tydelig mot endring der det står. Et produkt som stort sett svikter brukerne sine, hindret i fundamentet, på en plattform uten noe sted å gå, peker mot en ombygging. De fleste produkter havner et sted imellom, og det er der beslutningen er din å ta, med de fire svarene foran deg.
Vær på vakt mot ett argument spesielt: at den ene veien er raskere enn den andre. Hvor lang tid hver av dem tar, avhenger av produktet ditt, ikke av veien, og den som sier noe annet før de har sett på det, gjetter.
Begge veier, fra vår egen historikk
Vi har gått begge, og vi kan vise til ett eksempel på hver.
Endret der det står, for en kunde vi ikke navngir, et nordisk B2B-programvareselskap: Nettapplikasjonen deres ble oppgradert i sin egen kodebase fra Vue 2 til Vue 3.5 og Vuetify 4 på under seks uker, med mer enn 3 000 automatiske tester på plass før overgangen til Vue 3. Det er historikken til ett produkt, ikke en prognose for ditt.
Bygget om: Spillvipps ble bygget om med Zefana.
Hvilken vei som passer produktet ditt, avhenger av de fire svarene dine, ikke av hva vi gjorde for noen andre.
Der vi kommer inn
Peker svarene dine mot en ombygging, er det vi kan ta på oss beskrevet i Rebuild a legacy web application without losing what works (på engelsk). Peker de den andre veien, beskriver Move off an ageing framework without stopping the product (på engelsk) den veien.
Produktet ditt fortsetter å bevege seg framover, uke etter uke. Arbeidet havner i ditt eget kodelager. Du bestemmer hva som leveres. Ingenting når brukerne dine uten din godkjenning.
Det starter med en samtale, helt uforpliktende.
