Börja moderniseringen av en äldre applikation med att skriva ner varför den måste ändras, och bedöm sedan koden och driften tillsammans. Stabilisera systemet och sätt tester runt det beteende som verksamheten är beroende av innan du ändrar strukturen. När skyddsnätet finns på plats: ersätt systemet bit för bit, flytta data medvetet och spara en fullständig omskrivning till det sällsynta fallet där lite är värt att behålla.
Formulera affärsskälet innan du rör koden
Modernisering är dyrt, så börja med skälet. Vanliga skäl är en körmiljö eller ett ramverk som har nått end of life, ändringar som tar veckor eftersom varje release förstör något, ett system som bara en person förstår eller en plattform som inte klarar det verksamheten behöver härnäst. Varje skäl pekar mot ett annat första steg.
Skriv ner skälet med ett mått som du kan kontrollera senare, till exempel hur ofta du släpper nya versioner, hur många incidenter du har eller hur lång tid det tar för en typisk ändring att nå användarna. Utan det blir moderniseringen ett öppet utvecklingsprojekt som är svårt att försvara vid nästa budgetgenomgång.
Bedöm koden och driften innan du bestämmer något
En bedömning visar vad du faktiskt har. Håll den kort och låt den sluta med en skriftlig rapport och ett rekommenderat första steg. Läs koden, men läs också driften: loggar, incidenter, långsamma frågor och hur releaser görs. De värsta problemen finns ofta runt koden snarare än i den.
- Versioner av körmiljö, ramverk och bibliotek, och vilka av dem som inte längre får säkerhetsuppdateringar
- Vilka delar som ändras oftast och vilka som går sönder oftast, enligt versionshistoriken och incidentloggen
- Testtäckningen i de flöden som verksamheten är beroende av
- Hur applikationen byggs, konfigureras och driftsätts, och vem som kan göra det
- Datamodellen, dess storlek och vilka andra system som läser från eller skriver till samma databas
- De personer som känner systemet, och vad bara de vet
Stabilisera driften först, så att arbetet får en stadig grund
Om systemet fallerar varje vecka kommer moderniseringen att avbrytas varje vecka. Åtgärda först det som orsakar incidenter: lägg till övervakning och larm på kritiska flöden, automatisera bygge och driftsättning så att releaser blir repeterbara, och flytta ut hemligheter och konfiguration ur koden.
De här stegen lönar sig direkt och gör varje senare steg säkrare. De visar också tidigt om teamet kan ändra systemet utan att förstöra det, vilket är värt att veta innan du binder dig till en större plan.
Bygg ett skyddsnät av tester runt det beteende du förlitar dig på
Äldre kod har oftast få tester, och det dokumenterade beteendet stämmer sällan med det verkliga. Skriv karaktäriseringstester innan du ändrar strukturen: tester som registrerar vad systemet gör i dag, inklusive dess udda kantfall, så att varje beteendeförändring syns som ett test som fallerar.
Börja i kanterna, med tester som anropar applikationen via dess API eller användargränssnitt och kontrollerar resultaten, eftersom de överlever interna ändringar. För beräkningar och rapporter: kör verkliga indata genom den gamla och den nya koden och jämför utdata. Lägg till mer detaljerade tester för varje del när du refaktorerar den. Vår artikel om att uppgradera en kritisk Java 8-applikation visar samma skyddsnät tillämpat på en uppgradering av körmiljön.
Ersätt systemet bit för bit i stället för att skriva om det
En fullständig omskrivning ser snygg ut på papperet, men det gamla systemet fortsätter att köras och ändras medan det nya kommer ikapp, och varje odokumenterat beteende måste upptäckas på nytt längs vägen. Därför tar omskrivningar så ofta längre tid än planerat medan verksamheten väntar.
Det vanliga alternativet är strangler fig-mönstret. Placera ett routningslager, till exempel en omvänd proxy eller en API-gateway, framför den äldre applikationen. Bygg en funktion i taget i den nya koden och styr trafiken för den funktionen dit när den har visat sig fungera. Det gamla systemet krymper tills det kan stängas av, och verksamheten får värde i varje steg.
En omskrivning kan fortfarande vara rätt beslut: när kodbasen är liten och dess beteende väl förstått, eller när plattformen den körs på inte kan hållas vid liv tillräckligt länge för en gradvis ersättning. Bestäm utifrån skriftliga kriterier, inte frustration.
Behandla data som en egen migrering
Kod kan ersättas i skivor; data är svårare att dela upp. Så länge den äldre och den nya koden delar en databas måste varje schemaändring samordnas. Bestäm tidigt vilket system som är sanningskällan för varje typ av data, och undvik att två system skriver till samma post utan en regel för vilken skrivning som gäller.
När en funktion flyttas: flytta eller synkronisera dess data medvetet, med migreringsskript som testats mot en kopia av produktionen eller med kontinuerlig synkronisering medan båda systemen körs. Planera hur du ska stämma av de två, till exempel med dagliga antal och kontrollsummor, och behåll möjligheten att växla tillbaka tills siffrorna stämmer.
Ordna arbetet efter risk och värde och visa framsteg tidigt
Ordna arbetet så att varje steg antingen minskar risken eller levererar något som verksamheten kan se. En vanlig ordning är att stabilisera och automatisera, lägga till tester, uppgradera körmiljön och sedan bryta ut de funktioner som ändras oftast. Delar som är stabila och sällan rörs kan vänta, ibland på obestämd tid.
Håll planen kort och se över den efter varje steg, eftersom det du lär dig kommer att ändra ordningen. Våra utvecklare har arbetat så här med kritiska system. Via Sopra Steria ledde de en migrering från Java 8 till 16 av en kritisk applikation för dagshandel med gas, och som en del av teamet i Crédit Agricoles molnprogram bedömde vi varje applikation som vi migrerade för att avgöra om den skulle uppgraderas eller byggas om. Om du vill ha en bedömning av ditt eget system, eller ett team som genomför planen, gör SDK Enterprises båda under ett och samma avtal.
Det viktigaste
- Skriv ner affärsskälet till moderniseringen, med ett mått som du kan kontrollera senare.
- Bedöm kod och drift tillsammans innan du väljer mellan uppgradering, gradvis ersättning och omskrivning.
- Stabilisera driften och sätt karaktäriseringstester runt kritiskt beteende innan du ändrar strukturen.
- Ersätt systemet bit för bit bakom ett routningslager, om inte en omskrivning är klart mindre och säkrare.
- Planera ägarskap, synkronisering och avstämning av data som en egen migrering.
Vanliga frågor
Ska vi skriva om vår äldre applikation från grunden?
Oftast inte. En omskrivning konkurrerar med ett system som fortsätter att ändras och måste upptäcka beteenden som ingen har dokumenterat. Ersätt den gradvis, om inte kodbasen är liten och väl förstådd eller bunden till en plattform som inte kan hållas i drift.
Hur lång tid tar det att modernisera en äldre applikation?
Det beror på systemets storlek, testtäckningen, hur sammantrasslade data är och hur mycket som behöver ändras. En kort bedömning ger dig en realistisk plan och ett första steg som är litet nog att slutföra och mäta, i stället för ett enda datum för hela arbetet.
Kan vi fortsätta leverera funktioner medan vi moderniserar?
Ja, och det bör du göra. Gradvis ersättning låter teamet leverera funktioner i den nya koden medan det äldre systemet fortsätter att köras. Kom överens om hur stor del av teamets tid som går till moderniseringen, så att funktionsarbetet inte tyst äter upp den.