Hvorfor (og hvordan) jeg skriver kode med blyant og papir

Hvis tanken på håndskriftkode virker dum, kan det overraske deg å vite at det er uunngåelig. Hvis du er usikker, tenk på det siste jobbintervjuet du gjorde, og husk hvordan det ikke var noen datamaskin i intervjurommet – bare intervjuerne dine, et blankt ark og en blå kulepenn.

For studentene blant dere er det enda større sak ettersom karakterene dine henger etter kodelinjene du strategisk hadde klemt inn på den tilgjengelige plassen i svararket ditt.

Og ikke bare det, erfarne programmerere kan henvise deg til bunten med A4-ark de hadde fjernet fra kontorets kopimaskin for å skrive ned en spesielt kompleks algoritme de hadde jobbet med.

Så uansett om du er en eksamensstudent, en potensiell jobbintervjuobjekt eller noen som ønsker å løse programmeringens blindveier, håper jeg denne artikkelen hjelper deg når du legger pennen til papiret for å kode.

Selv om jeg vil fokusere på det analoge aspektet ved å skrive kode, kan du bruke disse trinnene til koding i alle former eller språk. Så tenk på at dette også er som en generisk kodingsretningslinje som fungerer spesielt for meg, men som også kan være veldig nyttig for deg i arbeidet ditt.

Hvorfor skrive det ned?

Før vi begynner, er det viktig å forstå at ingen forventer at du noterer produksjonsklar kode i en notatbok. Det er ikke slik at du kan slippe det inn i et koderedigeringsprogram og kompilere det uten feil. Hvis det å produsere perfekt kode var målet, ville du satt deg foran en datamaskin i intervjurommene og eksamenslokalene.

Hensikten med håndskriftkode er å jobbe gjennom logikk på forhånd. Det er et ønske om å "komme inn i nettleseren" så snart som mulig i design, men det er konvensjonell visdom i å skissere design for hånd. Et low-fidelity-medium oppmuntrer til rask eksperimentering og rimelige feil.

Det samme kan være tilfelle med kode, hovedsakelig når man jobber med syntaks og semantikk. Når det er sagt, er det å få riktig syntaks og semantikk alltid et plusspoeng, men ikke det eneste fokuset for hele håndskriftøvelsen.

La oss se hvor vi kan begynne når det gjelder håndskriftkode.

Kjenn spørsmålet ditt

I løpet av mitt siste år på college kunne jeg ikke ta et internship eller til og med delta på campusintervjuer på grunn av helsemessige årsaker. Som et resultat var mitt aller første jobbintervju ganske bokstavelig med høy innsats.

Når jeg ser tilbake nå, var intervjuet ganske enkelt. Men etter å ha aldri deltatt på en før, var jeg engstelig uten grunn. Det første intervjuerne spurte om programmering var om jeg kunne skrive ut en omvendt trekant laget av stjerner. Som jeg sa, det var enkelt - ingenting a for loop kan ikke håndtere, ikke sant? Men som sagt, angsten min var i taket også.

Jeg trakk pusten dypt, presset håndflaten mot det blanke papirarket de hadde lagt ut for meg, skled det så sakte som mulig mot meg på bordet (kjøper tid, selvfølgelig), klikket på pennen, og så gjorde jeg noe Ikke sant.

Jeg tegnet først en omvendt trekant laget av stjerner. Det var slik jeg fant føttene på bakken for å begynne å svare på spørsmålet deres.

Jeg har sett ellers strålende utviklere ta noe galt rett og slett fordi de aldri helt forstår hva det er de løser.

Spørsmålene vi jobber med er ikke som de spørsmålene fysikere eller matematikere løser. De får et sett med parametere og finner de som mangler; våre spørsmål er også våre resultater. Vi er allerede fortalt hva resultatene våre er - vi må finne ut hvordan vi skal nå dem. Det er derfor det er viktig å kjenne spørsmålet godt fordi du vil se resultatet.

Å skrive ned eller tegne ut det du vil skrive ut er en av de beste måtene å starte kodingen på. Jeg forstår at i vår fartsfylte bransje er forventningen at vi må hoppe rett inn i programmeringen ved å kjøre en «hallo verden»-demo. Og det er flott å bli kjent med en ukjent syntaks og riste av deg angsten for å prøve noe nytt.

