Torben Mogensen header

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?

Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jesper Madsen

Som jeg læser dit indlæg, så henvender du dig til elever der skal starte ved Adam og Eva. Og du tager dem de første par skridt, hen omkring Moses måske.. Når det er lykkedes at lave et program i en størrelse hvor en enkelt person kan have det i hovedet, så er næste udfordring at sætte sig ind i andres kode. Grib noget Open source, f.eks. en favorit browser eller en Web server. Læs koden og forsøg at forstå den. Prøv at finkæmme koden og se om der er svagheder, og se om de svagheder kan vises ved f.eks. Unit test eller system test. Vurder hvad der ville have gjort koden mere forståelig. Vurder hvad der ville gøre den mere testbar. Vurder hvad man kunne gøre kodemæssigt for at skabe en mere fleksibel arkitektur. Kig på hinandens kode, giv forbedringsforslag. Skab et fælles projekt. Lær udfordringerne ved kommunikation om design og arkitektur, lær værktøjer som cvs/subversion/git at kende, hold demo for hinanden og lær af hinandens succes'er og fejltrin.

  • 0
  • 0
Carsten Hansen

Så vidt jeg husker, så er ægte ungarsk notation baseret på bogen. Ikke noget med "int" foran variabelnavne og den slags som nogle anbefaler i lærebøger. I stedet skal variabelnavngivning være et meget bevidst valg afhængig af applikationens formål.

Brinch-Hansen er også glad for bogen, så måske de har diskuteret den i de gyldne dage i regnecentralen.

Jeg har ikke fået den købt endnu, men har overvejet det i lang tid. Måske jeg får gjort noget ved det :-)

  • 0
  • 0
Nicolai Nicolai

Datalogi (computer science) er jo lidt nærmere matematik end de fleste øvrige og egentlige videnskabelige fag. For så vidt programmering så er det jo primært et håndværk. Og når det kommer til håndværk, altså ordet Techne som i Teknologi, så må tankerne gå i retning af Aristoteles som ofte bliver citeret for "For the things we have to learn before we can do them, we learn by doing them" - der er ingen vej udenom.

Men altså med hensyn til den sidste paragraf, at der er erfarne undervisere som vil tage sig tid til at evaluere de studerendes løsninger. Ahem. Det er lidt mere akademisk tror jeg. Da jeg selv studerede på "Datalogi på Københavns Universitet" så var det LANGT overvejende andre studerende som allerede har taget et kursus, som blev sat til at rette opgaver. Og deres erfaring er selvsagt begrænset... Så det at få en opgave tilbage "rettet" var ikke nødvendigvis særligt frugtbart og var mest præget af frygt for at "den dumme instruktor Søren" igen skulle sjuske rette eller tilbagelevere løsningen med irrelevante og vilkårlige bemærkninger som satte dagsordnen for en efterfølgende karakter. Så, I min optik som tidligere studerende, hvis man vil se på Dunning–Kruger effekten så er udbyttet som udgangspunkt langt mere "interessant" hvis man undersøger instrukterne på Datalogi end de studerende ;)

Jeg mener at det bedste man kunne gøre på DIKU ville være at sende flere studerende i praktiker. Det er altså noget som kan rykke (f.eks. er https://cs.uwaterloo.ca/future-graduate-students/programs-courses verdenskendt i Silicon Valley som et uddannelsessted hvor man kan finde dygtige studerende som rent faktisk kan løse virkelighedens problemer).

  • 2
  • 0
Nicolas Guilbert Blogger

Det er en god udgangspointe, at mange vigtige ting kun kan læres ved at gøre.

Når det så er sagt, er det min erfaring, at det altafgørende næste skridt dernæst er, at omgive sig med folk, der kan hjælpe en på vej - altså indgå i et miljø.

Her byder Open Source miljøet på et kæmpemæssigt skattekammer af god kode, dårlig kode, diverse fora, IRC'er, online kurser af meget høj kvalitet mm. Det er bare at tage for sig.

Hvad de studerendes erfarne vejledere angår, ville det være interessant at vide, hvor meget erfaring fra det virkelige liv udenfor elfenbenstårnet de pågældende har.

Bl.a. DIKUs anbefaling af e-valg lugter i hvert fald af, at man har sat ræven til at vogte gæs.

  • 0
  • 0
Log ind eller Opret konto for at kommentere