Perché (e come) scrivo codice con carta e matita PlatoBlockchain Data Intelligence. Ricerca verticale. Ai.

Perché (e come) scrivo codice con carta e matita

Se il pensiero del codice della scrittura a mano sembra sciocco, potrebbe sorprenderti sapere che è inevitabile. Se non sei sicuro, pensa all'ultimo colloquio di lavoro che hai fatto e ricorda come non c'era un computer nella stanza del colloquio: solo i tuoi intervistatori, un foglio di carta bianco e una penna a sfera blu.

Per gli studenti tra di voi, è ancora più importante poiché i voti restano bloccati dalle righe di codice che avevi spremuto strategicamente nello spazio disponibile nel foglio delle risposte.

E non solo, i programmatori esperti possono indicarti il ​​fascio di fogli A4 che avevano rimosso dalla fotocopiatrice dell'ufficio per scarabocchiare un algoritmo particolarmente complesso su cui stavano lavorando.

Quindi, che tu sia uno studente d'esame, un potenziale intervistato di lavoro o qualcuno che vuole risolvere i propri vicoli ciechi di programmazione, spero che questo articolo ti aiuti quando metti la penna sulla carta per programmare.

Sebbene mi concentrerò sull'aspetto analogico della scrittura del codice, puoi applicare questi passaggi alla codifica in qualsiasi forma o lingua. Quindi considera questo anche come una linea guida di codifica generica che funziona specificamente per me ma può anche essere molto utile per te nel tuo lavoro.

Perché scriverlo?

Prima di iniziare, è essenziale capire che nessuno si aspetta che tu annoti il ​​codice pronto per la produzione in un notebook. Non è che puoi rilasciarlo in un editor di codice e compilarlo senza errori. Se l'obiettivo fosse produrre un codice perfetto, saresti seduto davanti a un computer nelle aule dei colloqui e nelle aule d'esame.

Lo scopo del codice di scrittura a mano è di lavorare in anticipo attraverso la logica. C'è il desiderio di "entrare nel browser" il prima possibile nel design, ma c'è una saggezza convenzionale nello disegnare i progetti a mano. Un mezzo a bassa fedeltà incoraggia la sperimentazione rapida e gli errori poco costosi.

La fatica di cercare di capire come influenzare gli oggetti circostanti con un clic (da my ultimo articolo)

Lo stesso può essere vero per il codice, principalmente quando si elabora la sintassi e la semantica. Detto questo, ottenere la sintassi e la semantica corrette lo è sempre un punto in più, anche se non l'unico obiettivo dell'intero esercizio di scrittura a mano.

Vediamo da dove possiamo iniziare quando si tratta di codice di scrittura a mano.

Conosci la tua domanda

Durante il mio ultimo anno al college, per motivi di salute non ho potuto fare uno stage e nemmeno partecipare a colloqui nel campus. Di conseguenza, il mio primo colloquio di lavoro è stato abbastanza letterale con una posta in gioco alta.

Quando mi guardo indietro ora, l'intervista è stata abbastanza facile. Ma non avendo mai frequentato uno prima, ero ansioso oltre ogni ragione. La prima cosa che gli intervistatori hanno chiesto sulla programmazione è stata se potevo produrre un triangolo invertito fatto di asterischi. Come ho detto, è stato facile - niente a for loop non può gestire, giusto? Ma come ho detto, anche la mia ansia era alle stelle.

Ho fatto un respiro profondo, ho premuto il palmo della mano contro il foglio bianco che mi avevano preparato, l'ho fatto scorrere il più lentamente possibile verso di me sul tavolo (tempo di acquisto, ovviamente), ho cliccato la penna e poi ho fatto qualcosa Giusto.

Per prima cosa ho disegnato un triangolo rovesciato fatto di asterischi. È così che ho trovato i piedi per terra per iniziare a rispondere alla loro domanda.

Ho visto sviluppatori altrimenti brillanti sbagliare qualcosa semplicemente perché non capiscono mai completamente cosa stanno risolvendo.

Le domande su cui lavoriamo non sono come le domande risolte dai fisici o dai matematici. Ottengono una serie di parametri e trovano quelli mancanti; le nostre domande sono anche i nostri risultati. Ci è già stato detto quali sono i nostri risultati: dobbiamo capire come raggiungerli. Ecco perché è fondamentale conoscere bene la domanda perché vedrai il risultato.