Men når noen stiller deg et spørsmål og gir deg et resultat å jobbe opp til, ville det ikke bare vært bedre å legge det ned først? Det spørsmålet/resultatet er ikke bare ditt utgangspunkt, men også ditt referansepunkt. På ethvert trinn i kodingen kan du se på den for å sikre at du jobber mot den og at du er på rett spor.

Så enten det er i svararkene dine eller i det tomme A4-papiret du skal skrive inn, start med å ta et sekund og skrive ned hva det er du prøver å skrive ut. Du kan sette det i margen eller et hjørne hvis du ikke vil at det skal være en del av svaret ditt. Bare sørg for at det er et sted du kan fortsette å referere til det.

Skisser koden din

Dette trinnet er som et tveegget sverd. Det kan gi deg et veikart til programmet ditt eller kaste bort tiden din. Min jobb er å sørge for at det er førstnevnte.

Så først og fremst liker jeg å si: Det er unødvendig med skisseringskode hvis omfanget av problemet eller spørsmålet ditt er lite. Igjen, denne praksisen er verken preskriptiv eller universell for alle prosjekter eller situasjoner. Tenk deg at jeg er intervjueren din, og jeg ber deg skrive hvordan du kan sentrere et element på en nettside ved å bruke CSS på så mange måter som mulig. Du trenger ikke akkurat en disposisjon for dette. Kodebitene er relativt små for hver metode.

Men nå, la oss si at jeg gir deg til å skrive en nettapplikasjon som fanger opp brukersignaturer via et berøringsskjermgrensesnitt og deretter lagrer signaturen på serveren. Ikke så enkelt, ikke sant? Du har mer enn én ting å finne ut. Kanskje en liten oversikt kan hjelpe.

1. Brukergrensesnitt for å fange signatur - HTML Canvas? WebGL?
2. Deaktiver pekerhendelser på resten av nettsiden når brukeren signerer
3. Konverter og lagre det fangede bildet til en PNG-fil — JS
4. Deretter konverterer du den til blob (kanskje) og lagrer den i besøkendes loggdatatabell.

Jeg har skrevet en grov sekvens av handlinger som jeg tror jeg kanskje må kode. Den kunne vært kortere eller lengre, avhengig av hva jeg ønsket meg.

Jeg anbefaler på det sterkeste å skissere kode for klientprosjekter. Skriv omrisset sammen med brukerkravene dine eller på baksiden av wireframes du har skrevet ut.

Ditt raske øyeblikksbilde av kulepunkter gir deg et kart, en gjøremålsliste og en sjekkliste du kan verifisere mot når du når slutten av prosjektet – stort sett hele prosjektets sammendrag i en lavtroskapsliste. Det kan også bli en mal for å starte ditt neste lignende prosjekt.

Men som jeg sa før, er dette trinnet som et tveegget sverd. Du må holde dette kort for kandidater og intervjuobjekter når det er tidsbegrensninger.

Hvis du ikke vet hvor du skal begynne, skriv ned bare tre viktige funksjoner du må kode i applikasjonen din, og hvis du har tid, gjør det til fem.

Men det er omtrent det. Bruk så lite tid som mulig på dette, og ikke svett over detaljene. Oversikten kommer ikke til å gi deg ekstra poeng. Den er der bare for å hjelpe deg med å sikre at du har alt dekket. Den fanger opp din første tarmreaksjon og holder deg ærlig gjennom hele prosjektets liv.

Longhand vs. stenografi

På tide å begynne å kode. Så, hva skriver du? "Bdrs" eller "border-radius"; "div -> p"Eller"<div><p></div></p>"; "pl()"Eller"println()"; "q()"Eller"querySelector()"?

Hvis noen andre graderer koden din, er det ikke noe valg. Utelat forkortelser, pseudokoder, Emmet-snarveier og enhver annen form for stenografi. Ellers er det ingen grunn til å anta at alle som leser dette vet hva forkortelsene dine betyr.

Det er egentlig opp til deg.

Hvis du har mistet kontakten med å skrive for hånd - og mange av oss har gjort det - er det bedre å ikke gå over bord med langhåndsnotasjonene, da de blir kjedelige. Samtidig er det ikke noe slikt som å være for sparsommelig med skrivingen din. Ikke hvis du vil kunne se tilbake på det en dag og forstå hva du har skrevet ned.

