Pourquoi (et comment) j'écris du code avec un crayon et du papier

Si la pensée du code d'écriture manuscrite semble idiote, cela pourrait vous surprendre de savoir que c'est inévitable. Si vous n'êtes pas sûr, pensez au dernier entretien d'embauche que vous avez fait et rappelez-vous qu'il n'y avait pas d'ordinateur dans la salle d'entretien - juste vos intervieweurs, une feuille de papier vierge et un stylo à bille bleu.

Pour les étudiants parmi vous, c'est encore plus important car vos notes dépendent des lignes de code que vous avez stratégiquement insérées dans l'espace disponible de votre feuille de réponses.

Et pas seulement cela, les programmeurs expérimentés peuvent vous indiquer le paquet de feuilles A4 qu'ils avaient retirées de la photocopieuse de bureau pour griffonner un algorithme particulièrement complexe sur lequel ils travaillaient.

Donc, que vous soyez un étudiant en examen, un candidat potentiel à un entretien d'embauche ou quelqu'un qui souhaite résoudre ses impasses de programmation, j'espère que cet article vous aidera lorsque vous mettez votre stylo sur le papier pour coder.

Bien que je me concentre sur l'aspect analogique de l'écriture de code, vous pouvez appliquer ces étapes au codage sous n'importe quelle forme ou langue. Considérez donc cela comme une directive de codage générique qui fonctionne spécifiquement pour moi mais qui peut également vous être très utile dans votre travail.

Pourquoi l'écrire ?

Avant de commencer, il est essentiel de comprendre que personne ne s'attend à ce que vous notiez du code prêt pour la production dans un cahier. Ce n'est pas comme si vous pouviez déposer cela dans un éditeur de code et le compiler sans erreur. Si l'objectif était de produire un code parfait, vous seriez assis devant un ordinateur dans les salles d'entretien et les salles d'examen.

Le but du code d'écriture manuscrite est de travailler à travers la logique à l'avance. Il y a un désir de "entrer dans le navigateur" dès que possible dans la conception, mais il y a une sagesse conventionnelle dans l'esquisse des conceptions à la main. Un support peu fidèle encourage une expérimentation rapide et des erreurs peu coûteuses.

Il en va de même pour le code, principalement lors de l'élaboration de la syntaxe et de la sémantique. Cela dit, obtenir la syntaxe et la sémantique correctes est toujours un point positif, mais pas le seul objectif de tout l'exercice d'écriture.

Voyons par où commencer en ce qui concerne le code d'écriture manuscrite.

Connaître votre question

Lors de ma dernière année à l'université, je n'ai pas pu faire de stage ni même assister à des entretiens sur le campus pour des raisons de santé. En conséquence, mon tout premier entretien d'embauche était assez littéral avec des enjeux élevés.

Quand je regarde en arrière maintenant, l'interview a été assez facile. Mais n'ayant jamais assisté à un avant, j'étais anxieux au-delà de toute raison. La première chose que les enquêteurs ont demandé à propos de la programmation était de savoir si je pouvais produire un triangle inversé composé d'astérisques. Comme je l'ai dit, c'était facile - rien de plus for la boucle ne peut pas gérer, non? Mais comme je l'ai dit, mon anxiété était également à son comble.

J'ai pris une profonde inspiration, j'ai appuyé ma paume contre la feuille de papier vierge qu'ils m'avaient préparée, je l'ai glissée aussi lentement que possible vers moi sur la table (pour gagner du temps, bien sûr), j'ai cliqué sur le stylo, puis j'ai fait quelque chose droite.

J'ai d'abord dessiné un triangle inversé composé d'astérisques. C'est ainsi que j'ai trouvé les pieds sur terre pour commencer à répondre à leur question.

J'ai vu des développeurs par ailleurs brillants se tromper simplement parce qu'ils ne saisissent jamais pleinement ce qu'ils résolvent.

Les questions avec lesquelles nous travaillons ne sont pas comme les questions que les physiciens ou les mathématiciens résolvent. Ils obtiennent un ensemble de paramètres et trouvent ceux qui manquent ; nos questions sont aussi nos résultats. On nous dit déjà quels sont nos résultats - nous devons trouver comment les atteindre. C'est pourquoi il est impératif de bien connaître la question car vous verrez le résultat.

Écrire ou dessiner ce que vous voulez produire est l'une des meilleures façons de commencer votre codage. Je comprends que dans notre industrie en évolution rapide, on s'attend à ce que nous devions sauter directement dans la programmation en exécutant une démo "hello world". Et c'est formidable de vous familiariser avec une syntaxe inconnue et de vous débarrasser de votre anxiété à l'idée d'essayer quelque chose de nouveau.

