Varför (och hur) jag skriver kod med penna och papper

Om tanken på handskriftskod verkar fånig, kan det förvåna dig att veta att det är oundvikligt. Om du är osäker, tänk på den senaste anställningsintervjun du gjorde och kom ihåg hur det inte fanns någon dator i intervjurummet – bara dina intervjuare, ett tomt papper och en blå kulspetspenna.

För eleverna bland er är det ännu en större sak eftersom dina betyg hänger med de kodrader som du strategiskt hade klämt in i det tillgängliga utrymmet i ditt svarsformulär.

Och inte bara det, erfarna programmerare kan peka dig till bunten med A4-ark som de hade tagit bort från kontorets kopieringsmaskin för att klottra ner en särskilt komplex algoritm som de hade arbetat med.

Så oavsett om du är en examensstudent, potentiell arbetsintervjuperson eller någon som vill lösa sina återvändsgränder för programmering, hoppas jag att den här artikeln hjälper dig när du sätter pennan på papperet för att koda.

Även om jag kommer att fokusera på den analoga aspekten av att skriva kod, kan du tillämpa dessa steg på kodning i vilken form eller språk som helst. Så betrakta detta som också som en generisk kodningsriktlinje som fungerar specifikt för mig men som också kan vara mycket användbar för dig i ditt arbete.

Varför skriva ner det?

Innan vi börjar är det viktigt att förstå att ingen förväntar sig att du ska skriva ner produktionsklar kod i en anteckningsbok. Det är inte så att du kan släppa det i en kodredigerare och kompilera det utan fel. Om målet var att producera perfekt kod, skulle du sitta framför en dator i intervjurummen och examenssalarna.

Syftet med handskriftskod är att arbeta igenom logiken i förväg. Det finns en önskan att "komma in i webbläsaren" så snart som möjligt i design, men det finns konventionell visdom i att skissa design för hand. Ett low-fidelity-medium uppmuntrar till snabba experiment och billiga misstag.

Detsamma kan gälla kod, främst när man arbetar med syntax och semantik. Som sagt, att få rätt syntax och semantik är alltid en pluspoäng, men inte den enda fokusen för hela handskriftsövningen.

Låt oss se var vi kan börja när det kommer till handskriftskod.

Vet din fråga

Under mitt sista år på college kunde jag inte göra praktik eller ens delta i campusintervjuer på grund av hälsoskäl. Som ett resultat var min allra första anställningsintervju ganska bokstavlig med höga insatser.

När jag ser tillbaka nu var intervjun ganska lätt. Men efter att aldrig ha deltagit i en tidigare, var jag orolig bortom rimligheten. Det första intervjuarna frågade om programmering var om jag kunde skriva ut en inverterad triangel gjord av asterisker. Som jag sa, det var lätt — ingenting a for loop klarar inte av, eller hur? Men som sagt, min ångest var i taket också.

Jag tog ett djupt andetag, tryckte handflatan mot det tomma pappersark som de hade lagt ut åt mig, gled det så sakta som möjligt mot mig på bordet (köptid förstås), klickade på pennan och sedan gjorde jag något höger.

Jag ritade först en omvänd triangel gjord av asterisker. Det var så jag hittade fötterna på jorden för att börja svara på deras fråga.

Jag har sett annars briljanta utvecklare få något fel bara för att de aldrig helt förstår vad det är de löser.

Frågorna vi arbetar med är inte som de frågor fysiker eller matematiker löser. De får en uppsättning parametrar och hittar de som saknas; våra frågor är också våra resultat. Vi har redan fått veta vad våra resultat är – vi måste ta reda på hur vi ska nå dem. Det är därför det är viktigt att känna till frågan väl eftersom du kommer att se resultatet.

Att skriva ner eller rita ut det du vill mata ut är ett av de bästa sätten att starta din kodning. Jag förstår att i vår snabba bransch är förväntningarna att vi måste hoppa direkt in i programmeringen genom att köra en "hej världen"-demo. Och det är fantastiskt att bekanta sig med en obekant syntax och skaka av sig ångesten över att prova något nytt.

