Als de gedachte aan handschriftcode dwaas lijkt, zal het je misschien verbazen te weten dat het onvermijdelijk is. Als je het niet zeker weet, denk dan eens aan het laatste sollicitatiegesprek dat je hebt gevoerd en onthoud dat er geen computer in de sollicitatieruimte was - alleen je interviewers, een blanco vel papier en een blauwe balpen.

Voor de studenten onder jullie is het zelfs nog belangrijker, omdat je cijfers hangen aan de regels code die je strategisch in de beschikbare ruimte op je antwoordblad had geperst.

En niet alleen dat, ervaren programmeurs kunnen u wijzen op de bundel A4-vellen die ze uit de kantoorkopieermachine hadden gehaald om een ​​bijzonder complex algoritme te krabbelen waaraan ze hadden gewerkt.

Dus of je nu een examenstudent bent, een potentiële sollicitant of iemand die zijn programmeerproblemen wil oplossen, ik hoop dat dit artikel je helpt wanneer je je pen op het papier zet om te coderen.

Hoewel ik me zal concentreren op het analoge aspect van het schrijven van code, kun je deze stappen toepassen op codering in elke vorm of taal. Beschouw dit dus ook als een generieke codeerrichtlijn die specifiek voor mij werkt, maar die ook zeer nuttig voor u kan zijn in uw werk.

Waarom opschrijven?

Voordat we beginnen, is het essentieel om te begrijpen dat niemand verwacht dat u productieklare code in een notitieboekje noteert. Het is niet zo dat je dat in een code-editor kunt laten vallen en het zonder fouten kunt compileren. Als het doel was om perfecte code te produceren, zou je achter een computer zitten in de interviewruimten en examenzalen.

Het doel van handschriftcode is om vooraf logica door te werken. Er is een wens om zo snel mogelijk "in de browser te komen" in ontwerp, maar er is conventionele wijsheid in het met de hand schetsen van ontwerpen. Een low-fidelity medium moedigt snelle experimenten en goedkope fouten aan.

Hetzelfde kan gelden voor code, vooral bij het uitwerken van syntaxis en semantiek. Dat gezegd hebbende, het verkrijgen van de juiste syntaxis en semantiek is: altijd een pluspunt, maar niet de enige focus van de hele handschriftoefening.

Laten we eens kijken waar we kunnen beginnen als het gaat om handschriftcode.

Ken je vraag

Tijdens mijn laatste jaar op de universiteit kon ik vanwege gezondheidsredenen geen stage lopen of zelfs maar campusinterviews bijwonen. Als gevolg hiervan was mijn allereerste sollicitatiegesprek vrij letterlijk met hoge inzetten.

Als ik nu terugkijk, was het interview vrij eenvoudig. Maar omdat ik er nog nooit eerder een had bijgewoond, was ik buitengewoon angstig. Het eerste wat de interviewers vroegen over programmeren was of ik een omgekeerde driehoek van sterretjes kon maken. Zoals ik al zei, het was gemakkelijk - niets a for lus kan het niet aan, toch? Maar zoals ik al zei, mijn angst was ook door het dak.

Ik haalde diep adem, drukte mijn handpalm tegen het blanco vel papier dat ze voor me hadden neergelegd, schoof het zo langzaam mogelijk naar me toe op de tafel (tijd kopen natuurlijk), klikte op de pen en toen deed ik iets Rechtsaf.

Ik tekende eerst een omgekeerde driehoek gemaakt van sterretjes. Zo vond ik mijn voeten op de grond om hun vraag te beantwoorden.

Ik heb andere briljante ontwikkelaars iets verkeerd zien doen, simpelweg omdat ze nooit helemaal begrijpen wat ze aan het oplossen zijn.

De vragen waarmee we werken zijn niet zoals de vragen die natuurkundigen of wiskundigen oplossen. Ze krijgen een set parameters en vinden de ontbrekende; onze vragen zijn ook onze resultaten. Er is ons al verteld wat onze resultaten zijn - we moeten uitzoeken hoe we ze kunnen bereiken. Daarom is het noodzakelijk om de vraag goed te kennen, want je zult het resultaat zien.

Het opschrijven of uittekenen van wat u wilt uitvoeren, is een van de beste manieren om te beginnen met coderen. Ik begrijp dat in onze snelle industrie de verwachting is dat we meteen in de programmering moeten springen door een "hallo wereld"-demo te draaien. En dat is geweldig om jezelf vertrouwd te maken met een onbekende syntaxis en je angst om iets nieuws te proberen van je af te schudden.

