Hvordan man lærer det

Der er mange ting, som man ikke kan lære (kun) ved at se andre gøre det. En af disse ting er programmering.

Derfor er en vigtig del af undervisning i programmering at aktivere de studerende til prøve selv, og gøre dem bevidste om, at dette er en meget væsentlig del af deres læringsproces: Programmeringsopgaver stilles ikke for at teste de studerendes kunnen, men for at styrke den. Det er derfor vigtigt, at studerende ikke kan slippe for at lave opgaverne: Dels skal de være obligatoriske, og dels skal der være et individuelt element, så en studerende i en gruppe ikke blot ser et andet gruppemedlem løse opgaven og tænke "det kunne jeg også have gjort".

Det var så den nemme og indlysende del.

Den næste -- og langt sværere -- del er at give de studerende metoder til at gribe de selvstædige programmeringsopgaver an.

Programmering er i bund og grund problemløsning, så derfor er metoder til at løse programmeringsproblemer ikke fundamentalt anderledes end metoder til at løse alle andre slags problemer. Desværre er netop problemløsning ikke noget, som folkeskole og gymnasier underviser i -- på trods af stigende brug af såkaldte "problemopgaver". Groft sagt stiller underviserne bare problemopgaverne, og forventer at de studerende selv finder ud af, hvordan de skal løses. Allerhøjest har underviseren vist eleverne, hvordan en lignende opgave løses. Men her er løsningen som regel serveret som givet fra himlen: De nødvendige skridt udføres med allerhøjest en forklaring på, hvorfor de er nødvendige. Men hele processen med at indse, hvorfor skridtene er nødvendige, og hvordan man finder frem til dem, er ofte overset.

Der findes heldigvis problemløsere, der har studeret deres egen problemløsningsproces og endda formuleret denne som en opskrift til nye problemløsere. En af dem er George Pólya, der i 1945 skrev bogen "How to Solve it". Alderen af dette værk afslører, at forfatteren næppe havde programmering i tankerne, da han skrev bogen. Mere præcist havde han matematik i tankerne, og bruger gennem bogen mange matematiske eksempler, for eksempel hvordan man kan finde afstanden mellem de modsatte hjørner i et rum ved at bruge Pythagoras' sætning flere gange. Men metoderne er gangbare ikke bare til matematik, men til stort set alle former for teknisk problemløsning, herunder programmering.

Pólya opdelte problemløsningsproblemet i fire skridt:

1. Forstå problemet.
2. Lav en plan til løsning af problemet.
3. Udfør planen.
4. Evaluer, hvordan det gik.

For at gå tilbage til den typiske læringssituation, så bliver eleverne ofte præsenteret for skridt 2 og 3, men sjældent skridt 1 og 4. Og de er ofte de vigtigste og sværeste trin.

For hver af de ovennævnte skridt giver Pólya et antal teknikker, som man kan bruge. Det er normalt kun en lille del af teknikkerne, der passer til det givne problem, og det er ikke altid oplagt, hvilke der gør. Men en begyndende problemløser kan prøve de mest lovende teknikker, indtil hun finder en eller flere, der virker. Herunder er et antal metoder, som jeg selv synes virker godt til programmeringsopgaver af den slags, man bliver stillet på et kursus:

Forstå problemet:

Omformuler problemet i dine egne ord: Læs opgaven igennem, læg den væk, og skriv med dine egne ord, hvad opgaven er. Sammenhold derefter din formulering med den oprindelige og gentag processen, indtil din egen formulering dækker problemet. Forsøg ikke at huske opgaven ordret. Din formulering skal helst være så forskellig så muligt fra den oprindelige, men alligevel have samme mening.

Prøv at forklare problemet til en anden.

Find nogle eksempler på input/output.

Overvej, hvordan du vil kunne efterprøve, om din løsning er rigtig.

Problemerne er ofte abstrakte. Prøv at finde et problem i "den virkelige verden", som kan være en instans af det abstrakte problem.

Se, om der er information nok i opgaven til at finde et entydigt svar. Hvis ikke, overvej hvilken information, der mangler.

Lav en plan til løsning af problemet:

Overvej grænsetilfældende. Hvad er det simpleste inddata, hvor funktionen er defineret, og hvad er resultatet? Kan du bruge det som basistilfælde for en induktiv/rekursiv løsning?

Kan du reducere problemet til et eller flere simplere problemer? Kan det bruges til det generelle tilfælde i en induktiv/rekursiv løsning?

Kan du opdele inddata i klasser, der behandles forskelligt? Kan klasseopdelingen kodes som en betingelse?

Er der en symmetri i problemet, du kan udnytte?

Kan du udnytte en matematisk ækvivalens til at omskrive problemet?

Kan du ved at tilføje ekstra variable/parametre løse det mere generelle problem med en induktiv/rekursiv metode?

Lav en plan til afprøvning af din løsning.

Formuler dine overvejelser og din plan skriftligt. Hvis du springer det trin over, så er der stor risiko for, at dine tanker og din plan er for vage til at kunne bruges.

Udfør planen:

FInd konkrete datarepræsentationer af de abstrakte begreber.

Lav funktioner/procedurer til grundlæggende operationer på datarepræsentationerne.

Lav en løsning, der afspejler planen.

Skriv hele tiden kommentarer, der forklarer intentionen med koden -- ikke hvad den gør, men hvorfor den gør det.

Sørg for, at grænsetilfældende er håndteret rigtigt.

Afprøv hele tiden din delvise løsning, og lav den om, hvis noget ikke passer. Overvej dog, om det er afprøvningen, der tager fejl.

Vær ikke bange for at smide kode væk. Nogen gange er det lettere at starte forfra end at lappe på den kode, der er skrevet.

Evaluer, hvordan det gik:

Overvej, om der er tilfælde, som din afprøvning ikke dækker.

Overvej, om der er noget, du ville have gjort anderledes, hvis du vidste det, du ved nu.

Hvis du undervejs var inde på et vildspor, overvej, hvordan du ville kunne have undgået dette.

Var der nogle steder, hvor du gik i gang med at programmere uden at overvejet grundigt nok, hvad din kode skulle gøre?

Hvad har du lært af opgaven?

Som studerende har man endvidere den luksus, at der er erfarne folk (underviserne), der vil tage sig tid til at se på din løsning og komme med feedback om, hvad der er god og skidt med den. Lyt til dem. Det kan godt være, at du synes, at din løsning er genial, men hvis underviserne (som har meget mere erfaring end dig) synes noget andet, så er det nok dem, der har ret. Se evt. Dunning–Kruger effect.

Har jeg glemt noget?