Mais quand quelqu'un vous pose une question et vous donne un résultat sur lequel travailler, ne serait-il pas préférable de le poser d'abord ? Cette question/résultat n'est pas seulement votre point de départ mais aussi votre point de référence. À n'importe quelle étape de votre codage, vous pouvez l'examiner pour vous assurer que vous y travaillez et que vous êtes sur la bonne voie.

Donc, que ce soit dans vos feuilles de réponses ou dans ce papier A4 vierge que vous êtes sur le point d'écrire, commencez par prendre une seconde et notez ce que vous essayez de produire. Vous pouvez le mettre dans les marges ou dans un coin si vous ne voulez pas qu'il fasse partie de votre réponse. Assurez-vous simplement que c'est un endroit où vous pouvez continuer à le référencer.

Décrivez votre code

Cette étape est comme une épée à double tranchant. Cela peut vous donner une feuille de route pour votre programme ou vous faire perdre votre temps. Mon travail consiste à m'assurer que c'est le premier.

Alors, avant tout, j'aime dire : décrire le code n'est pas nécessaire si la portée de votre problème ou de votre question est petite. Encore une fois, cette pratique n'est ni prescriptive ni universelle pour tous les projets ou situations. Imaginez que je sois votre intervieweur et que je vous demande d'écrire comment centrer un élément dans une page Web en utilisant CSS de toutes les manières possibles. Vous n'aurez pas exactement besoin d'un plan pour cela. Les extraits de code sont relativement petits pour chaque méthode.

Mais maintenant, disons que je vous demande d'écrire une application Web qui capture les signatures des utilisateurs via une interface à écran tactile, puis enregistre la signature sur le serveur. Pas si simple, non ? Vous avez plus d'une chose à comprendre. Peut-être qu'un petit aperçu peut aider.

1. Interface utilisateur pour capturer la signature - HTML Canvas ? WebGL ?
2. Désactiver les événements de pointeur sur le reste de la page Web lorsque l'utilisateur signe
3. Convertir et enregistrer l'image capturée dans un fichier PNG — JS
4. Ensuite, convertissez-le en blob (peut-être) et enregistrez-le dans la table de données du journal du visiteur.

J'ai écrit une séquence approximative d'actions que je pense devoir coder. Cela aurait pu être plus court ou plus long, selon ce que j'en attendais.

Je recommande fortement de décrire le code pour les projets clients. Écrivez le contour avec vos besoins d'utilisateur ou au dos des wireframes que vous avez imprimés.

Votre aperçu rapide des puces vous donne une carte, une liste de tâches et une liste de contrôle à vérifier lorsque vous atteignez la fin du projet - à peu près le résumé de l'ensemble de votre projet dans une liste basse fidélité. Il peut également devenir un modèle pour démarrer votre prochain projet similaire.

Mais comme je l'ai déjà dit, cette étape est comme une épée à double tranchant. Vous devrez être bref pour les candidats et les personnes interrogées lorsqu'il y a des contraintes de temps.

Si vous ne savez pas par où commencer, écrivez seulement trois fonctions essentielles que vous devrez coder dans votre application, et si vous avez le temps, faites-en cinq.

Mais c'est à peu près tout. Passez le moins de temps possible là-dessus et ne vous souciez pas des détails. Le contour ne va pas vous marquer des points supplémentaires. Il est là uniquement pour vous aider à vous assurer que tout est couvert. Il capture votre réaction instinctive initiale et vous permet de rester honnête tout au long de la vie du projet.

Longue vs sténographie

Il est temps de commencer à coder. Alors, qu'est-ce que tu écris ? "Chambres" ou "border-radius"; "div -> pou<div><p></div></p>"; "pl()ouprintln()"; "q()ouquerySelector()« ?

Si quelqu'un d'autre note votre code, vous n'avez pas le choix. Oubliez les abréviations, les pseudo-codes, les raccourcis Emmet et toute autre forme d'écriture abrégée. Sinon, il n'y a aucune raison de supposer que quiconque lit ceci sait ce que signifient vos abréviations.

C'est vraiment comme tu veux.

Si vous avez perdu le contact avec l'écriture à la main - et beaucoup d'entre nous l'ont fait - il vaut mieux ne pas aller trop loin avec les notations manuscrites, car elles deviennent fastidieuses. En même temps, il n'y a rien de tel que d'être trop frugal avec votre écriture. Pas si vous voulez pouvoir y revenir un jour et comprendre ce que vous avez écrit.