Annotare o disegnare ciò che si desidera produrre è uno dei modi migliori per iniziare la codifica. Capisco che nel nostro settore frenetico, l'aspettativa è che dobbiamo saltare direttamente alla programmazione eseguendo una demo "ciao mondo". Ed è fantastico familiarizzare con una sintassi sconosciuta e scrollarsi di dosso l'ansia di provare qualcosa di nuovo.

Ma quando qualcuno ti fa una domanda e ti dà un risultato su cui lavorare, non sarebbe meglio prima metterlo giù? Quella domanda/risultato non è solo il tuo punto di partenza, ma anche il tuo punto di riferimento. In qualsiasi fase della codifica, puoi esaminarla per assicurarti di lavorare in tal senso e di essere sulla strada giusta.

Quindi, sia nei fogli delle risposte che in quel foglio A4 bianco su cui stai per scrivere, inizia prendendo un secondo e annotando ciò che stai cercando di produrre. Puoi metterlo ai margini o in un angolo se non vuoi che faccia parte della tua risposta. Assicurati solo che sia da qualche parte dove puoi continuare a fare riferimento.

Delinea il tuo codice

Questo passaggio è come un'arma a doppio taglio. Può fornirti una tabella di marcia per il tuo programma o farti perdere tempo. Il mio compito è assicurarmi che sia il primo.

Quindi, prima di tutto, mi piace dire: il codice di struttura non è necessario se l'ambito del problema o della domanda è piccolo. Ancora una volta, questa pratica non è né prescrittiva né universale per tutti i progetti o situazioni. Immagina di essere il tuo intervistatore e di chiederti di scrivere come centrare un elemento in una pagina web usando i CSS nel maggior numero possibile di modi. Non avrai esattamente bisogno di uno schema per questo. I frammenti di codice sono relativamente piccoli per ogni metodo.

Ma ora, diciamo che ti assegno a scrivere un'applicazione web che acquisisce le firme degli utenti tramite un'interfaccia touchscreen e quindi salva la firma sul server. Non così semplice, giusto? Hai più di una cosa da capire. Forse, un piccolo schema può aiutare.

  1. Interfaccia utente per l'acquisizione della firma: HTML Canvas? WebGL?
  2. Disabilita gli eventi del puntatore nel resto della pagina Web quando l'utente sta firmando
  3. Converti e salva l'immagine acquisita in un file PNG — JS
  4. Quindi convertilo in blob (forse) e salvalo nella tabella dei dati di registro del visitatore.

Ho scritto una sequenza approssimativa di azioni che penso di dover programmare. Avrebbe potuto essere più breve o più lungo, a seconda di cosa volevo da esso.

Consiglio vivamente di delineare il codice per i progetti dei clienti. Scrivi lo schema insieme ai requisiti dell'utente o sul retro dei wireframe che hai stampato.

La tua rapida istantanea dei punti elenco ti fornisce una mappa, un elenco di cose da fare e un elenco di controllo da confrontare quando raggiungi la fine del progetto: praticamente il riepilogo dell'intero progetto in un elenco a bassa fedeltà. Può anche diventare un modello per iniziare il tuo prossimo progetto simile.

Ma come ho detto prima, questo passaggio è come un'arma a doppio taglio. Dovrai mantenere questo breve per esaminati e intervistati quando ci sono vincoli di tempo.

Se non sai da dove iniziare, annota solo tre funzioni essenziali che dovrai codificare nella tua applicazione e, se hai tempo, fallo cinque.

Ma questo è tutto. Dedica meno tempo possibile a questo e non preoccuparti dei dettagli. Lo schema non ti farà guadagnare punti extra. È lì solo per aiutarti ad assicurarti di avere tutto coperto. Cattura la tua reazione istintiva iniziale e ti mantiene onesto per tutta la vita del progetto.

Mano lunga contro stenografia

Carta a righe bianche con note scritte a mano in corsivo in inchiostro nero.
Un rapido riferimento per disabilitare la selezione del testo

È ora di iniziare a codificare. Allora, cosa scrivi? "Bdrs" o "border-radius“; "div -> p" o "<div><p></div></p>“; "pl()" o "println()“; "q()" o "querySelector()"?

Se qualcun altro sta valutando il tuo codice, non c'è scelta. Tralascia abbreviazioni, pseudocodici, scorciatoie Emmet e qualsiasi altra forma di scrittura abbreviata. Altrimenti, non c'è motivo di presumere che chiunque legga questo articolo sappia cosa significano le tue abbreviazioni.

Dipende davvero da te.

