Når vi skal løse et programmeringsproblem skriver vi i praksis aldri et program på blanke ark. Hovedregelen er at vi begynner jobben med å endre et program vi eller andre har skrevet før. Det vi tar med oss fra det vi kopierer fra kan være alt fra rene formalia som er nyttig eller nødvendig i alle programmer i det aktuelle språket, eller det kan være store deler av koden.
Praksis
Det kan være mange kilder for slik kopiering og omskriving.
Egne programmer
Dette gjør vi alltid og det er nyttig og i praksis nødvendig. Det er imidlertid noen momenter som en skal merke seg.
Det er lett å dra med seg dårlige løsninger og dårlige vaner uten å tenke på det, og det kan være at vi drar med oss løsninger eller lenker til ting som har gått ut på dato. De erfaringene vi gjør kan tilsi at vi bør gjøre noen endringer på "standardene" våre.
For eksempel bruker jeg alltid disse to filene når jeg starter arbeidet med en p5js-sketch:
<!DOCTYPE HTML> <html lang="no"> <head> <meta charset="UTF-8"/> <title>test</title> <script src="https://borres.hiof.no/resources/p5js/p5.min.js"> </script> <script src="sketch.js"> </script> </head> <body> <div id="canvasHere"></div> </body> </html>
function setup() {
var canvas = createCanvas(400, 400);
canvas.parent('canvasHere');
}
function draw() {
background(255,255,255);
stroke(0,0,255);
line(0,height/2,width,height/2);
}
lagrer dem som "test.html" og "sketch.js", åpner dem i editoren og jeg er i gang.
Min erfaring er at det er lett å undervurdere nytten av å skrive kommentarer til de løsningene vi bruker, både i selve koden og gjerne i en egen fil i det prosjektet vi arbeider med. Det er av og til forbløffende vanskelig å lese og endre sin egen kode som ble skrevet for noen måneder siden. Når vi skriver kode etablerer vi ofte et sett med logiske forutsetninger som vi sliter med å rekonstruere i en annen setting. Jeg har lært meg å lage en "readme.txt"-fil som har som eneste hensikt å forklare forutsetningene og løsningen for meg selv.
Medarbeideres programmer
Hvis vi arbeider sammen med andre i et prosjekt er dette både nødvendig og naturlig. Det bidrar til at flere øyne leser og flere tester blir gjort. I en startfase i programmering er det naturlig å bruke ganske enkle delingsmekanismer, som tilgang til en felles datalagringsplass og et eller annet kommunikasjonsmedium for å varsle om oppdateringer og endringer. Etterhvert er det naturlig å ta i bruk mer avanserte verktøy for versjonering.
Det er en rekke utviklingsmetodikk som på ulike måter og med ulike begrunnelser beskriver samarbeid i programutvikling og kodeproduksjon
Medstudenters programmer
I en studiesituasjon er dette en litt vanskelig problemstilling. På den ene siden er det åpenbart at det å dele erfaringer, ideer og programmer er et udiskutabelt gode. Når det gjelder gruppearbeid er situasjonen i prinsipp den samme som kommentert over.
På den andre siden er det vel alle underviseres erfaring at det foregår en del ureflektert kopiering for å bli ferdig med obligatoriske oppgaver innen tidsfristen. Det skjer uavhengig av tilbud om hjelp og veiledning. Det er av og til fristende som underviser ha en kynisk holdning til dette: Vil du ikke lære så er det din egen beslutning. På den annen side er det elementer i oppstart av en programmeringsundervisning som kan virke demotiverende på mange og føre til at arbeidsinnsatsen utesettes. Først og fremst gjelder dette trolig opplevelsen av å gjøre feil, av å mislykkes. Jeg har drøftet feilrettingsperspektivet i en annen artikkel.
Eksempler fra læremateriell
Dette er rimeligvis en god kilde, selv eksempler av og til kan være litt ensidige
Eksempler som er distribuert sammen med det utviklingsystemet vi bruker
Det varierer veldig hvor mye materiell som distribueres eller gjøres tilgjengelig i forbindelse med utviklingssystemer. Noen er eksemplariske gode og har svar på akkurat det vi lurer på. Det som ofte er et problem er at nivået på koden ikke er tilpasset nybegynnere.
Programmer vi finner på nettet
Dette er en interessant problemstilling og det er en del forhold som skiller programmering fra de fleste andre fagområder.
For det første er det en sterk kultur for å dele. Du vil finne forslag og forklaringen av de forunderligste problemer. Det finnes en rekke åpne utviklingsprosjekter der kode i nær sagt alle kompleksitetsgrader er tilgjengelige.
For det andre er det en slags "The truth is in the pudding" situasjon. Vi kan i de fleste tilfeller teste det vi finner og sjekke om det gjør det det gir seg ut for. Vi trenger normalt ikke gjøre systematisk bakgrunnssjekking for å se om noe er "sant". Dette er selvsagt ikke tilfeller der vi er ute etter mer avanserte systemer som f.eks. statistikkprogrammer eller lignende.
Metodisk
Som beskrevet over er kopiering og omskriving av kode en praksis som vi ikke greier oss uten, og etter mitt syn spiller det en avgjørende i rolle i læring. Det er interessant å se om vi kan finne angrepsvinkler der vi kan bruke kodekopiering systematisk i en oppstartfase.
Når det gjelder den grunnleggende forståelsen av syntaks og enkel algoritmeutforming kunne en tenke seg å la studentene få tilgang til kodebiter skrevet i forskjellige språk. Studentenes oppgave blir å forsøke å finne ut hva koden gjør og hva som må endres for å endre funksjonaliteten.
Vi kan illustrere det med et enkelt eksempel. Vi tar for oss en funksjon som skal summere tall fra 1 og opp til en grense. Vi kan se på dette i flere språk.
Java
int tall(int n){
int sum=0;
for(int i=1; i < n; i=i+1)
sum=sum+i;
return sum;
}
print tall(5);
JavaScript
function tall(n){
var sum=0;
for(var i=1; i < n; i=i+1)
sum=sum+i;
return sum
}
console.log(tall(5));
Python
def tall(n):
sum=0
for i in range(1,n):
sum=sum+i
return sum
print tall(5)
Basic
PRINT tall(5);
FUNCTION tall(n)
sum=0
FOR i = 1 TO n-1
sum= sum + i
NEXT i
tall=sum
END FUNCTION
Det vi muligens kunne oppnå med dette er å illustrere noen prinsipper som er allmengyldige og det lar oss betrakte løsningen med litt forskjellige perspektiv. Det gir oss en anledning til å diskutere datatyper og syntaksregler.
Nå vil det være praktisk umulig å sette i gang en paralell prosess der vi inviterer studentene til å eksperimentere med flere utviklingsmiljøer. Den administrative jobben med å holde styr på omgivelsene vil trolig bli lang mer omfattende enn selve kodingen.
Vi kunne tenke oss et scenario der studentene arbeider, f.eks med JavaScript og undervisningen har innslag av kommenterte løsningsforslag i andre språk.
En åpenbar innvending er at dette er en veldig formalistisk angrepsvinkel og det vil neppe fungere som dominerende arbeidsform. Det kunne muligens brukes som et supplement, ikke i den kreative prosessen, men som en måte å få grep om noen syntaktiske og algoritmiske problemstillinger.
Ingen kommentarer :
Legg inn en kommentar
Skrv din kommentar ....