Jag håller just nu på att hjälpa några kunder att planera hur de skall uppgradera sina gamla applikationer till ny teknologi och arkitektur. Det finns mycket att fundera på när man skall göra det. Jag kommer nog i några inlägg på min blogg diskutera detta.
Det här är min första reflektion. Konceptet Upgrade, Reuse, Rewrite och Replace kommer ifrån den utmärkat pdf-boken Upgrading Visual Basic 6.0 Applications to Visual Basic .NET and Visual Basic 2005, utgiven av Microsoft och är gratis.
UPGRADE - Man uppdaterar, konverterar, den befintliga koden. Det kan antingen ske manuellt eller med uppgraderingsverktyg. Det positiva är att all logik och alla användargränssnitt följer med. Man har redan allt detta klart och behöver inte göra ny design av applikationen. Nackdelen är att det troligtvis är svårt att göra en bra uppgradering som också följer de mönster och de nya möjligheter som .NET har. Koden kommer troligtvis också bli svårare att senare hantera och förstå. Det kan kräva mycket testning och, om inte personalen redan är duktiga på .NET, mycket tid att förstå vad som är problem och hur man fixar dem.
REUSE - Man återanvänder de gamla komponenterna och bygger nya delar som använder sig av dem. Det kan ske på flera sätt. Det vanligaste är nog att man bygger ett nytt användargränssnitt och återanvänder affärslogik från Com-komponenter. (Detta fungerar nog rätt bra i WinForms-applikationer, men kan vara lite värre i webbapplikationer. Om man gör detta i en webbapplikation måste man ta större hänsyn till att de olika miljöerna använder sig av olika trådmodeller för att köra koden.)
Ett annan variant är att man förändrar sina gamla komponenter något, så att de till exempel kan börja kommunicera med webbtjänster, och sedan bygger nya delar av applikationen med hjälp av detta. Om man gör det får man en större möjlighet att kombinera och återanvända det gamla. Då kan man till exempel återanvända sitt gamla användargränssnitt men utnyttja nya tjänster för att hantera affärslogik och dylikt.
REWRITE - Man skriver om applikationen. Det beslutet kan man komma fram till av många orsaker. Några av de vanligaste är kanske: 1) Koden har blivit väldigt svårhanterlig. Det kostar väldigt mycket att göra förändringar eller rättningar av den. 2) Personal för att underhålla applikationen är väldigt svåra att få tag på. 3) Vissa viktiga och centrala funktionstillägg går inte att göra i den befintliga applikationen. Den kanske måste få ett webbanvändargränssnitt, men arkitekturen gör det fullständigt omöjligt att klara av att tillgodose ett sådant önskemål.
Jag tycker också att det här kan vara av hjälp att dela upp "rewrite" i två underkategorier: "TOTAL REWRITE" och "TECHNOLOGY REWRITE". "Total Rewrite" är när man går helt tillbaka till designbordet och börjar, i princip, designa en ny applikation. Man tittar på användarprocesser och användargränssnitt för att stödja den. Man kanske till och med gör en ny version av sin datamodell. "Technology Rewrite" handlar mer om att man använder den befintliga designen (som det har troligtvis lagts ned mycket tid på) och skriver om systemet med en ny teknologi och arkitektur. Detta har fördelen att man har specifikationen på hur applikationen skall fungera genom att det redan finns en körbar att jämföra med.
REPLACE - Att man byter ut applikationen, helt eller delvis, till ett annat system. Detta kan för många vara ett svårt alternativ att överväga. Det är inte alltid lätt att byta ut en del av det som man känner till och själv. Men det är viktigt att ändå analysera och överväga om man kan utnyttja andra produkter för att utföra de funktioner som den gamla applikationen gör. Många av de gamla applikationerna skrevs för kanske över tio år sedan. Då fanns inte många av de standardapplikationer som vi idag tar för självklara. Det finns också idag helt andra sätt att samverka med standardsystem än det fanns förut. Börjar man också titta på att använda sig av tjänstebaserad arkitektur så blir det ändå lättare att använda sig av komponenter som andra har utvecklat.
Comments