Sådan flyttes milliarder af kodelinjer fra VB6
VB6 er en død sild. Microsoft har vinket farvel til den gamle udgave af Visual Basic, som ikke er kompatibel med efterfølgeren, Visual Studio .Net.
Det var nødvendigt at modernisere Visual Basic på en række områder, for at få sproget til at passe sammen med det kørselsmiljø, som ligger under hele familien af .Net-sprog. Det betyder, at mange firmaer står med håret i postkassen og massevis af VB6-kode på disken.
Firmaet Artinsoft, som er baseret i Costa Rica, har udviklet et værktøj, som kan oversætte VB6 til VB.Net og C#.
Det er i høj grad C#, som kunderne er interesseret i at oversætte til, fortæller Artinsofts direktør Roberto Leitón Garro, der er i Danmark for at snakke med samarbejdspartneren Avanade.
»I de næste tre til fem år er der 24 milliarder linjers kode, som skal flyttes. Det giver en ide om, hvor meget VB6, der er derude,« fortæller Roberto Leitón Garro.
Artinsofts værktøj kan tilrettes kundernes ønsker. Det skyldes at problemerne ved at oversætte VB6-kode især stammer fra tredjepartskomponeter, som ikke nødvendigvis har en pendant i .Net-verdenen. Et andet ønske som kunderne stiller op med, er muligheden for at få koden til at opfylde bestemte krav til udformning. Sådanne politikker findes i mange store virksomheder.
Kunstig intelligens oversætter Artinsoft kan oversætte 90 til 95 procent af kildekoden, målt i kodelinjer, helt automatisk. Det kan øges ved at tilrette værktøjet til specifikke kodebaser, og det sker ved at tilføje regler til værktøjet, som fungerer ved at benytte kunstig intelligens, der prøver at genkende mønstre i koden. Det er, hvad der kaldes for en "semantisk oversætter."
Der er ikke noget kørselsmodul, som skal benyttes til at afvikle den oversatte kode, og dermed slipper kunderne også for ekstra licensomkostninger.
Firmaet her endda oversat VB6 for selveste Microsoft og har netop oversat fem millioner kodelinjer for bankvirksomheden Citigroup. Firmaet står også bag den "upgrade wizard," som følger med Visual Studio, Microsofts universalværktøj.
Selve den automatiske oversættermaskine kan klare millionvis af linjer på et par dage, men hele oversættelsesprocessen minder meget om så mange andre softwareprojekter.
Første fase handler om at kigge VB6-programmet efter i sømmene. Dernæst kigger partner-selskabet Avanade tættere på koden, og derefter kværnes kodebasen gennem oversætteren. Det giver en ny kodebase, som ikke kan kompileres på grund af fejl, og det er startskuddet til at rette den sidste del af koden i hånden. Til sidst testes programmet på samme måde som alle andre softwareprodukter.
Men på trods af den omfattende proces er der stadig penge at spare ved at oversætte, i forhold til at skrive programmet om fra bunden. Ifølge Roberto Leitón Garro koster det fem gange mere at starte forfra, og tidsbesparelsen er i samme størrelsesorden.
Ifølge partner-firmaet Avanades danske afdeling er der ikke den store interesse for at flytte programmernes forretningslogik til andre arkitekturer, som f.eks. webapplikationer eller SOA-løsninger. Kunderne er glade for de pc-baserede programmer, som de er.
Kommentarer (2)
Det betyder at mellem hver tiende og hver tyvende kodelinje skal håndoversættes. Det vil kræve indsigt i koden i en sådan grad, at man næsten ligesågodt kan håndoversætte det hele.
Jeg er også lidt loren ved ideen om at bruge kunstig intelligens til at genkende kodemønstre. Selv om de bruger betegnelsen "semantisk oversættelse", tvivler jeg på, at der er garantier for, at semantikken bevares.
Jeg kan ikke se, at det skulle være umuligt at oversætte al VB6-kode til .NET -- hvis man altså kender den præcise semantik for VB6. Det kan selvfølgelig være et problem, hvis der ikke findes et dokument, der beskriver dette, men at man skal til at lave reverse engineering for at finde det, men det skulle alligevel være overkommeligt.
Det kan så være, at den resulterende kode ikke er specielt læsbar, fordi man ikke direkte kan bruge lignende programstrukturer i VB.NET (fordi de ikke har eksakt samme semantik), men man kan gøre et forsøg på at gøre det læseligt, hvor det er muligt. Og jeg vil til enhver tid have en 100% korrekt oversættelse, der måske kun er 75% læsbar, end en 100% læsbar oversættelse, der kun er 95% korrekt.
-
0 -
0
De linier, der skal håndoversættes, kræver ikke funktionel indsigt i applikationen, men handler primært om at løse tekniske ting et automatisk konverteringsværktøj ikke kan håndtere, som f.eks. visse former for COM+ anvendelse. Det er vores erfaring at disse rettelser af ”konverteringsfejl” sagtens kan laves af folk, der ikke har specielt kendskab til den specifikke applikation. Endvidere gælder, at selvom en mindre del af koden skal håndoversættes, er der stadig en ganske stor besparelse i at slippe for at håndoversætte de øvrige 90-95% som kan være mange 100.000 linier kode. Det er i øvrigt ikke vores erfaringer at andre værktøjer kan garantere en 100% automatisk oversættelse under alle omstændigheder.
Vi hører mange af vore kunder efterspørge at ”koden kan vedligeholdes manuelt bagefter” uden brug af specielle run-time engines, som binder kunden til produkter og/eller licenser. Vi er derfor meget begejstrede for ArtinSofts semantiske oversættelse, hvor f.eks. ”On Error Goto” sætninger erstattes med ”Try/Catch” og ”if, else, elseif” ændres til ”switch statements” i .NET koden under konverteringen og at koden reelt bliver ligeså god som om den var håndkonverteret.
Ved store projekter anbefaler vi en tilpasning af ArtinSoft værktøjet, så kunden kan få præcis den kode ud de ønsker, der overholder interne kode-guidelines, og hvor vi up-front minimerer antallet af tilfælde, hvor en automatisk konvertering ikke er mulig.
Jakob Leander, Solution Manager, Avanade
-
0
-
0
Tilføj kommentar