Jeg har en åpen fil i notatappen min og en notisblokk med strek på skrivebordet der jeg skriver ned kodebiter jeg vil lagre for senere referanse. De er uorganiserte, bare en lang strøm av utdrag. Det er derfor når jeg blar gjennom eldre notater, ville jeg ikke vite hva jeg mente å skrive hvis jeg ikke hadde skrevet dem tydelig ned.

Jeg glemmer syntakser hele tiden. For eksempel har jeg brukt pilnotasjonen for JavaScript-funksjoner siden den ble introdusert (fordi den er kortere), og jeg er ganske sikker på at hvis noen plutselig ber meg om å definere en funksjon ved å bruke function nøkkelord, kan jeg til og med feilplassere parentesene eller funksjonsnavnet, noe som forårsaker en syntaksfeil.

Det er ikke uvanlig at vi glemmer syntakser vi ikke har brukt på en stund. Derfor er det bedre å skrive notatene tydelig når du vet at du trenger dem for fremtidig referanse.

Den ikke-sekvensielle flyten av kode

I motsetning til det siste trinnet, som ikke gjelder for de av dere intervjuobjekter og testtakere, er dette spesielt tilrettelagt for deg.

De fleste programmeringsspråk tolkes, kompileres og kjøres slik at noen ganger forhåndsskrevet kode i kilden blir utført senere når den kalles. Vi gjør det i JavaScript, for eksempel med funksjonskall - funksjoner kan defineres i utgangspunktet, og deretter utføres senere. Undersøkte og intervjuobjekter kan bruke dette til å begynne å jobbe med det kritiske punktet i svaret ditt først.

Som jeg har sagt helt fra begynnelsen, er hensikten med håndskriftkode å jobbe gjennom eller teste logikken til hva det enn er du programmerer. Det er best når du fokuserer på å løse det først.

La oss ta et klassisk lærebokeksempel - et program for å finne den n'te Fibonacci-nummer. Hvis jeg skulle skrive en enkel disposisjon for det, ville det vært noe slikt:

1. Få innspillet.
2. Regn ut Fibonacci-tallet.
3. Oppsummer resultatet.
4. Skriv ut utskriften.

Alle trinnene i den disposisjonen er essensielle; 1, 3 og 4 er imidlertid mer obligatoriske. De er nødvendige, men ikke viktige nok til å fokusere på med en gang.

Det er bedre å begynne å skrive ned koden for å beregne Fibonacci-tallet i stedet for å hente inndataene. Pakk den inn i en funksjon, fortsett og skriv koden sekvensielt og skriv ned en linje for å kalle den funksjonen der det er aktuelt.

Bruk tiden din på å skrive kode som fokuserer på problemets kjerne.

Ekte fagfolk kan hoppe foran. La oss si at jeg har et klientprosjekt, og jeg må jobbe med litt trekantgeometri - har to sider, motsatt vinkel, og må finne lengden på den tredje siden. Og jeg har bestemt meg for å skrive på papir for å komme i gang i stedet for å åpne min IDE.

Først ville jeg tegne trekanten, selvfølgelig (det er noe jeg er veldig erfaren med, som du skjønner). Jeg ville skrevet ned noen prøvelengder og vinkler. Så ville jeg skrevet formelen (komplimenter for nettsøk, helt sikkert), og så hoppet jeg rett til koden for funksjonen.

Det nytter ikke å skrive ned de obligatoriske trinnene selv om jeg trenger dem i produksjonsklar kode. Men det ville vært annerledes om jeg måtte skrive det på et svarark på en eksamen. Jeg kan ikke hoppe over de andre trinnene; Jeg kan imidlertid fortsatt starte med koden for formelen.

Pseudokode

Chris har allerede skrevet en nyttig artikkel om pseudo-kode at jeg anbefaler deg å gi en solid lesning.

For alle de profesjonelle som føler at hele håndskriftskoden ikke virker som din kopp te, men som likevel er nysgjerrige på om det kan hjelpe deg, da pseudokode kan være balansen du leter etter.

Det ligner på å skissere koden, som jeg nevnte i et av de foregående trinnene. Imidlertid er det kortere og føles mer som stenografikoding. Det blir noen ganger også referert til som "skjelettkode."

