De vigtigste søjler i programmering af læring - og hvorfor begyndere skal mestre dem.

Jeg har programmeret i mere end 20 år. I løbet af denne tid har jeg haft fornøjelsen at arbejde med mange mennesker, som jeg lærte meget af. Jeg har også arbejdet med mange studerende, der kommer frisk fra universitetet, med hvem jeg var nødt til at påtage mig rollen som lærer eller mentor.

I det seneste har jeg været involveret som træner i et program, der lærer kodning til absolutte begyndere.

Det er svært at lære at programmere. Jeg finder ofte, at universitetskurser og bootcamps går glip af vigtige aspekter af programmering og tager dårlige tilgange til undervisning af rookies.

Jeg vil dele de fem grundlæggende søjler, som jeg mener, at et vellykket programmeringskursus skal bygge på. Som altid adresserer jeg konteksten for almindelige webapplikationer.

En rookies mål er at mestre programmeringsgrundlaget og forstå vigtigheden af ​​biblioteker og rammer.

Avancerede emner som skyen, operationer generelt eller buildværktøjer bør ikke være en del af læseplanen. Jeg er også skeptisk, når det kommer til designmønstre. De antager oplevelse, som begyndere aldrig har.

Så lad os se på, hvor nye programmører skal starte.

Test-Driven Development (TDD)

TDD giver mange fordele. Desværre er det et avanceret emne, som begyndere ikke er helt klar til.

Begyndere bør ikke skrive prøver. Dette ville være for meget for deres grundlæggende færdighedsniveauer. I stedet bør de lære at bruge og arbejde med test.

Hvert programmeringskursus skal centrere omkring øvelser. Jeg udvider mine øvelser med enhedstest og giver de studerende et miljø, der allerede er konfigureret til at køre disse tests.

Alt, hvad de studerende skal gøre, er at skrive deres kode og derefter se testrunnerens lys blive rødt til grønt. Den resulterende gamification er en god bivirkning.

For eksempel: Hvis den valgte teknologi er Spring, giver jeg øvelserne og testene inden for et Spring-projekt. Studerende behøver ikke at vide noget om foråret. Alt, hvad de har brug for at vide, er placeringen af ​​øvelserne og knappen til at udløse testene.

Derudover skal eleverne vide, hvordan man bruger en debugger og har en Read-Eval-Print Loop (REPL) praktisk. Evnen til at analysere kode under kørsel og have en legeplads til små eksperimenter er vigtig i TDD.

Hovedpointen er at sikre, at studerende ikke behøver at lære grundlæggende TDD-adfærd, efter at de har tilegnet sig grundlæggende programmeringsfærdigheder. Ændring af vaner senere i de studerendes karriere vil være meget sværere end at lære disse vaner nu. Derfor skal de leve og ånde test af enheder fra starten.

Senere i deres professionelle liv skulle de have en antipati for projekter uden enhedstest. De bør intuitivt se fraværet af enhedstest som antimønster.

Grundlæggende først

Jeg hører meget ofte, at rookies straks skal starte med en ramme. Dette er som at lære folk at køre ved at placere dem i en rallybil og bede dem om at undgå overstyring. Dette ignorerer simpelthen det faktum, at de stadig fejler bremsen for gashåndtaget.

Det samme gælder, når vi starter studerende med en ramme som Angular. Begyndere skal først forstå det grundlæggende ved programmering. De skal være fortrolige med de grundlæggende elementer og hvad det betyder at skrive kode, før de kan bruge en andens.

Konceptet med en funktion, en variabel, en betingelse og en sløjfe er helt fremmed for nybegyndere. Disse fire elementer bygger grundlaget for programmering. Alt, hvad et program er lavet af, er afhængig af dem.

Studerende hører disse begreber for første gang, men det er yderst vigtigt, at de studerende bliver dygtige med dem. Hvis eleverne ikke behersker det grundlæggende, ser alt, der følger, ud som magi og fører til forvirring og frustration.

Lærere bør bruge mere tid på disse grundlæggende. Men desværre går mange alt for hurtigt. Problemet er, at nogle lærere kæmper for at sætte sig ind i rollen som studerende. De har programmeret i årevis og har glemt, hvilke typer problemer en nybegynder skal håndtere. Det ligner en professionel rallydriver. Han kan ikke forestille sig, at nogen skal tænke, før de bremser. Han gør det bare automatisk.

Jeg designer mine øvelser, så de er udfordrende, men kan løses på en rimelig tid ved at bruge en kombination af de fire hovedelementer.

Et godt eksempel er en konverter til romerske og arabiske tal. Denne udfordring kræver tålmodighed fra de studerende. Når de med succes anvender de fire elementer til at løse udfordringen, får de også et stort boost i motivation.

Grundlæggende er vigtige. Gå ikke videre, før de er afgjort.

Biblioteker og rammer

Når eleverne bruger meget tid på kodning, skal de lære, at de fleste koder allerede findes i form af et bibliotek eller en ramme. Dette er mere en tankegang end et mønster.

Som jeg har skrevet før: Moderne udviklere kender og vælger det rigtige bibliotek. De bruger ikke timer på at skrive en buggy-version alene.

For at gøre denne tankegangsovergang til en succes, bør eksemplerne fra "grundlæggende fase" kunne løses ved hjælp af velkendte biblioteker som Moment.js, Jackson, Lodash eller Apache Commons.