Se hai perso il contatto con la scrittura a mano - e molti di noi l'hanno fatto - è meglio non esagerare con le annotazioni a mano lunga, poiché diventano noiose. Allo stesso tempo, non c'è niente come essere troppo frugali con la tua scrittura. Non se vuoi essere in grado di ripensarci un giorno e capire cosa avevi scritto.

Ho un file aperto nella mia app per prendere appunti e un blocco note a righe sulla mia scrivania dove annoto frammenti di codice che voglio salvare per riferimento futuro. Sono disorganizzati, solo un lungo flusso di frammenti. Ecco perché quando sfoglio le note più vecchie, non saprei cosa intendevo scrivere se non le avessi scritte chiaramente.

Dimentico sempre le sintassi. Ad esempio, ho usato la notazione freccia per le funzioni JavaScript da quando è stata introdotta (perché è più breve), e sono abbastanza sicuro se qualcuno improvvisamente mi chiedesse di definire una funzione usando il function parola chiave, potrei anche smarrire le parentesi o il nome della funzione, provocando un errore di sintassi.

Non è insolito per noi dimenticare sintassi che non usiamo da un po'. Ecco perché è meglio scrivere i tuoi appunti in modo chiaro quando sai che ne hai bisogno per riferimento futuro.

Il flusso non sequenziale del codice

A differenza dell'ultimo passaggio, che non si applica a voi intervistati e partecipanti al test, questo è pensato appositamente per voi.

La maggior parte dei linguaggi di programmazione vengono interpretati, compilati ed eseguiti in modo che a volte il codice pre-scritto nel sorgente venga eseguito in seguito quando viene chiamato. Lo facciamo in JavaScript, ad esempio, con la funzione di chiamata: le funzioni possono essere definite inizialmente, quindi eseguite in seguito. Gli esaminatori e gli intervistati possono usarlo per iniziare a lavorare prima sul punto critico della tua risposta.

Come ho detto fin dall'inizio, lo scopo del codice di scrittura a mano è di elaborare o testare la logica di qualunque cosa tu stia programmando. È meglio quando ti concentri prima sulla risoluzione del problema.

Prendiamo un classico esempio da manuale: un programma per trovare l'ennesimo Numero di Fibonacci. Se dovessi scriverne uno schema semplice, sarebbe qualcosa del genere:

  1. Ottieni l'input.
  2. Calcola il numero di Fibonacci.
  3. Riassumi l'output.
  4. Stampa l'output.

Tutti i passaggi in quello schema sono essenziali; tuttavia, 1, 3 e 4 sono più obbligatori. Sono necessari ma non abbastanza importanti su cui concentrarsi subito.

È meglio iniziare a scrivere il codice per calcolare il numero di Fibonacci piuttosto che recuperare l'input. Avvolgilo in una funzione, quindi vai avanti e scrivi il codice in sequenza e annota una riga per chiamare quella funzione ove appropriato.

Dedica il tuo tempo a scrivere codice che si concentri sul cuore del problema.

I veri professionisti possono saltare avanti. Diciamo che ho un progetto per un cliente e devo lavorare con una geometria triangolare: ho due lati, angolo opposto e devo trovare la lunghezza del terzo lato. E ho deciso di scarabocchiare su carta per iniziare piuttosto che aprire il mio IDE.

Per prima cosa, disegnerei il triangolo, ovviamente (è qualcosa con cui ho molta esperienza, come puoi vedere). Scriverei alcune lunghezze e angoli del campione. Quindi scriverei la formula (complimenti per la ricerca online, di sicuro), e poi salterei direttamente al codice per la funzione.

Non ha senso che io scriva i passaggi obbligatori anche se ne avrò bisogno nel codice pronto per la produzione. Ma sarebbe diverso se dovessi scriverlo su un foglio delle risposte in un esame. Non posso saltare gli altri passaggi; tuttavia, posso ancora iniziare con il codice per la formula.

Pseudo-codice

Chris ha già scritto a articolo pratico sullo pseudo-codice che vi consiglio vivamente di dare una lettura solida.

Per tutti quei professionisti che hanno la sensazione che l'intero codice della scrittura a mano non sembri la tua tazza di tè ma potrebbero comunque essere curiosi se può aiutarti, allora pseudo-codice potrebbe essere l'equilibrio che stai cercando.

È simile a delineare il codice, come ho menzionato in uno dei passaggi precedenti. Tuttavia, è più breve e sembra più una codifica abbreviata. A volte viene anche chiamato "codice scheletro".

Ecco un rapido pseudo-codice per un layout di griglia CSS:

Grid
5 60px rows
6 100px columns

Non c'è molto da scrivere! Quindi, anche se mettere una matita su carta è eccellente per questo genere di cose, è altrettanto efficace, veloce ed economico annotare un po' di pseudocodice in qualunque programma tu stia usando.

Spazio e commenti

Credo che il codice sia composto per il 90% da parole chiave e per il 10% da schede. Senza spazi la leggibilità delle parole diminuisce. I rientri sono necessari anche per il codice scritto a mano. Tuttavia, per favore non usarlo per tutti i livelli perché la larghezza della carta ti limiterà. Usa gli spazi con giudizio, ma usali.

Carta gialla sfoderata con codice scritto a mano in corsivo con inchiostro nero.
Pregiato frammento OG, scritto con TLC extra

Se stai scrivendo codice per il tuo uso, credo anche che se hai seguito tutto ciò che ho menzionato finora e hai già annotato il tuo output e uno schema sulla pagina, potresti non aver nemmeno bisogno di includere commenti. I commenti ti dicono rapidamente cosa fa il seguente set di codice. Se hai già scritto e letto uno schema per il codice, i commenti sono note ridondanti.

Tuttavia, se il tuo giudizio dice di abbatterne uno, fallo. Aggiungilo sul lato destro del codice (dal momento che non sarai in grado di inserirlo tra le righe già scritte nel modo in cui potresti, ad esempio, VS Code). Usa barre, parentesi o frecce per indicare che si tratta di commenti.

Per i candidati che non sono sicuri di una certa sintassi, annota i commenti. In questo modo, almeno, fai sapere alla persona che valuta la tua carta la tua intenzione con quel codice formattato in modo errato. E usa solo i delimitatori corretti per denotare i commenti, ad esempio, sarebbero le barre in avanti per JavaScript.

Analogico vs. digitale

Come accennato in precedenza, tutto ciò che sto fornendo qui può essere un consiglio di codifica generico. Se non vuoi provare questo con carta fisica, funziona anche qualsiasi applicazione per prendere appunti.

Ma se hai intenzione di provare il percorso digitale, la mia raccomandazione è di provare a utilizzare qualcosa di diverso da un'app semplice per prendere appunti. Lavora con più strumenti digitali visivi: diagrammi di flusso, mappe mentali, wireframe, ecc. Possono aiutarti a visualizzare il risultato, i contorni e il codice stesso.

Non sono un gran cittadino digitale (tranne che per lavorare sul web e recentemente mi sono convertito alla lettura di e-book), quindi mi attengo ai taccuini fisici.

I miei strumenti preferiti per scrivere il codice

Qualsiasi matita e carta andrà bene! Ma ci sono molte opzioni là fuori e questi sono alcuni strumenti di scelta che uso:

Non esiste un modo di "scrivere" il codice

Spero, se non altro, che il mio piccolo modo di scrivere il codice con carta e matita ti faccia valutare il modo in cui già pianifichi e scrivi il codice. Mi piace sapere come gli altri sviluppatori affrontano il loro lavoro, e questo è il mio modo di darti una sbirciatina nel modo in cui faccio le cose.

Ancora una volta, niente qui è scientifico o un'arte esatta. Ma se vuoi provare la pianificazione del codice scritto a mano, ecco tutto ciò che abbiamo trattato in un bel elenco ordinato:

  1. Inizia scrivendo (con dati di esempio, se necessario) l'output del tuo codice.
  2. Scrivi uno schema per il codice. Si prega di mantenere i tre passaggi per progetti piccoli o meno complessi.
  3. Usa le notazioni a mano lunga. Gli sviluppatori che scrivono per se stessi possono usare notazioni abbreviate purché la scrittura sia leggibile e abbia senso per te quando ci si fa riferimento in seguito.
  4. Quando hai un vincolo di tempo, prendi in considerazione la possibilità di scrivere prima il codice che affronti il ​​cuore del problema. Successivamente, annota una chiamata a quel codice nel posto giusto nel tuo codice sequenziale.
  5. Se ti senti sicuro, prova a scrivere pseudocodice che affronta l'idea principale.
  6. Usa rientri e spazi appropriati e fai attenzione alla larghezza della carta.

Questo è tutto! Quando sarai pronto per provare a scrivere il codice a mano, spero che questo articolo ti renda facile iniziare. E se sei seduto per un esame o un colloquio, spero che questo ti aiuti a concentrarti sulla risposta giusta alle domande.

Timestamp:

Di più da Trucchi CSS