Men när någon ställer en fråga till dig och ger dig ett resultat att arbeta mot, vore det inte bara bättre att lägga ner det först? Den frågan/resultatet är inte bara din utgångspunkt utan också din referenspunkt. I vilket steg som helst i din kodning kan du titta på det för att säkerställa att du arbetar mot det och att du är på rätt väg.

Så oavsett om det är i dina svarsblad eller i det tomma A4-pappret du ska skriva i, börja med att ta en sekund och skriva ner vad det är du försöker skriva ut. Du kan lägga det i marginalen eller i ett hörn om du inte vill att det ska vara en del av ditt svar. Se bara till att det är någonstans där du kan fortsätta hänvisa till det.

Beskriv din kod

Detta steg är som ett tveeggat svärd. Det kan ge dig en färdplan till ditt program eller slösa bort din tid. Mitt jobb är att se till att det är det förstnämnda.

Så först och främst vill jag säga: beskrivningskoden är onödig om omfattningen av ditt problem eller din fråga är liten. Återigen, denna praxis är varken föreskrivande eller universell för alla projekt eller situationer. Föreställ dig att jag är din intervjuare, och jag ber dig skriva hur du centrerar ett element på en webbsida med hjälp av CSS på så många sätt som möjligt. Du behöver inte precis en disposition för detta. Kodavsnitten är relativt små för varje metod.

Men nu, låt oss säga att jag tilldelar dig att skriva en webbapplikation som fångar användarsignaturer via ett pekskärmsgränssnitt och sedan sparar signaturen på servern. Inte så enkelt, eller hur? Du har mer än en sak att ta reda på. Kanske kan en liten översikt hjälpa till.

1. Användargränssnitt för att fånga signaturer - HTML Canvas? WebGL?
2. Inaktivera pekarhändelser på resten av webbsidan när användaren signerar
3. Konvertera och spara den tagna bilden till en PNG-fil — JS
4. Konvertera den sedan till blob (kanske) och spara den i besökarens loggdatatabell.

Jag har skrivit en grov sekvens av åtgärder som jag tror att jag kan behöva koda. Den kunde ha varit kortare eller längre, beroende på vad jag ville ha av den.

Jag rekommenderar starkt att du beskriver koden för kundprojekt. Skriv konturen tillsammans med dina användarkrav eller på baksidan av wireframes du har skrivit ut.

Din snabba ögonblicksbild av punktpunkter ger dig en karta, en att göra-lista och en checklista att verifiera mot när du når slutet av projektet - i stort sett hela ditt projekts sammanfattning i en lågtrohetslista. Det kan också bli en mall för att starta ditt nästa liknande projekt.

Men som jag sa tidigare, detta steg är som ett tveeggat svärd. Du måste hålla detta kort för examinander och intervjupersoner när det finns tidsbrist.

Om du inte vet var du ska börja, skriv bara ner tre viktiga funktioner som du måste koda i din ansökan, och om du har tid, gör det till fem.

Men det är ungefär det. Lägg så lite tid som möjligt på detta och svettas inte över detaljerna. Konturen kommer inte att ge dig extra poäng. Det finns bara för att hjälpa dig att se till att du har allt täckt. Den fångar din första magreaktion och håller dig ärlig under hela projektets liv.

Longhand vs. stenografi

Dags att börja koda. Så vad skriver du? "Bdrs" eller "border-radius"; "div -> p"Eller"<div><p></div></p>"; "pl()"Eller"println()"; "q()"Eller"querySelector()"?

Om någon annan betygsätter din kod, så finns det inget val. Utelämna förkortningar, pseudokoder, Emmet-genvägar och alla andra former av stenografi. Annars finns det ingen anledning att anta att någon som läser detta vet vad dina förkortningar betyder.

Det är verkligen upp till dig.

Om du har tappat kontakten med att skriva för hand - och många av oss har gjort det - är det bättre att inte gå överbord med långhandsbeteckningarna, eftersom de blir tråkiga. Samtidigt finns det inget som heter att vara för sparsam med ditt skrivande. Inte om du vill kunna se tillbaka på det en dag och förstå vad du skrivit ner.

