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

Hvis tanken om håndskriftskode virker dum, kan det overraske dig at vide, at det er uundgåeligt. Hvis du er usikker, så tænk på den sidste jobsamtale, du lavede, og husk, hvordan der ikke var nogen computer i interviewrummet - kun dine interviewere, et blankt ark papir og en blå kuglepen.

For eleverne blandt jer er det endnu en større sag, da dine karakterer hænger fast ved de kodelinjer, du strategisk havde presset ind på den ledige plads i dit svarark.

Og ikke bare det, erfarne programmører kan henvise dig til det bundt af A4-ark, de havde fjernet fra kontorets kopimaskine, for at nedskrive en særlig kompleks algoritme, de havde arbejdet på.

Så uanset om du er en eksamensstuderende, en potentiel jobinterviewet eller en person, der ønsker at løse deres programmerings blindgyder, håber jeg, at denne artikel hjælper dig, når du lægger pennen til papiret for at kode.

Selvom jeg vil fokusere på det analoge aspekt ved at skrive kode, kan du anvende disse trin til kodning i enhver form eller sprog. Så anser dette for også at være som en generisk kodningsvejledning, der fungerer specifikt for mig, men som også kan være meget nyttig for dig i dit arbejde.

Hvorfor skrive det ned?

Før vi starter, er det vigtigt at forstå, at ingen forventer, at du noterer produktionsklar kode ned i en notesbog. Det er ikke sådan, at du kan slippe det ind i en kodeeditor og kompilere det uden fejl. Hvis det var målet at producere perfekt kode, ville du sidde foran en computer i interviewlokalerne og eksamenslokalerne.

Formålet med håndskriftskode er at gennemarbejde logikken på forhånd. Der er et ønske om at "komme ind i browseren" så hurtigt som muligt i design, men der er konventionel visdom i at tegne designs i hånden. Et low-fidelity-medium tilskynder til hurtige eksperimenter og billige fejl.

Det samme kan være tilfældet med kode, hovedsageligt når man arbejder med syntaks og semantik. Når det er sagt, er det at få den korrekte syntaks og semantik altid et pluspunkt, dog ikke det eneste fokus for hele håndskriftsøvelsen.

Lad os se, hvor vi kan starte, når det kommer til håndskriftskode.

Kend dit spørgsmål

I løbet af mit sidste år på college kunne jeg ikke komme i praktik eller endda deltage i campussamtaler på grund af helbredsmæssige årsager. Som følge heraf var min allerførste jobsamtale ganske bogstavelig med høje indsatser.

Når jeg ser tilbage nu, var interviewet ret nemt. Men efter at have aldrig deltaget i en før, var jeg ængstelig uden fornuft. Det første, interviewerne spurgte om programmering, var, om jeg kunne udskrive en omvendt trekant lavet af stjerner. Som jeg sagde, det var nemt - intet a for loop kan ikke klare, vel? Men som sagt, min angst var også gennem taget.

Jeg tog en dyb indånding, pressede min håndflade mod det tomme ark papir, de havde lagt ud til mig, sled det så langsomt som muligt mod mig på bordet (køber tid, selvfølgelig), klikkede på pennen, og så gjorde jeg noget ret.

Jeg tegnede først en omvendt trekant lavet af stjerner. Det var sådan, jeg fandt mine fødder på jorden for at begynde at besvare deres spørgsmål.

Jeg har set ellers geniale udviklere tage noget galt, simpelthen fordi de aldrig helt forstår, hvad det er, de løser.

De spørgsmål, vi arbejder med, er ikke som de spørgsmål, fysikere eller matematikere løser. De får et sæt parametre og finder de manglende; vores spørgsmål er også vores resultater. Vi er allerede fortalt, hvad vores resultater er - vi er nødt til at finde ud af, hvordan vi når dem. Derfor er det bydende nødvendigt at kende spørgsmålet godt, fordi du vil se resultatet.

At skrive ned eller tegne det, du vil udskrive, er en af ​​de bedste måder at starte din kodning på. Jeg forstår, at i vores hurtige branche er forventningen, at vi skal springe direkte ind i programmeringen ved at køre en "hej verden"-demo. Og det er dejligt at sætte sig ind i en ukendt syntaks og ryste af sig angsten for at prøve noget nyt.