Maar als iemand je een vraag stelt en je een resultaat geeft om naar toe te werken, zou het dan niet beter zijn om dat eerst op te schrijven? Die vraag/resultaat is niet alleen je vertrekpunt maar ook je referentiepunt. Bij elke stap in uw codering kunt u ernaar kijken om er zeker van te zijn dat u ernaartoe werkt en dat u op de goede weg bent.

Dus of het nu in je antwoordbladen is of in dat blanco A4-papier dat je gaat schrijven, begin met een seconde te nemen en op te schrijven wat je probeert uit te voeren. Je kunt het in de marge of in een hoek plaatsen als je niet wilt dat het een onderdeel van je antwoord is. Zorg ervoor dat het ergens is waar u ernaar kunt blijven verwijzen.

Maak een overzicht van uw code

Deze stap is als een tweesnijdend zwaard. Het kan u een routekaart naar uw programma opleveren of uw tijd verspillen. Het is mijn taak ervoor te zorgen dat het de eerste is.

Daarom wil ik eerst en vooral zeggen: schetscode is niet nodig als de omvang van uw probleem of vraag klein is. Nogmaals, deze praktijk is noch prescriptief noch universeel voor alle projecten of situaties. Stel je voor dat ik je interviewer ben en ik vraag je te schrijven hoe je een element in een webpagina kunt centreren met behulp van CSS op zoveel mogelijk manieren. Je hebt hier niet bepaald een schets voor nodig. De codefragmenten zijn relatief klein voor elke methode.

Maar laten we zeggen dat ik u nu toewijs om een ​​webtoepassing te schrijven die gebruikershandtekeningen vastlegt via een touchscreen-interface en vervolgens de handtekening opslaat op de server. Niet zo eenvoudig, toch? Je moet meer dan één ding uitzoeken. Misschien kan een klein overzicht helpen.

1. Gebruikersinterface voor het vastleggen van handtekening - HTML Canvas? WebGL?
2. Aanwijzergebeurtenissen op de rest van de webpagina uitschakelen wanneer de gebruiker ondertekent
3. Converteer en sla de vastgelegde afbeelding op in een PNG-bestand — JS
4. Converteer het vervolgens naar blob (misschien) en sla het op in de loggegevenstabel van de bezoeker.

Ik heb een ruwe reeks acties geschreven waarvan ik denk dat ik ze moet coderen. Het had korter of langer kunnen zijn, afhankelijk van wat ik ervan wilde.

Ik raad ten zeerste aan om code te schetsen voor klantprojecten. Schrijf de omtrek samen met uw gebruikersvereisten of op de achterkant van draadframes die u hebt afgedrukt.

Je snelle momentopname van opsommingstekens geeft je een kaart, een takenlijst en een checklist om te verifiëren wanneer je het einde van het project bereikt - vrijwel de samenvatting van je hele project in een low-fidelity-lijst. Het kan ook een sjabloon worden om uw volgende soortgelijke project te starten.

Maar zoals ik al eerder zei, deze stap is als een tweesnijdend zwaard. Je zult dit kort moeten houden voor examinatoren en geïnterviewden als er tijdsdruk is.

Als je niet weet waar je moet beginnen, noteer dan slechts drie essentiële functies die je in je applicatie moet coderen, en als je de tijd hebt, maak er dan vijf van.

Maar dat is het ongeveer. Besteed hier zo min mogelijk tijd aan en maak je niet druk om de details. Het overzicht levert je geen extra punten op. Het is er alleen om u te helpen ervoor te zorgen dat u alles heeft gedekt. Het legt je eerste instinctieve reactie vast en houdt je eerlijk gedurende de hele levensduur van het project.

Longhand versus steno

Tijd om te beginnen met coderen. Dus, wat schrijf je? "Bdrs" of "border-radius“; "div -> p"Of"<div><p></div></p>“; "pl()"Of"println()“; "q()"Of"querySelector()"?

Als iemand anders je code beoordeelt, is er geen keuze. Laat afkortingen, pseudo-codes, Emmet-snelkoppelingen en elke andere vorm van stenoschrift achterwege. Anders is er geen reden om aan te nemen dat iemand die dit leest weet wat uw afkortingen betekenen.

Het is echt aan jou.

Als je het schrijven met de hand bent kwijtgeraakt - en velen van ons hebben dat - is het beter om niet overboord te gaan met de handgeschreven notaties, omdat ze vervelend worden. Tegelijkertijd is er niet zoiets als te zuinig zijn met je schrijven. Niet als je er ooit op terug wilt kunnen kijken en wilt begrijpen wat je hebt opgeschreven.