Jag har en öppen fil i min anteckningsapp och ett fodrat anteckningsblock på skrivbordet där jag skriver ner kodavsnitt som jag vill spara för senare referens. De är oorganiserade, bara en lång ström av utdrag. Det är därför när jag bläddrar igenom äldre anteckningar, skulle jag inte veta vad jag menade att skriva om jag inte hade skrivit ner dem tydligt.

Jag glömmer syntaxer hela tiden. Jag har till exempel använt pilnotationen för JavaScript-funktioner sedan den introducerades (eftersom den är kortare), och jag är ganska säker på att om någon plötsligt ber mig att definiera en funktion med hjälp av function nyckelord kan jag till och med ta bort parentesen eller funktionsnamnet, vilket leder till ett syntaxfel.

Det är inte ovanligt att vi glömmer syntaxer som vi inte har använt på ett tag. Det är därför det är bättre att skriva dina anteckningar tydligt när du vet att du behöver dem för framtida referens.

Det icke-sekventiella flödet av kod

Till skillnad från det sista steget, som inte gäller för er intervjupersoner och testtagare, är det här speciellt tillgodosedda för er.

De flesta programmeringsspråk tolkas, kompileras och exekveras så att ibland förskriven kod i källan exekveras senare när den anropas. Vi gör det i JavaScript, till exempel, med funktionsanrop — funktioner kan definieras initialt och sedan exekveras senare. Examinerade och intervjupersoner kan använda detta för att börja arbeta med den kritiska punkten i ditt svar först.

Som jag har sagt från allra första början, syftet med handskriftskod är att arbeta igenom eller testa logiken i vad det än är du programmerar. Det är bäst när du fokuserar på att lösa det först.

Låt oss ta ett klassiskt läroboksexempel — ett program för att hitta det n:te Fibonacci-nummer. Om jag skulle skriva en enkel disposition för det skulle det vara ungefär så här:

1. Få input.
2. Beräkna Fibonacci-talet.
3. Sammanfatta resultatet.
4. Skriv ut resultatet.

Alla steg i den dispositionen är väsentliga; dock är 1, 3 och 4 mer obligatoriska. De är nödvändiga men inte tillräckligt viktiga för att fokusera på direkt.

Det är bättre att börja skriva ner koden för att beräkna Fibonacci-talet snarare än att hämta indata. Slå in den i en funktion, fortsätt sedan och skriv koden sekventiellt och skriv ner en rad för att anropa den funktionen där det är lämpligt.

Lägg din tid på att skriva kod som fokuserar på problemets kärna.

Riktiga proffs kan hoppa framåt. Låt oss säga att jag har ett kundprojekt och jag måste arbeta med lite triangelgeometri - jag har två sidor, motsatt vinkel och måste hitta den tredje sidans längd. Och jag har bestämt mig för att klottra på papper för att komma igång istället för att öppna min IDE.

Först skulle jag rita triangeln, såklart (det är något jag är väldigt erfaren med, som ni märker). Jag skulle skriva ner några provlängder och vinklar. Sedan skulle jag skriva formeln (komplimanger till onlinesökning, helt klart), och sedan hoppade jag direkt till koden för funktionen.

Det är ingen idé att jag skriver ner de obligatoriska stegen även om jag behöver dem i produktionsklar kod. Men det skulle vara annorlunda om jag måste skriva det på ett svarsblad på en tenta. Jag kan inte hoppa över de andra stegen; dock kan jag fortfarande börja med koden för formeln.

Pseudokod

Chris har redan skrivit en praktisk artikel om pseudokod som jag starkt rekommenderar att du läser.

För alla de proffs som känner att hela handskriftskoden inte verkar vara din kopp te men som ändå kan vara nyfiken på om det kan hjälpa dig, då pseudokod kan vara balansen du letar efter.

Det liknar att beskriva koden, som jag nämnde i ett av de föregående stegen. Det är dock kortare och känns mer som stenografikodning. Det kallas ibland också för "skelettkod".