J'ai un fichier ouvert dans mon application de prise de notes et un bloc-notes ligné sur mon bureau où j'écris des extraits de code que je souhaite enregistrer pour référence ultérieure. Ils ne sont pas organisés, juste un long flux d'extraits. C'est pourquoi, lorsque je parcours des notes plus anciennes, je ne saurais pas ce que je voulais écrire si je ne les avais pas écrites clairement.

J'oublie tout le temps les syntaxes. Par exemple, j'utilise la notation fléchée pour les fonctions JavaScript depuis son introduction (parce qu'elle est plus courte), et je suis à peu près sûr que si quelqu'un me demande soudainement de définir une fonction en utilisant le function mot-clé, je pourrais même égarer les parenthèses ou le nom de la fonction, provoquant une erreur de syntaxe.

Il n'est pas rare que nous oubliions des syntaxes que nous n'avons pas utilisées depuis un moment. C'est pourquoi il est préférable d'écrire clairement vos notes lorsque vous savez que vous en aurez besoin pour référence future.

Le flux de code non séquentiel

Contrairement à la dernière étape, qui ne s'applique pas à ceux d'entre vous, les personnes interrogées et les personnes testées, celle-ci s'adresse spécialement à vous.

La plupart des langages de programmation sont interprétés, compilés et exécutés de sorte que le code parfois pré-écrit dans la source est exécuté plus tard lorsqu'il est appelé. Nous le faisons en JavaScript, par exemple, avec l'appel de fonction — les fonctions peuvent être définies initialement, puis exécutées plus tard. Les candidats et les personnes interrogées peuvent l'utiliser pour commencer à travailler sur le point critique de votre réponse en premier.

Comme je l'ai dit dès le début, le but du code d'écriture manuscrite est de travailler ou de tester la logique de tout ce que vous programmez. Il est préférable que vous vous concentriez d'abord sur la résolution de ce problème.

Prenons un exemple de manuel classique - un programme pour trouver le nième Numéro de Fibonacci. Si je devais écrire un schéma simple pour cela, ce serait quelque chose comme ceci :

1. Obtenez l'entrée.
2. Calculez le nombre de Fibonacci.
3. Résumez la sortie.
4. Imprimez la sortie.

Toutes les étapes de ce schéma sont essentielles ; cependant, 1, 3 et 4 sont plus obligatoires. Ils sont nécessaires mais pas assez importants pour se concentrer sur tout de suite.

Il est préférable de commencer à écrire le code pour calculer le nombre de Fibonacci plutôt que de récupérer l'entrée. Enveloppez-le dans une fonction, puis continuez et écrivez le code de manière séquentielle et écrivez une ligne pour appeler cette fonction le cas échéant.

Passez votre temps à écrire du code qui se concentre sur le cœur du problème.

Les vrais professionnels peuvent passer devant. Disons que j'ai un projet client et que je dois travailler avec une géométrie triangulaire - j'ai deux côtés, un angle opposé et je dois trouver la longueur du troisième côté. Et j'ai décidé de griffonner sur du papier pour commencer plutôt que d'ouvrir mon IDE.

Tout d'abord, je dessinerais le triangle, bien sûr (c'est quelque chose avec lequel j'ai beaucoup d'expérience, comme vous pouvez le constater). J'écrirais quelques exemples de longueurs et d'angles. Ensuite, j'écrirais la formule (compliments de la recherche en ligne, bien sûr), puis je passerais directement au code de la fonction.

Il est inutile que j'écrive les étapes obligatoires même si j'en aurai besoin dans du code prêt pour la production. Mais ce serait différent si je devais écrire cela sur une feuille de réponses à un examen. Je ne peux pas sauter les autres étapes ; cependant, je peux toujours commencer avec le code de la formule.

Pseudo-code

Chris a déjà écrit un article pratique sur le pseudo-code que je vous recommande fortement de donner une lecture solide.

Pour tous ces professionnels qui ont l'impression que tout le code d'écriture manuscrite ne semble pas être votre tasse de thé, mais qui pourraient quand même être curieux de savoir si cela peut vous aider, alors pseudo-code pourrait être l'équilibre que vous recherchez.

Cela revient à décrire le code, comme je l'ai mentionné dans l'une des étapes précédentes. Cependant, il est plus bref et ressemble plus à un codage abrégé. Il est parfois aussi appelé "code squelette".

