Kopier og indsæt ikke kode. Skriv det ud. ?

At skrive kode kan hjælpe dig med at udvikle en læringstankegang

Vil du bryde noget kode? Skift det rigtigt hurtigt, før du overhovedet forstår, hvad det gør.

Nu praktiserer du Cargo Cult-programmering - en stil med softwareudvikling, hvor du ignorerer, hvordan et stykke kode fungerer, og dets forhold til koden omkring det.

Udtrykket fragtkult-programmerer kan anvendes, når en computerprogrammerer, der er uerfaren med det aktuelle problem, kopierer en eller anden kode fra et sted til et andet med ringe eller ingen forståelse for, hvordan det fungerer, eller om det kræves i sin nye position.

- Carg Cult programmering på Wikipedia

Når en udvikler kopierer et stykke kode, som de ikke forstår, og bruger det i håb om at løse et problem, praktiserer de Cargo Cult-programmering. Dette øger risikoen for utilsigtede bivirkninger.

Når en udvikler læser et stykke kode, som de ikke forstår og stadig ændrer det i håb om at løse et problem, praktiserer de også Cargo Cult-programmering.

Problemet er i dette tilfælde ikke, at udvikleren kopierer noget. Alle kan kopiere et kodestykke, forstå det, lære af det, bruge det og stadig have en lavere risiko for utilsigtede bivirkninger.

Cargo Cult-programmering repræsenterer på den anden side en grundlæggende misforståelse af dokumenterede trin til at lære af andres kode.

Her er den mest effektive måde at lære i denne sammenhæng på:

  1. Læs et stykke kode.
  2. Forstå alle funktionerne i det sprog, der bruges der.
  3. Forstå alle funktionerne i de biblioteker / rammer, der bruges der.
  4. Lær det grundlæggende i disse biblioteker / rammer.
  5. Forstå hvad hver linje gør, og formålet med disse biblioteker / rammer i sammenhæng med det stykke kode.

For en person, der begynder at arbejde med et nyt sprog, bliver dette ekstremt svært. Mængden af ​​information, et menneske har brug for at beholde for effektivt at forstå selv et lille kodestykke, er så stort, at det måske bliver glemt med det samme. Hvad vi kan gøre er at udnytte visse aspekter af, hvordan den menneskelige hjerne er vant til at lære ting - bevidst eller ubevidst - med nogle dokumenterede teknikker.

En af disse teknikker er blokeret praksis. Det er dybest set hvor du lærer ved "at udføre en enkelt færdighed igen og igen, hvor gentagelse er nøglen."

Dette er dog ikke den bedste måde at lære på. Det er bevist, at når du lærer gennem sammenfletning af forskellige variationer af samme færdighed, lærer du mere effektivt.

I softwareteknik kan vi udnytte både blokerede og sammenflettede læringspraksis, når vi skriver koden i forskellige sammenhænge i stedet for bare at kopiere og indsætte den.

Når du kopierer uddrag, læser vi bare (hvis vi engang gider at gøre det). Og ifølge forholdet mellem erfaringskeglen lærer vi måske kun en lille del af den information, vi bruger, fordi den er for abstrakt.

Kontraster dette med at lære bedre ved faktisk at skrive det stykke kode ud. Dette er en mere direkte og målrettet oplevelse. Det tvinger din hjerne til at forstå alle disse forskellige mønstre og lære mere effektivt.

At skrive kode i stedet for at kopiere og indsætte det giver et bedre lærings-ROI, fordi vi øver i stedet for bare at læse.

At navngive ting betragtes som et af de sværeste aspekter ved programmering. Når vi kopierer kode uden at forstå det, risikerer vi at bryde noget ved at overskrive variabelnavne, funktionsnavne eller klasser.

Hvis vi i stedet forstår koden først, så indtast den med vores egne ord, kan vi omdøbe tingene på en måde, der passer til vores app og sikrer, at vi ikke har nogen navngivningskollisioner, selvom det endelige resultat er funktionelt det samme som stykke kode, vi baserer på.

Udover det, hvis vi kopierer koden fra et sted i vores kodebase til et andet, er der en chance for, at vi kopierer tokens, der er unødvendige eller glemmer at ændre tokens, der skulle have været ændret.

Tag for eksempel følgende HTML-uddrag:

Når duplikere denne kode til at oprette en ny indgang, er vi tilbøjelige til at glemme at ændre for attribut af etiketten element, som vil bryde den tilsigtede adfærd for nye input.

Dette eksempel er interessant, fordi det er den slags funktionalitet, der er vanskelig at teste, selv med visuel regression. Det afhænger stærkt af statisk test - som en kodegennemgang - for at sikre, at koden blev skrevet til det tilsigtede formål. (I dette tilfælde skal propagere musebegivenheder til input for det samme id for etiketten til attribut.)

Det samme sker med test. Når vi kopierer en allerede bestået test i stedet for at oprette en ny fra bunden, risikerer vi ikke at ændre de nødvendige tokens, der ellers ville få denne test til at mislykkes.

I dette tilfælde kan vi dog forhindre denne fejl ved at bruge Test Driven Development - en tankegang baseret på oprettelse af en fejlagtig test først, og derefter ændre applikationskoden for at få den til at bestå. Denne tankegang giver os mulighed for at være sikre på, at vi er mindre tilbøjelige til at gå glip af noget eller skabe falske positive.

I stedet for at kopiere kode uden at forstå den, kan du lære af andres kode og øve dig oven på den. Dette maksimerer dit lærings-ROI.

Når alt kommer til alt er den mest værdifulde ressource hos en udvikler hjernen - ikke fingrene.

Tak for læsningen. Hvis du har feedback, så kontakt mig på Twitter, Facebook eller Github.