Begynd moderniseringen af en ældre applikation med at skrive ned, hvorfor den skal ændres, og vurder derefter koden og driften samlet. Stabilisér systemet, og sæt tests om den adfærd, forretningen er afhængig af, før du ændrer strukturen. Når det sikkerhedsnet er på plads, så udskift systemet bid for bid, flyt dataene med omtanke, og gem en fuld omskrivning til det sjældne tilfælde, hvor der er lidt, der er værd at beholde.
Sæt ord på forretningsbehovet, før du rører koden
Modernisering er dyrt, så start med årsagen. Almindelige årsager er en runtime eller et framework, der ikke længere understøttes, ændringer, der tager uger, fordi hver release ødelægger noget, et system, som kun én person forstår, eller en platform, der ikke kan understøtte det, forretningen har brug for fremover. Hver årsag peger på et forskelligt første skridt.
Skriv årsagen ned med et mål, du kan tjekke senere, for eksempel hvor ofte der udgives nye versioner, hvor mange hændelser der er, eller hvor lang tid en typisk ændring er om at nå brugerne. Uden det bliver moderniseringen et åbent udviklingsprojekt, som er svært at forsvare ved næste budgetgennemgang.
Vurder koden og driften, før du beslutter noget
En vurdering fortæller dig, hvad du faktisk har. Hold den kort, og lad den slutte med en skriftlig rapport og et anbefalet første skridt. Læs koden, men læs også driften: logs, hændelser, langsomme databaseforespørgsler og måden, releases udføres på. De værste problemer ligger ofte omkring koden snarere end i den.
- Versioner af runtime, framework og biblioteker, og hvilke af dem der ikke længere får sikkerhedsrettelser
- Hvilke dele der ændres oftest, og hvilke der går i stykker oftest, ud fra versionshistorikken og hændelsesloggen
- Testdækningen på de forløb, forretningen er afhængig af
- Hvordan applikationen bygges, konfigureres og udrulles, og hvem der kan gøre det
- Datamodellen, dens størrelse, og hvilke andre systemer der læser fra eller skriver til den samme database
- De personer, der kender systemet, og hvad kun de ved
Stabilisér driften først, så arbejdet har et fast fundament
Hvis systemet fejler hver uge, bliver moderniseringen afbrudt hver uge. Ret først det, der skaber hændelser: tilføj overvågning og alarmer på kritiske forløb, automatisér build og udrulning, så releases kan gentages, og flyt hemmeligheder og konfiguration ud af koden.
Disse skridt betaler sig med det samme og gør alle senere skridt mere sikre. De viser også tidligt, om teamet kan ændre systemet uden at ødelægge det, hvilket er værd at vide, før du forpligter dig til en større plan.
Byg et sikkerhedsnet af tests omkring den adfærd, du er afhængig af
Ældre kode har som regel få tests, og dens dokumenterede adfærd svarer sjældent til dens reelle adfærd. Før du ændrer strukturen, så skriv karakteriseringstests: tests, der registrerer, hvad systemet gør i dag, inklusive dets mærkelige kanttilfælde, så enhver ændring i adfærd viser sig som en fejlende test.
Start i kanterne med tests, der kalder applikationen gennem dens API eller brugerflade og kontrollerer resultaterne, fordi de overlever interne ændringer. For beregninger og rapporter kan du afspille rigtige input gennem den gamle og den nye kode og sammenligne output. Tilføj mere finkornede tests til hver del, efterhånden som du refaktorerer den. Vores artikel om opgradering af en kritisk Java 8-applikation viser det samme sikkerhedsnet anvendt på en runtime-opgradering.
Udskift systemet bid for bid i stedet for at skrive det om
En fuld omskrivning ser pæn ud på papiret, men det gamle system bliver ved med at køre og ændre sig, mens det nye indhenter det, og al udokumenteret adfærd skal genopdages undervejs. Derfor tager omskrivninger så ofte længere tid end planlagt, mens forretningen venter.
Det sædvanlige alternativ er strangler fig-mønsteret. Placér et routinglag, for eksempel en reverse proxy eller en API-gateway, foran den ældre applikation. Byg én funktion ad gangen i den nye kode, og send trafikken for den funktion dertil, når den har bevist sit værd. Det gamle system skrumper, indtil det kan slukkes, og forretningen får værdi ved hvert skridt.
En omskrivning kan stadig være det rigtige valg: når kodebasen er lille, og dens adfærd er godt forstået, eller når den platform, den kører på, ikke kan holdes i live længe nok til en gradvis udskiftning. Beslut ud fra skriftlige kriterier, ikke ud fra frustration.
Behandl dataene som en migrering for sig
Kode kan udskiftes i skiver; data er sværere at dele op. Så længe den ældre og den nye kode deler én database, skal hver ændring i skemaet koordineres. Beslut tidligt, hvilket system der er den autoritative kilde for hver type data, og undgå, at to systemer skriver til den samme post uden en regel for, hvilken skrivning der vinder.
Når en funktion flyttes, så flyt eller synkronisér dens data med omtanke: migreringsscripts, der er testet mod en kopi af produktionen, eller løbende synkronisering, mens begge systemer kører. Planlæg, hvordan du afstemmer de to, for eksempel med daglige optællinger og checksummer, og bevar muligheden for at skifte tilbage, indtil tallene stemmer.
Planlæg rækkefølgen efter risiko og værdi, og vis fremskridt tidligt
Læg arbejdet i en rækkefølge, hvor hvert skridt enten mindsker risikoen eller leverer noget, forretningen kan se. En almindelig rækkefølge er at stabilisere og automatisere, tilføje tests, opgradere runtimen og derefter trække de funktioner ud, der ændres oftest. Dele, der er stabile og sjældent røres, kan vente, nogle gange på ubestemt tid.
Hold planen kort, og gennemgå den efter hvert skridt, fordi det, du lærer, vil ændre rækkefølgen. Vores udviklere har arbejdet sådan på kritiske systemer. Gennem Sopra Steria ledede de en migrering fra Java 8 til 16 af en kritisk applikation til dagshandel med gas, og som en del af programteamet i Crédit Agricoles cloudprogram vurderede vi hver applikation, vi migrerede, for at afgøre, om den skulle opgraderes eller genopbygges. Hvis du ønsker en vurdering af dit eget system eller et team til at gennemføre planen, gør SDK Enterprises begge dele under én kontrakt.
Det vigtigste
- Skriv forretningsbehovet for moderniseringen ned med et mål, du kan tjekke senere.
- Vurder kode og drift samlet, før du vælger mellem opgradering, gradvis udskiftning og omskrivning.
- Stabilisér driften, og sæt karakteriseringstests om den kritiske adfærd, før du ændrer strukturen.
- Udskift systemet bid for bid bag et routinglag, medmindre en omskrivning klart er mindre og sikrere.
- Planlæg ejerskab til data, synkronisering og afstemning som en migrering for sig.
FAQ
Skal vi skrive vores ældre applikation om fra bunden?
Som regel ikke. En omskrivning konkurrerer med et system, der bliver ved med at ændre sig, og skal genopdage adfærd, som ingen har dokumenteret. Udskift det gradvist, medmindre kodebasen er lille og godt forstået eller bundet til en platform, der ikke kan holdes kørende.
Hvor lang tid tager det at modernisere en ældre applikation?
Det afhænger af systemets størrelse, dets testdækning, hvor sammenfiltrede dataene er, og hvor meget der skal ændres. En kort vurdering giver dig en realistisk plan og et første skridt, der er lille nok til at blive gjort færdigt og målt, frem for én dato for hele indsatsen.
Kan vi blive ved med at levere nye funktioner, mens vi moderniserer?
Ja, og det bør I. Gradvis udskiftning lader teamet levere funktioner i den nye kode, mens det ældre system bliver ved med at køre. Aftal, hvor meget af teamets tid der går til modernisering, så arbejdet med nye funktioner ikke i stilhed opsluger den.