Voici un pseudo-code rapide pour une mise en page de grille CSS :

Grid
5 60px rows
6 100px columns

Il n'y a pas grand chose à écrire ! Ainsi, même si mettre un crayon sur papier est excellent pour ce genre de chose, il est tout aussi efficace, rapide et peu coûteux de noter un pseudo-code dans n'importe quel programme que vous utilisez.

Espace et commentaires

Je crois que le code est composé à 90 % de mots-clés et à 10 % d'onglets. Sans espaces, la lisibilité des mots diminue. Les indentations sont également nécessaires pour le code manuscrit. Cependant, veuillez ne pas l'utiliser pour chaque niveau car la largeur du papier vous limitera. Utilisez les espaces judicieusement, mais utilisez-les.

Si vous écrivez du code pour votre usage, je pense également que si vous avez suivi tout ce que j'ai mentionné jusqu'à présent et que vous avez déjà écrit votre sortie et un aperçu sur la page, vous n'aurez peut-être même pas besoin d'inclure des commentaires. Les commentaires vous indiquent rapidement ce que fait l'ensemble de code suivant. Si vous avez déjà écrit et lu un plan pour le code, les commentaires sont des notes redondantes.

Cependant, si votre jugement vous dit d'en déposer un, alors faites-le. Ajoutez-le sur le côté droit du code (puisque vous ne pourrez pas l'insérer entre des lignes déjà écrites comme vous le pourriez, par exemple, dans VS Code). Utilisez des barres obliques, des crochets ou des flèches pour indiquer qu'il s'agit de commentaires.

Pour les candidats qui ne sont pas sûrs d'une certaine syntaxe, notez les commentaires. De cette façon, au moins, vous informez la personne qui note votre article de votre intention avec ce code au format incorrect. Et n'utilisez que les délimiteurs corrects pour indiquer les commentaires - par exemple, ce serait les barres obliques pour JavaScript.

Analogique vs numérique

Comme je l'ai mentionné plus tôt, tout ce que je fournis ici peut être un conseil de codage générique. Si vous ne voulez pas essayer cela avec du papier physique, n'importe quelle application de prise de notes fonctionne également.

Mais si vous allez essayer la voie numérique, ma recommandation est d'essayer d'utiliser autre chose qu'une simple application de prise de notes. Travaillez avec des outils numériques plus visuels - diagrammes de flux, cartes mentales, wireframes, etc. Ils peuvent vous aider à visualiser votre résultat, les contours et le code lui-même.

Je ne suis pas vraiment un citoyen numérique (sauf pour travailler sur le Web et me convertir récemment à la lecture de livres électroniques), donc je m'en tiens aux cahiers physiques.

Mes outils préférés pour le code d'écriture manuscrite

N'importe quel crayon et papier fera l'affaire ! Mais il existe de nombreuses options, et voici quelques outils de choix que j'utilise :

Il n'y a pas de méthode "d'écriture" pour coder

J'espère, au moins, que ma petite façon d'écrire du code avec un crayon et du papier vous fera évaluer la façon dont vous planifiez et écrivez déjà du code. J'aime savoir comment les autres développeurs abordent leur travail, et c'est ma façon de vous donner un aperçu de ma façon de faire les choses.

Encore une fois, rien ici n'est scientifique ou un art exact. Mais si vous voulez essayer la planification de code manuscrite, voici tout ce que nous avons couvert dans une belle liste ordonnée :

1. Commencez par écrire (avec des exemples de données, si nécessaire) la sortie de votre code.
2. Rédigez un plan pour le code. Veuillez vous en tenir à trois étapes pour les petits projets ou ceux qui sont moins complexes.
3. Utilisez des notations longues. Les développeurs qui écrivent pour eux-mêmes peuvent utiliser des notations abrégées tant que l'écriture est lisible et a du sens pour vous lorsque vous vous y référerez plus tard.
4. Lorsque vous êtes soumis à une contrainte de temps, envisagez d'écrire d'abord le code qui s'attaque au cœur du problème. Plus tard, notez un appel à ce code au bon endroit dans votre code séquentiel.
5. Si vous vous sentez en confiance, essayez d'écrire un pseudo-code traitant de l'idée principale.
6. Utilisez des indentations et des espaces appropriés - et faites attention à la largeur du papier.

C'est ça! Lorsque vous serez prêt à essayer d'écrire du code à la main, j'espère que cet article vous facilitera la tâche. Et si vous vous asseyez pour un examen ou un entretien, j'espère que cela vous aidera à vous concentrer sur les bonnes questions.