Här är lite snabb pseudokod för en CSS-rutnätslayout:

Grid
5 60px rows
6 100px columns

Det finns inte mycket att skriva! Så även om det är utmärkt att sätta en penna på papper för den här typen av saker, är det lika effektivt, snabbt och billigt att anteckna lite pseudokod i vilket program du än använder.

Utrymme och kommentarer

Jag tror att kod är 90% nyckelord och 10% flikar. Utan mellanslag minskar ordens läsbarhet. Indrag är nödvändiga för handskriven kod också. Men använd den inte för varje nivå eftersom papprets bredd kommer att begränsa dig. Använd utrymmen med omtanke, men använd dem.

Om du skriver kod för din användning, tror jag också att om du har följt allt jag har nämnt hittills och redan har skrivit ner din utdata och en disposition på sidan, kanske du inte ens behöver inkludera kommentarer. Kommentarer berättar snabbt vad dess följande koduppsättning gör. Om du redan har skrivit och läst en disposition för koden, är kommentarer överflödiga anteckningar.

Men om din bedömning säger att du ska lägga ner en, gör det då. Lägg till den på höger sida av koden (eftersom du inte kommer att kunna infoga den mellan redan skrivna rader som du kunde i t.ex. VS-kod). Använd snedstreck, parenteser eller pilar för att ange att de är kommentarer.

För examinander som är osäker på en viss syntax, skriv ner kommentarer. På så sätt låter du åtminstone personen som betygsätter ditt papper veta din avsikt med den felaktigt formaterade koden. Och använd bara rätt avgränsare för att beteckna kommentarer - det skulle till exempel vara snedstreck för JavaScript.

Analog kontra digital

Som jag nämnde tidigare kan allt jag tillhandahåller här är generiska kodningsråd. Om du inte vill prova detta med fysiskt papper, fungerar även vilken anteckningsapplikation som helst.

Men om du ska prova den digitala vägen är min rekommendation att prova att använda något annat än en rak anteckningsapp. Arbeta med fler visuella digitala verktyg — flödesdiagram, tankekartor, trådramar, etc. De kan hjälpa dig att visualisera ditt resultat, konturerna och själva koden.

Jag är inte mycket av en digital medborgare (förutom att jag arbetar på webben och nyligen konverterat till att läsa e-böcker), så jag håller mig till fysiska anteckningsböcker.

Mina favoritverktyg för handskriftskod

Vilken penna och papper som helst duger! Men det finns massor av alternativ där ute, och det här är några valverktyg jag använder:

Det finns inget "skriv" sätt att koda

Jag hoppas, om inte annat, att mitt lilla sätt att handskriva kod med penna och papper får dig att utvärdera hur du redan planerar och skriver kod. Jag gillar att veta hur andra utvecklare närmar sig sitt arbete, och det här är mitt sätt att ge dig en titt på hur jag gör saker.

Återigen, ingenting här är vetenskapligt eller en exakt konst. Men om du vill ge handskriven kodplanering ett försök, här är allt vi har täckt i en trevlig ordnad lista:

1. Börja med att skriva ner (med exempeldata, om det behövs) utdata från din kod.
2. Skriv en disposition för koden. Vänligen håll det till tre steg för små projekt eller de som är mindre komplexa.
3. Använd långhandsbeteckningar. Utvecklare som skriver för sig själva kan använda stenografisk notationer så länge som skriften är läsbar och vettig för dig när du hänvisar till den senare.
4. När du har en tidspress, överväg att skriva koden som tar itu med problemets kärna först. Skriv senare ner ett samtal till den koden på rätt plats i din sekventiella kod.
5. Om du känner dig säker, försök att skriva pseudokod som adresserar huvudidén.
6. Använd lämpliga fördjupningar och mellanrum - och var uppmärksam på papperets bredd.

Det är allt! När du är redo att försöka skriva kod för hand hoppas jag att den här artikeln gör det enkelt för dig att börja. Och om du sitter ner för ett prov eller en intervju, hoppas jag att detta hjälper dig att fokusera på att få frågorna rätt.