Men når nogen stiller dig et spørgsmål og giver dig et resultat at arbejde op til, ville det så ikke bare være bedre at lægge det fra sig først? Det spørgsmål/resultat er ikke kun dit udgangspunkt, men også dit referencepunkt. På ethvert trin i din kodning kan du se på det for at sikre, at du arbejder hen imod det, og at du er på rette vej.

Så uanset om det er i dine svarark eller i det tomme A4-papir, du er ved at skrive i, start med at tage et øjeblik og skrive ned, hvad det er, du prøver at udskrive. Du kan sætte det i margenen eller et hjørne, hvis du ikke ønsker, at det skal være en del af dit svar. Bare sørg for, at det er et sted, hvor du kan blive ved med at henvise til det.

Skitsér din kode

Dette trin er som et tveægget sværd. Det kan give dig en køreplan til dit program eller spilde din tid. Min opgave er at sikre, at det er førstnævnte.

Så først og fremmest vil jeg gerne sige: skitserende kode er unødvendig, hvis omfanget af dit problem eller spørgsmål er lille. Igen er denne praksis hverken præskriptiv eller universel for alle projekter eller situationer. Forestil dig, at jeg er din interviewer, og jeg beder dig skrive, hvordan du centrerer et element på en webside ved hjælp af CSS på så mange måder som muligt. Du behøver ikke ligefrem en oversigt for dette. Kodestykkerne er relativt små for hver metode.

Men lad os nu sige, at jeg tildeler dig at skrive en webapplikation, der fanger brugersignaturer via en touchscreen-grænseflade og derefter gemmer signaturen på serveren. Ikke så ligetil, vel? Du har mere end én ting at finde ud af. Måske kan en lille oversigt hjælpe.

1. Brugergrænseflade til at fange signatur — HTML Canvas? WebGL?
2. Deaktiver markørhændelser på resten af ​​websiden, når brugeren signerer
3. Konverter og gem det optagne billede til en PNG-fil — JS
4. Konverter det derefter til blob (måske) og gem det i den besøgendes logdatatabel.

Jeg har skrevet en grov sekvens af handlinger, som jeg tror, ​​jeg måske skal kode. Den kunne have været kortere eller længere, alt efter hvad jeg ville have ud af den.

Jeg anbefaler stærkt at skitsere kode for klientprojekter. Skriv omridset sammen med dine brugerkrav eller på bagsiden af ​​wireframes, du har printet ud.

Dit hurtige øjebliksbillede af punktopstillinger giver dig et kort, en opgaveliste og en tjekliste, du kan verificere i forhold til, når du når slutningen af ​​projektet - stort set hele dit projekts resumé i en low-fidelity-liste. Det kan også blive en skabelon til at starte dit næste lignende projekt.

Men som jeg sagde før, er dette trin som et tveægget sværd. Du bliver nødt til at holde dette kort for eksaminander og interviewpersoner, når der er tidsbegrænsninger.

Hvis du ikke ved, hvor du skal starte, så skriv blot tre vigtige funktioner ned, som du skal kode i din applikation, og hvis du har tid, så gør det til fem.

Men det handler om det. Brug så lidt tid som muligt på dette, og lad være med at svede over detaljerne. Oplægget vil ikke give dig ekstra point. Det er der kun for at hjælpe dig med at sikre, at du har alt dækket. Det fanger din første tarmreaktion og holder dig ærlig gennem hele projektets liv.

Longhand vs. stenografi

Tid til at begynde at kode. Så hvad skriver du? "Bdrs" eller "border-radius"; "div -> p"Eller"<div><p></div></p>"; "pl()"Eller"println()"; "q()"Eller"querySelector()"?

Hvis en anden bedømmer din kode, så er der ikke noget valg. Udelad forkortelser, pseudo-koder, Emmet-genveje og enhver anden form for stenografi. Ellers er der ingen grund til at antage, at nogen, der læser dette, ved, hvad dine forkortelser betyder.

Det er virkelig op til dig.

Hvis du er kommet ud af kontakten med at skrive i hånden - og mange af os har - er det bedre ikke at gå overbord med langhåndsnotationerne, da de bliver kedelige. Samtidig er der ikke noget, der hedder at være for sparsommelig med dit forfatterskab. Ikke hvis du vil være i stand til at se tilbage på det en dag og forstå, hvad du har skrevet ned.