Her er litt rask pseudo-kode for et CSS-rutenettoppsett:

Grid
5 60px rows
6 100px columns

Det er ikke mye å skrive! Så selv om å sette en blyant på papir er utmerket for denne typen ting, er det like effektivt, raskt og rimelig å skrive litt pseudokode inn i hvilket program du bruker.

Plass og kommentarer

Jeg tror kode er 90 % søkeord og 10 % faner. Uten mellomrom minker ordlesbarheten. Innrykk er også nødvendig for håndskrevet kode. Ikke bruk den for alle nivåer fordi bredden på papiret vil begrense deg. Bruk mellomrom med omtanke, men bruk dem.

Hvis du skriver kode for ditt bruk, tror jeg også at hvis du har fulgt alt jeg har nevnt så langt og allerede har skrevet ned utdataene dine og en disposisjon på siden, trenger du kanskje ikke engang å inkludere kommentarer. Kommentarer forteller deg raskt hva det følgende settet med kode gjør. Hvis du allerede har skrevet og lest en disposisjon for koden, er kommentarer overflødige notater.

Men hvis dommen din sier at du skal legge fra deg en, så gjør det. Legg den til på høyre side av koden (siden du ikke vil kunne sette den inn mellom allerede skrevne linjer slik du kunne i for eksempel VS-kode). Bruk skråstreker, parenteser eller piler for å angi at de er kommentarer.

For kandidater som er usikker på en viss syntaks, skriv ned kommentarer. På denne måten lar du i det minste personen som vurderer oppgaven din vite at du har tenkt med den feilformaterte koden. Og bruk bare de riktige skilletegnene for å angi kommentarer - for eksempel vil det være skråstrekene for JavaScript.

Analog vs digital

Som jeg nevnte tidligere, er alt jeg gir her generiske kodingsråd. Hvis du ikke vil prøve dette med fysisk papir, fungerer også ethvert notatprogram.

Men hvis du skal prøve den digitale ruten, er min anbefaling å prøve å bruke noe annet enn en rett notatapp. Arbeid med flere visuelle digitale verktøy – flytdiagrammer, tankekart, wireframes osv. De kan hjelpe deg med å visualisere resultatet, konturene og selve koden.

Jeg er ikke mye av en digital borger (bortsett fra å jobbe på nettet og nylig konverterte til å lese e-bøker), så jeg holder meg til fysiske notatbøker.

Mine favorittverktøy for håndskriftkode

Enhver blyant og papir vil duge! Men det er mange alternativer der ute, og dette er noen valgverktøy jeg bruker:

Det er ingen "skrive" måte å kode på

Jeg håper, om ikke annet, at min lille måte å håndskrive kode med blyant og papir på får deg til å evaluere måten du allerede planlegger og skriver kode på. Jeg liker å vite hvordan andre utviklere nærmer seg arbeidet deres, og dette er min måte å gi deg et innblikk i måten jeg gjør ting på.

Igjen, ingenting her er vitenskapelig eller en eksakt kunst. Men hvis du vil prøve håndskreven kodeplanlegging, her er alt vi har dekket i en fin ordnet liste:

1. Start med å skrive ned (med eksempeldata, om nødvendig) utdataene til koden din.
2. Skriv en disposisjon for koden. Vennligst hold det til tre trinn for små prosjekter eller de som er mindre komplekse.
3. Bruk langhåndsnotasjoner. Utviklere som skriver for seg selv kan bruke stenografinotasjoner så lenge skriften er lesbar og gir mening for deg når du refererer til den senere.
4. Når du har en tidsbegrensning, bør du vurdere å skrive koden som tar tak i kjernen av problemet først. Skriv ned et anrop til den koden på rett sted i den sekvensielle koden din senere.
5. Hvis du føler deg trygg, prøv å skrive pseudokode som adresserer hovedideen.
6. Bruk riktige fordypninger og mellomrom – og vær oppmerksom på papirets bredde.

Det er det! Når du er klar til å prøve å skrive kode for hånd, håper jeg denne artikkelen gjør det enkelt for deg å komme i gang. Og hvis du skal sette deg ned for en eksamen eller et intervju, håper jeg dette hjelper deg med å fokusere på å få spørsmålene riktige.