På denne måde vil eleverne straks forstå værdien af ​​biblioteker. De knuste hovedet omkring disse komplicerede problemer. Nu opdager de, at et bibliotek løser øvelsen på ingen tid.

I lighed med TDD skal studerende blive mistænksomme, når kolleger skryter af deres selvfremstillede statsstyringsbibliotek, der gør Redux unødvendig.

Når det kommer til rammer, har eleverne ikke noget problem med at forstå vigtigheden, når de først forstår nytten af ​​biblioteker.

Afhængigt af kursets tidsramme kan det være svært at bruge tid på rammer. Men som jeg allerede påpegede, er det vigtigste aspekt at flytte den studerendes tankegang væk fra at programmere alt fra bunden til at udforske og bruge biblioteker.

Jeg tilføjede ikke værktøjer til denne søjle, da de kun er til brug for erfarne udviklere. På dette tidlige tidspunkt behøver eleverne ikke at lære at integrere og konfigurere værktøjer.

Master & lærling

I mine tidlige 20'ere ville jeg lære at spille klaver. Jeg ville ikke have en lærer og troede, at jeg selv kunne lære det. Fem år senere konsulterede jeg en professionel vejleder. Hvad kan jeg sige? Jeg har lært mere på 1 måned end i de fem år før.

Min klaverlærer påpegede fejl i mit spil, jeg ikke kunne høre, og gjorde mig opmærksom på fortolknings ting, som jeg aldrig ville have forestillet mig. Efter alt indpodede hun mig tankegangen for musik og kunst, som begge var uden for rækkevidde for mig som teknisk person.

Det er det samme ved programmering. Hvis nogen ikke har nogen erfaring med programmering, kan selvstudium være en dårlig idé. Selvom der er mange succeshistorier, sætter jeg spørgsmålstegn ved effektiviteten ved at gøre det alene.

I stedet skal der være et "master & lærling" forhold. I begyndelsen giver mesteren regler, som lærlingen skal følge - blindt! Skibsføreren kan forklare reglerne, men ræsonnementet ligger normalt uden for lærlingens forståelse.

Disse internaliserede regler udgør en slags sikkerhedsnet. Hvis man går tabt, har man altid et sikkert sted at vende tilbage til.

Undervisning bør ikke være en monolog. Mesteren skal håndtere hver enkelt studerende individuelt. Han bør kontrollere, hvordan de studerende arbejder, give råd og tilpasse kursets hastighed til deres fremskridt.

Når lærlingene når et vist niveau af mestring, bør de opfordres til at udforske nyt territorium. Mesteren udvikler sig til en mentor, der deler "visdom" og er åben for diskussioner.

Udfordring og motivation

"Lad os oprette en Facebook-klon!" Dette kommer ikke fra en CEO understøttet af en horde af senior softwareudviklere og et budget på flere millioner euro. Det er en øvelse fra et introduktionskursus for programmører. En sådan forpligtelse er næsten umulig. Endnu værre er, at studerende sættes i vidunderland og bedrages til at tro, at de har færdigheder, der virkelig er uden for deres rækkevidde.

Uden tvivl er læreren opmærksom på det, men opretter sådanne øvelser af motiverende årsager.

Hovedmålet med en øvelse er ikke at underholde. Den skal oprettes omkring en bestemt teknik og skal hjælpe de studerende til at forstå denne teknik.

Motivation er god, men ikke ved ofring af indhold. Programmering er ikke let. Hvis eleverne ikke har en iboende motivation, er kodning muligvis ikke vejen at gå.

Nybegyndere skal opleve, hvad det betyder at være en professionel udvikler. De burde vide, hvad der venter dem, før de investerer mange timer.

For eksempel er mange forretningsapplikationer centreret omkring komplekse formularer og net. At skabe disse er en vigtig færdighed, som øvelser kan give. At opbygge en applikation svarende til Facebook er måske ikke den bedste lektion for studerende at lære med det samme.

Tilsvarende kan en ikke-programmør måske blive overrasket over, hvor få kodelinjer en udvikler skriver om dagen. Der er endda tidspunkter, hvor vi fjerner kode eller opnår intet.

Hvorfor? Fordi tingene går galt hele tiden. Vi bruger uendelige timer på at rette nogle ekstremt mærkelige fejl, der viser sig at være en simpel skrivefejl. Noget værktøj fungerer muligvis ikke bare fordi et bibliotek fik en mindre versionopgradering. Eller systemet går ned, fordi nogen glemte at tilføje en fil til git. Listen kan fortsætte og fortsætte.

Studerende bør nyde disse oplevelser. En øvelse målrettet mod et ukendt bibliotek under tidspres kan være nøjagtigt den rigtige ting. ;)

Solen skinner ikke altid i det virkelige liv. Begyndere skal være godt forberedt på realiteten af ​​programmering.

Endelig rådgivning

Sidst men ikke mindst: Man kan ikke blive en professionel programmør på to uger, to måneder eller endda et år. Det tager tid og tålmodighed.

Trænere bør ikke skynde sig eller afgive falske løfter. De skal fokusere på, om eleverne forstår begreberne og ikke gå videre for hurtigt.

Oprindeligt offentliggjort på www.rainerhahnekamp.com den 10. juni 2018.