Legacy JavaScript
skal sjældent skrives helt om
jQuery, AngularJS og gammel JavaScript-kode kan være dyr at ændre. Men en total rewrite flytter ofte risikoen i stedet for at fjerne den. Her er en mere kontrolleret vej til en moderne frontend.
Gammel kode er ikke i sig selv teknisk gæld
Hvis en gammel JavaScript-del er stabil, sikker og næsten aldrig ændres, kan det være billigere at lade den være. Problemet opstår, når kodebasen gør ændringer langsomme, skaber fejl, låser jer til udgåede dependencies eller gør det svært at arbejde sikkert i den.
Derfor starter en modernisering med at identificere de områder, hvor den gamle teknologi faktisk koster noget. Ikke med et krav om at alt skal ende i det nyeste framework.
Modernisér omkring klare grænser
1. Kortlæg
Find kritiske flows, dependencies, globale sideeffekter, browserkrav og de dele der ændres ofte.
2. Skab testbarhed
Læg tests omkring de vigtigste forretningsflows, før adfærden ændres.
3. Adskil data og UI
Flyt API-kald og forretningslogik ud af DOM-kode, så frontend kan udskiftes i mindre bidder.
4. Indfør TypeScript selektivt
Start ved nye moduler og tydelige grænser. En big-bang konvertering er sjældent nødvendig.
5. Erstat feature for feature
Nye komponenter kan leve ved siden af gammel kode under en overgang.
6. Fjern det gamle
Dependencies og legacy-kode slettes først, når trafikken reelt er flyttet og den nye del er bevist.
To forskellige moderniseringsproblemer
jQuery
jQuery er ikke nødvendigvis et problem i en lille stabil funktion. I større applikationer opstår udfordringen ofte, når DOM-manipulation, state og forretningslogik er filtret sammen. Her kan nye komponenter gradvist overtage afgrænsede områder.
AngularJS
AngularJS 1.x har været ude af officiel support siden 2021. Her bør risikoen vurderes mere aktivt. En strangler-tilgang, hvor routes eller funktioner flyttes gradvist, kan være mindre risikabel end en parallel total rewrite.
Framework-skift
Modernisering behøver ikke betyde React. Vue, Angular eller en enklere web-stack kan være bedre afhængigt af team, produkt og eksisterende arkitektur.
Nogle gange er en ny kodebase stadig den rigtige beslutning
En rewrite kan give mening, hvis produktet samtidig ændrer sig grundlæggende, den eksisterende arkitektur ikke kan understøtte de nye krav, eller hvis en gradvis migration kræver dyr dobbeltvedligeholdelse i mange år.
Men beregn hele risikoen: skjulte forretningsregler skal genopdages, gamle edge cases skal genimplementeres, og ny software får også fejl. Bevar derfor den gamle løsning som reference, migrér data og brugere kontrolleret, og planlæg en reel rollback.
Et godt første mål
Vælg én funktion, som ændres ofte og har tydelige grænser. Modernisér den ende til ende og mål, om deploy-frekvens, fejlrate eller udviklingstid faktisk bliver bedre.
){kind=small}
){kind=small}
){kind=small}
){kind=small}
){kind=small}