Ik heb een open bestand in mijn notitie-app en een gelinieerd notitieblok op mijn bureau waar ik codefragmenten opschrijf die ik wil bewaren voor later gebruik. Ze zijn ongeorganiseerd, slechts een lange stroom fragmenten. Daarom zou ik, als ik door oudere aantekeningen blader, niet weten wat ik wilde schrijven als ik ze niet duidelijk had opgeschreven.

Ik vergeet de hele tijd syntaxis. Ik gebruik bijvoorbeeld de pijlnotatie voor JavaScript-functies sinds het werd geïntroduceerd (omdat het korter is), en ik ben er vrij zeker van dat als iemand me plotseling vraagt ​​om een ​​functie te definiëren met behulp van de function trefwoord, kan ik zelfs de haakjes of de functienaam verkeerd plaatsen, waardoor een syntaxisfout wordt veroorzaakt.

Het is niet ongebruikelijk dat we syntaxis vergeten die we al een tijdje niet hebben gebruikt. Daarom is het beter om uw aantekeningen duidelijk te schrijven als u weet dat u ze nodig heeft voor toekomstig gebruik.

De niet-sequentiële codestroom

In tegenstelling tot de laatste stap, die niet van toepassing is op de geïnterviewden en testpersonen, is deze speciaal voor jou bedoeld.

De meeste programmeertalen worden geïnterpreteerd, gecompileerd en uitgevoerd, zodat soms vooraf geschreven code in de broncode later wordt uitgevoerd wanneer ze worden aangeroepen. We doen het bijvoorbeeld in JavaScript met functieaanroep - functies kunnen in eerste instantie worden gedefinieerd en later worden uitgevoerd. Examinatoren en geïnterviewden kunnen dit gebruiken om eerst aan de slag te gaan met het kritieke punt van je antwoord.

Zoals ik vanaf het begin heb gezegd, is het doel van handgeschreven code om de logica van wat je ook programmeert door te werken of te testen. Het is het beste als u zich eerst concentreert op het oplossen daarvan.

Laten we een klassiek schoolvoorbeeld nemen - een programma om de nth . te vinden Fibonacci-nummer. Als ik er een eenvoudige schets voor zou moeten schrijven, zou het zoiets zijn als dit:

1. Krijg de invoer.
2. Bereken het Fibonacci-getal.
3. Vat de uitvoer samen.
4. Druk de uitvoer af.

Alle stappen in dat overzicht zijn essentieel; 1, 3 en 4 zijn echter meer verplicht. Ze zijn noodzakelijk, maar niet belangrijk genoeg om er meteen op te focussen.

Het is beter om de code op te schrijven om het Fibonacci-getal te berekenen in plaats van de invoer op te halen. Wikkel het in een functie, ga je gang en schrijf de code opeenvolgend en schrijf een regel op om die functie waar nodig aan te roepen.

Besteed uw tijd aan het schrijven van code die zich richt op de kern van het probleem.

Echte professionals kunnen vooruit springen. Laten we zeggen dat ik een klantproject heb, en ik moet werken met een driehoeksgeometrie - ik heb twee zijden, een tegenovergestelde hoek, en ik moet de lengte van de derde zijde vinden. En ik heb besloten om op papier te krabbelen om te beginnen in plaats van mijn . te openen IDE.

Eerst zou ik natuurlijk de driehoek tekenen (dat is iets waar ik veel ervaring mee heb, zoals je kunt zien). Ik zou wat monsterlengtes en -hoeken opschrijven. Dan zou ik de formule schrijven (zeker complimenten van online zoeken), en dan zou ik meteen naar de code voor de functie springen.

Het heeft geen zin dat ik de verplichte stappen opschrijf, ook al heb ik ze nodig in productieklare code. Maar het zou anders zijn als ik dat bij een tentamen op een antwoordblad zou moeten schrijven. Ik kan de andere stappen niet overslaan; ik kan echter nog steeds beginnen met de code voor de formule.

Pseudo-code

Chris heeft al geschreven a handig artikel over pseudo-code dat ik je ten zeerste aanbeveel om het goed te lezen.

Voor al die professionals die het gevoel hebben dat het hele handschriftcode gedoe niet jouw ding lijkt, maar toch nieuwsgierig zijn of het je kan helpen, dan pseudo-code misschien wel de balans die u zoekt.

Het is vergelijkbaar met het schetsen van de code, zoals ik al zei in een van de vorige stappen. Het is echter korter en voelt meer als stenocodering. Het wordt soms ook wel 'skeletcode' genoemd.

Hier is wat snelle pseudo-code voor een CSS-rasterlay-out:

Grid
5 60px rows
6 100px columns

Er valt niet veel te schrijven! Dus ook al is een potlood op papier uitstekend geschikt voor dit soort dingen, het is net zo effectief, snel en goedkoop om wat pseudo-code te noteren in welk programma je ook gebruikt.

Ruimte en opmerkingen

Ik geloof dat code 90% zoekwoorden en 10% tabbladen is. Zonder spaties neemt de leesbaarheid van woorden af. Inspringingen zijn ook nodig voor handgeschreven code. Gebruik het echter niet voor elk niveau, omdat de breedte van het papier u zal beperken. Gebruik ruimtes verstandig, maar gebruik ze.

Als je code schrijft voor eigen gebruik, geloof ik ook dat als je alles wat ik tot nu toe heb genoemd hebt gevolgd en je output en een overzicht op de pagina al hebt opgeschreven, je misschien niet eens opmerkingen hoeft op te nemen. Opmerkingen vertellen je snel wat de volgende set code doet. Als u al een overzicht voor de code hebt geschreven en gelezen, zijn opmerkingen overbodige opmerkingen.

Als je oordeel echter zegt dat je er een moet neerleggen, doe het dan. Voeg het toe aan de rechterkant van de code (omdat je het niet tussen reeds geschreven regels kunt invoegen zoals je zou kunnen in, laten we zeggen, VS-code). Gebruik schuine strepen, haakjes of pijlen om aan te geven dat het opmerkingen zijn.

Voor examenkandidaten die niet zeker zijn van een bepaalde syntaxis, noteer opmerkingen. Op deze manier laat je in ieder geval de persoon die je paper beoordeelt je bedoeling weten met die verkeerd opgemaakte code. En gebruik alleen de juiste scheidingstekens om opmerkingen aan te duiden - dat zijn bijvoorbeeld de schuine strepen voor JavaScript.

Analoog versus digitaal

Zoals ik eerder al zei, kan alles wat ik hier geef generiek codeeradvies zijn. Als u dit niet met fysiek papier wilt proberen, werkt elke toepassing voor het maken van aantekeningen ook.

Maar als je de digitale route gaat proberen, is mijn aanbeveling om iets anders te proberen dan een gewone app voor het maken van aantekeningen. Werk met meer visuele digitale hulpmiddelen - stroomdiagrammen, mindmaps, wireframes, enz. Ze kunnen u helpen uw resultaat, de contouren en de code zelf te visualiseren.

Ik ben niet zo'n digitale burger (behalve dat ik op het web werk en onlangs ben overgestapt op het lezen van e-books), dus ik blijf bij fysieke notebooks.

Mijn favoriete tools voor handschriftcode

Elk potlood en papier is voldoende! Maar er zijn veel opties die er zijn, en dit zijn een paar keuzehulpmiddelen die ik gebruik:

Er is geen "schrijf" manier om te coderen

Ik hoop dat mijn kleine manier van handgeschreven code met potlood en papier ervoor zorgt dat je de manier waarop je al code plant en schrijft, evalueert. Ik vind het leuk om te weten hoe andere ontwikkelaars hun werk benaderen, en dit is mijn manier om je een kijkje te geven in de manier waarop ik dingen doe.

Nogmaals, niets is hier wetenschappelijk of een exacte kunst. Maar als je handgeschreven codeplanning eens wilt proberen, hier is alles wat we hebben behandeld in een mooie geordende lijst:

1. Begin met het opschrijven (met voorbeeldgegevens, indien nodig) van de uitvoer van uw code.
2. Schrijf een schets voor de code. Houd het bij drie stappen voor kleine of minder complexe projecten.
3. Gebruik handgeschreven notaties. Ontwikkelaars die voor zichzelf schrijven, kunnen steno-notaties gebruiken zolang het schrift leesbaar is en logisch voor u is wanneer u er later naar verwijst.
4. Overweeg bij een beperkte tijd de code te schrijven die de kern van het probleem als eerste aanpakt. Schrijf later een aanroep naar die code op de juiste plaats in uw sequentiële code.
5. Als je je zelfverzekerd voelt, probeer dan pseudocode te schrijven die het hoofdidee aanpakt.
6. Gebruik de juiste inkepingen en spaties - en houd rekening met de breedte van het papier.

Dat is het! Als je klaar bent om met de hand code te schrijven, hoop ik dat dit artikel het je gemakkelijk maakt om te beginnen. En als je gaat zitten voor een examen of een interview, hoop ik dat dit je helpt je te concentreren op het krijgen van de juiste vragen.