Overvejelser ifbm komplekst system

Umiddelbart synes jeg det er svært og sige hvad du skal gøre, udover den måde jeg tror jeg ville gøre det.

1.
Bruge rigeligt med tid på og gå gennem den eksisterende kode, og analyserer den. Bryde den ned i de store og mindre klumper det med garanti vil have.

2.
Ud fra hvad du finder frem til, undersøge mulighederne for at gøre de forskellige ting - altså kode de forskellige klumper, på den mest hensigtsmæssige måde.
Hvor mange klumper kan der deles op i, og hvordan kan de laves smartest. I hvor stor en grad kan klumperne laves, så de kan genbruges forskellige steder i koden.

Det kan være noget besværligt noget og kigge på, og afhængig af den kode-struktur og den dokumentation der er af den eksisterende kode, vil det være en kæmpe del af opgaven.

Noget jeg på det kraftigste kan fraråde er, at gå koden igennem fra ende til anden, og så ellers bare begynde og skrive den direkte over i C#.
Du ender med garanti op med noget værre rod, og overser de steder du ville kunne gøre tingene bedre og smartere, hvis ikke du har det "gyldne" overblik.
...Desværre taler jeg af bitre erfaringer :)

Hej stalle

Tak for dit svar.

"Dokumentationen er i koden" som man siger, når der ikke er nogen. ;)

Derudover kan jeg sige, at jeg bliver kastet direkte i ilden når jeg starter, da vi skal holde møde omkring arkitekturen stor set fra dag 1 - og det forventes, at jeg har noget intelligent at sige! :D

Så jeg ville natuligvis gerne kunne sige noget fornuftigt i den forbindelse. ;)

Hvis du/andre har brug for yderligere infomation, så spørg endelig. Jeg kan måske svare. :D

Ja, det var vist som man kunne "frygte"

Uden og kende dit egentlige kendskab til den kode du skal arbejde i, vil jeg stadig mene, at en stor del af processen er, at danne sig et overblik over hvad hulen det lige er koden gør.

Jeg gætter på, at det er noget software der i tidernes morgen er blevet arbejdet på løbende, så der vil med garanti være meget og hente i og optimere på den.
Den slags bliver meget let noget "spagetti" programmering.

Hvad du skal sige fra dag et, afhænger med andre ord ret meget af, hvor godt et kendskab du har til koden.
Selvfølgelig kan du begynde og tale om, hvordan man normalt griber den slags projekter an - og lige DER har jeg ikke de store erfaringer - udover hvad du IKKE skal gøre :)

Jeg er selv autodidakt programmør, så har ikke undervisning i de forskellige begreber i forhold til og gribe en større opgave an - blot praktisk erfaring:)

"Selvfølgelig kan du begynde og tale om, hvordan man normalt griber den slags projekter an - og lige DER har jeg ikke de store erfaringer - udover hvad du IKKE skal gøre :)"

Jeg vil gerne høre, hvad du mener jeg IKKE skal gøre? :D

Som jeg nævner i det første jeg skriver


Og føre kildekoden over 1:1 og bare skrive C# koden, mens du sidder og læser VB koden, kan ikke anbefales.
Der er med garanti mange ting i VB koden, der kan laves mere hensigtmæssigt.
Nye metoder og nyere versioner af fx .NET vil uden tvivl byde på bedre metoder til og kunne optimerer den process man går gennem, for at nå et endeligt resultat.
Derfor mener jeg, det eneste rigtige og gøre, er at danne sig et gyldent overblik over koden og hvad den gør, og så efterfølgende finde frem til den bedste måde og gøre det med de teknologier og værktøjer der findes i dag.

Jeg er selv gået i gang med at lave et stykke vb.net software om, fordi jeg i min videre færd med at programmere, har lært mig nye teknikker til at systematisere min kode.

Faktisk er det et projekt der startede ud som et VBScript, bestående af 2 script filer.
Sidenhen valgte jeg, da det blev alt for komplekst og styre i VBScript, og flytte det over i noget VB.net.
Til min store ærgelse gjorde jeg netop det, at jeg "bare" gik i krig med at skrive koden mere eller mindre 1:1, over i VB.NET.

Jeg er derfor nu gået i krig med, at lave endnu en omskrivning - denne gang over til C#, hvor jeg har delt tingene væsentligt mere op i brugbare klumper.
Gennemtænker tingene, så jeg ikke behøver skrive den samme kode flere gange, med ganske få ændringer fordi det jeg på det givne punkt, ikke er 100% som sidst jeg brugte koden.
Så hvad der startede ud med 2 VBScript filer, er nu endt i en VS løsning, der bygger på 4 projekter. 4 projekter der virker sammen, men også kan benyttes uafhængigt af hinanden.
Det kan virke som noget "overkill", men mener selv det giver meget god mening.

Ok, tak for dit input - jeg venter lige og ser om der kommer nogen guldkorn fra andre. ;)

http://newz.dk/forum/programmering/hvordan-saetter-i-jer-ind-i-andres-kode-125944

har muligvis nogle relevante betragtninger

Jeg er helt enig i betragtningen om at der ikke skal konverteres fra VBA til C# men at applikationen skal reimplementeres i C#.

Saa derfor:

VBA app -> krav -> arkitektur -> design -> implementering

Jeg er lidt skeptisk overfor den arkitektur og det design du vil ende op med givet dine forudsaetninger (mangel paa samme).

Men situationen er som den er.

Hvis du kan finde nogen i firmaet at lave lidt faglig sparring med vil jeg dog absolut anbefale det.

Hej Arne

Tak for dit link. Jeg nærlæser det ved lejlighed. :)

Jeg er også enig i den betagtning. Hvor vidt det så rent faktisk kommer til at gå 100% "By-The-Book" er nok en smule tvivlsomt. ;)

Jeg har de samme bekymringer, hvilket også er grunden til at jeg har lavet dette spg. Men jeg har, som nævnt, klargjort overfor bossen hvilke evner jeg besidder. Og der er intet der siger at den første (færdige?) version skal være den endelige. Alt er bedre end det nuværende system. :D

Og ja, det vil være nogen jeg kan snakke med - ud over Jer her på e. ;)

Nå, der kommer vidst ikke mere her - smider I to lige et svar, så vi kan lukke i god ro og orden? :)

svar

Tak :)

Stalle - skal du have points??

Jeg lukker senest søndag aften...