Problemløsning og programmering

Formålet med denne tekst er at præsentere nogle grundlæggende problemløsningsteknikker og demonstrere anvendelsen af dem ved hjælp af nogle eksempler skrevet i C#. Samtidig præsenteres nogle af C# sprogets basale datatyper og kontrolstrukturer.

Eksemplerne er på ingen måde tænkt som en udtømmende beskrivelse af alle aspekter ved problemløsningsteknik; men udelukkende som en kort introduktion til emnet.

Eksemplerne skal naturligvis suppleres med mere udførlige beskrivelser af bl.a. C# sprogets syntaks og udviklingsmiljøets muligheder. Der kan i den forbindelse henvises til de relevante referencemanualer, som alle findes on-line via udviklingsmiljøets hjælpe filer.

Indhold

Generel strategi for problemløsning

Eksempel 1. Gentagelser og tælleværker.

Eksempel 2. Sammenligning og forgrening.

Eksempel 3. Gentagelse og opsummering.

Eksempel 4. Tabeller.

Nogle øvelsesopgaver, som man selv kan arbejde videre med.

Generel strategi for problemløsning

Det, der er svært i forbindelse med systemudvikling og herunder programudvikling, er at lære at håndtere den enorme abstrakte kompleksitet, som er til stede i den virkelige verdens problemer. Formålet med systemudvikling er jo netop at danne computermodeller af systemer fra den virkelige verden.

Hvis man kunne forestille sig, at man kunne få problemet "kogt ned" til en enkelt eller nogle få formler eller matematiske ligninger, har man også løst problemet, fordi man har fået taget kompleksiteten ud af situationen. Desværre er det meget svært at koge den virkelige verdens problemer ned på denne måde. Tværtimod er der ofte en tendens til at problemet bliver mere og mere uoverskueligt, jo flere detaljer man får kendskab til.

Traditionelt forsøger man at overskue problemets kompleksitet ved hjælp af forskellige former for abstraktion eller distancering fra problemet. En abstraktion har til formål at fokusere på nogle få centrale aspekter ved en situation, hvorimod man bevidst vælger at se bort fra andre.

Hvordan finder man ud af, hvilke aspekter, der er væsentlige i en situation? Og hvilke, der er uvæsentlige?

Svaret er, at denne evne til at skelne imellem væsentligt og uvæsentligt kræver betydelig praktisk erfaring med løsning af konkrete opgaver fra det virkelige liv, hvor den kompleksitet, man skal lære at beherske, netop er til stede. Herved vil man efterhånden blive i stand til ubevidst at skelne det væsentlige fra det uvæsentlige.

Det vigtigste råd man kan give, er aldrig at koble den sunde fornuft fra, når man arbejder med problemløsning. Man får brug for den sunde fornuft, når man skal lave en rationel og kritisk vurdering af de ideer til løsningsforslag, som med erfaringen kommer til én mere eller mindre intuitivt.

Intuition og kreativitet spiller altså en vis rolle; men uden den sunde fornuft bliver man ikke en seriøs professionel udøver af systemudvikling.

Formålet med de følgende anvisninger er et forsøg på at komme ind til kernen af, hvad problemløsning i virkeligheden er for noget, og hvordan vi mennesker kan lære at håndtere de afsindigt komplekse problemstillinger, som vi bliver stillet overfor i professionel system- og programudvikling.

Opstil drejebog (scenario) og lav modeller (prototyper)

Når man skal lave et teaterstykke eller en spillefilm, udarbejder man en drejebog, som i detaljer beskriver forløbet af hver enkelt scene. Det gør man af flere grunde.

For det første har instruktøren behov for at kunne leve sig ind i situationen i en scene allerede på det tidspunkt, hvor man planlægger scenen. Indlevelsesevne er en uhyre vigtig evne for en systemudvikler, og en evne man får brug for, når man skal prøve at forstå, hvad programspecifikationen eller opgaveformuleringen egentlig går ud på. I den virkelige verden er det normalt programmøren selv, der fremstiller specifikationen; men det fritager ham ikke for behovet for indlevelsesevnen - det vanskelige arbejde med at forstå, hvad der er meningen med opgaven, bliver bare flyttet fra programkonstruktion til systemanalysen.

For det andet er der som regel flere mennesker involveret i projektet, og det er vigtigt, at man er i stand til at beskrive sine ideer, så man kan vise dem til andre, når man vil bede dem om deres accept eller kritik.

For det tredie har man også som ophavsmand til ideer det problem, at man ikke kan huske alt. Derfor er det vigtigt, at man får dokumenteret sine ideer, mens man kan huske dem.

Når man skal lave film eller teaterstykker, laver man modeller af kulisser og kostumer. Årsagen hertil er, at det dels kan være meget kostbart at lave en kulisse i fuld skala, og dels, at det giver bedre mulighed for at leve sig ind i scenen, når man ser modellen for sig, samtidig med at man hører beskrivelsen.

De følgende punkter er en række anvisninger på nogle simple ting, man kan gøre, for at få gang i sin kreativitet og indlevelsesevne. På længere sigt er det dog vigtigt, at man finder sin egen stil, så disse punkter må kun opfattes som en foreløbig anvisning. Med øvelsen bliver man i stand til at opstille drejebog og modeller ubevidst og uden anvisninger på, hvordan det skal gøres.

Træf nogle hurtige beslutninger

Det kan være stressende at arbejde som systemudvikler i det virkelige liv. Kravene til produktivitet og kvalitet er høje, og det synes for mange (især begyndere) umuligt at forene kravet om høj produktivitet (tempo) med kravet om høj kvalitet (korrekthed). Tempo og korrekthed er netop begreber, som mange i erhvervslivet anvender som synonymer for produktivitet og kvalitet.

Efterhånden som erfaringen vokser, opdager man imidlertid, at ens produktivitet kan forøges gradvist uden at det påvirker kvaliteten af ens arbejde. Hemmeligheden er, at man lærer at genbruge nogle relativt få løsningsmodeller eller algoritmeskabeloner i et utal af variationer. Algoritmeskabeloner er kendte løsninger på større eller mindre problemer, som man genanvender, fordi man tidligere har anvendt dem med succes.

Programmets struktur.

Oprettet 9. januar 2008
Opdateret 01. februar 2008