Jeg har en åben fil i min note-app og en foret notesblok på mit skrivebord, hvor jeg skriver kodestykker ned, jeg vil gemme til senere reference. De er uorganiserede, bare en lang strøm af uddrag. Det er derfor, når jeg gennemser ældre noter, ville jeg ikke vide, hvad jeg mente at skrive, hvis jeg ikke havde skrevet dem tydeligt ned.

Jeg glemmer syntakser hele tiden. For eksempel har jeg brugt pilenotationen til JavaScript-funktioner, siden den blev introduceret (fordi den er kortere), og jeg er ret sikker på, hvis nogen pludselig beder mig om at definere en funktion ved hjælp af function nøgleord, kan jeg endda forlægge parenteserne eller funktionsnavnet, hvilket inciterer en syntaksfejl.

Det er ikke usædvanligt for os at glemme syntakser, vi ikke har brugt i et stykke tid. Derfor er det bedre at skrive dine noter tydeligt, når du ved, at du har brug for dem til fremtidig reference.

Det ikke-sekventielle flow af kode

I modsætning til det sidste trin, som ikke gælder for de af jer interviewpersoner og testpersoner, er dette trin specielt henvendt til dig.

De fleste programmeringssprog fortolkes, kompileres og udføres, så nogle gange forskrevet kode i kilden udføres senere, når de kaldes. Vi gør det i JavaScript, for eksempel med funktionskald - funktioner kan defineres indledningsvis og derefter udføres senere. Undersøgte og interviewpersoner kan bruge dette til at begynde at arbejde med det kritiske punkt i dit svar først.

Som jeg har sagt helt fra begyndelsen, er formålet med håndskriftskode at gennemarbejde eller teste logikken i, hvad end det er, du programmerer. Det er bedst, når du fokuserer på at løse det først.

Lad os tage et klassisk lærebogseksempel - et program til at finde den n'te Fibonacci nummer. Hvis jeg skulle skrive et simpelt oplæg til det, ville det være sådan her:

1. Få input.
2. Beregn Fibonacci-tallet.
3. Opsummer outputtet.
4. Udskriv output.

Alle trinene i den oversigt er væsentlige; dog er 1, 3 og 4 mere obligatoriske. De er nødvendige, men ikke vigtige nok til at fokusere på med det samme.

Det er bedre at begynde at skrive koden ned for at beregne Fibonacci-tallet i stedet for at hente inputtet. Pak den ind i en funktion, og skriv derefter koden sekventielt og skriv en linje ned for at kalde den funktion, hvor det er relevant.

Brug din tid på at skrive kode, der fokuserer på problemets kerne.

Rigtige professionelle kan springe videre. Lad os sige, at jeg har et klientprojekt, og jeg skal arbejde med noget trekantgeometri - jeg har to sider, modsat vinkel og skal finde længden på den tredje side. Og jeg har besluttet at skrive på papir for at komme i gang i stedet for at åbne min IDE.

Først ville jeg selvfølgelig tegne trekanten (det er noget, jeg er meget erfaren med, som du kan se). Jeg ville skrive nogle prøvelængder og vinkler ned. Så ville jeg skrive formlen (komplimenter til onlinesøgning, helt sikkert), og så ville jeg hoppe direkte til koden til funktionen.

Det nytter ikke, at jeg skriver de obligatoriske trin ned, selvom jeg skal bruge dem i produktionsklar kode. Men det ville være anderledes, hvis jeg skulle skrive det på et svarark til en eksamen. Jeg kan ikke springe de andre trin over; jeg kan dog stadig starte med koden til formlen.

Pseudo-kode

Chris har allerede skrevet en praktisk artikel om pseudo-kode at jeg stærkt anbefaler dig at læse solidt.

Til alle de fagfolk, der har lyst til, at hele håndskriftskoden ikke virker som din kop te, men som alligevel kunne være nysgerrige om det kan hjælpe dig, så pseudokode kan være den balance, du leder efter.

Det svarer til at skitsere koden, som jeg nævnte i et af de foregående trin. Det er dog kortere og føles mere som stenografikodning. Det bliver nogle gange også omtalt som "skeletkode."

Her er lidt hurtig pseudo-kode til et CSS-gitterlayout:

Grid
5 60px rows
6 100px columns

Der er ikke meget at skrive! Så selvom at sætte en blyant på papir er fremragende til denne slags ting, er det lige så effektivt, hurtigt og billigt at skrive noget pseudokode ind i det program, du bruger.

Plads og kommentarer

Jeg tror, ​​kode er 90% søgeord og 10% faner. Uden mellemrum falder ordenes læselighed. Indrykninger er også nødvendige for håndskrevet kode. Brug det dog ikke til alle niveauer, da papirets bredde vil begrænse dig. Brug mellemrum med omtanke, men brug dem.

Hvis du skriver kode til dit brug, tror jeg også, at hvis du har fulgt alt, hvad jeg har nævnt indtil nu og allerede har skrevet dit output ned og en disposition på siden, behøver du måske ikke engang at inkludere kommentarer. Kommentarer fortæller dig hurtigt, hvad dets følgende kodesæt gør. Hvis du allerede har skrevet og læst en disposition til koden, så er kommentarer overflødige noter.

Men hvis din dom siger, at du skal lægge en fra dig, så gør det. Tilføj det til højre side af koden (da du ikke vil være i stand til at indsætte det mellem allerede skrevne linjer, som du kunne i f.eks. VS-kode). Brug skråstreger, parenteser eller pile for at angive, at de er kommentarer.

For eksaminander, der er usikker på en bestemt syntaks, skriv kommentarer ned. På denne måde giver du i det mindste den person, der bedømmer dit papir, din hensigt med den forkert formaterede kode. Og brug kun de korrekte afgrænsninger til at angive kommentarer - det ville f.eks. være skråstregerne for JavaScript.

Analog vs digital

Som jeg nævnte tidligere, er alt, hvad jeg giver her, generisk kodningsråd. Hvis du ikke vil prøve dette med fysisk papir, virker enhver noteapplikation også.

Men hvis du vil prøve den digitale rute, er min anbefaling at prøve at bruge noget andet end en direkte note-app. Arbejd med mere visuelle digitale værktøjer — flowdiagrammer, mindmaps, wireframes osv. De kan hjælpe dig med at visualisere dit resultat, konturerne og selve koden.

Jeg er ikke meget af en digital borger (bortset fra at arbejde på nettet og for nylig konverterede til at læse e-bøger), så jeg holder mig til fysiske notesbøger.

Mine yndlingsværktøjer til håndskriftskode

Enhver blyant og papir duer! Men der er masser af muligheder derude, og disse er et par valgværktøjer, jeg bruger:

Der er ingen "skrive" måde at kode på

Jeg håber, om ikke andet, min lille måde at håndskrive kode med blyant og papir på, får dig til at evaluere den måde, du allerede planlægger og skriver kode på. Jeg kan godt lide at vide, hvordan andre udviklere griber deres arbejde an, og dette er min måde at give dig et indblik i, hvordan jeg gør tingene.

Igen, intet her er videnskabeligt eller en eksakt kunst. Men hvis du vil prøve håndskreven kodeplanlægning, er her alt, hvad vi har dækket i en flot ordnet liste:

1. Start med at skrive ned (med eksempeldata, hvis det er nødvendigt) outputtet af din kode.
2. Skriv en disposition til koden. Hold det til tre trin for små projekter eller dem, der er mindre komplekse.
3. Brug langhåndsnotationer. Udviklere, der skriver for sig selv, kan bruge stenografiske notationer, så længe skriften er læselig og giver mening for dig, når du henviser til den senere.
4. Når du har en tidsbegrænsning, kan du overveje at skrive den kode, der løser problemets kerne først. Skriv senere et opkald til den kode på det rigtige sted i din sekventielle kode.
5. Hvis du føler dig sikker, så prøv at skrive pseudokode, der adresserer hovedideen.
6. Brug korrekte fordybninger og mellemrum - og vær opmærksom på papirets bredde.

Det er det! Når du er klar til at prøve at skrive kode i hånden, håber jeg, at denne artikel gør det nemt for dig at komme i gang. Og hvis du sidder ned til en eksamen eller en samtale, håber jeg, at dette hjælper dig med at fokusere på at stille spørgsmålene rigtigt.