L'autre jour, j'ai interviewé un développeur JavaScript qui prétendait être un senior. Un collègue qui était également présent à l'entretien a demandé au candidat d'écrire une fonction qui produirait une requête HTTP et, en cas d'échec, de réessayer plusieurs fois.
Il a écrit le code immédiatement au tableau, il suffirait donc de représenter quelque chose d'approximatif. S'il montrait simplement qu'il comprenait bien l'essence de la question, nous serions entièrement satisfaits. Mais, malheureusement, il n'a pas pu trouver de solution réussie. Ensuite, en écrivant cela comme excitation, nous avons décidé d'alléger un peu la tâche et lui avons demandé de créer une fonction basée sur les promesses d'une fonction avec des rappels.
Mais hélas. Oui, il était évident qu'il avait déjà rencontré un code similaire auparavant. En général, il savait comment tout fonctionnait là-bas. Un croquis d'une solution qui démontrerait une compréhension du concept suffirait. Cependant, le code que le candidat a écrit au tableau était complètement insensé. Il avait une idée extrêmement vague de ce qu'étaient les promesses JavaScript et il ne pouvait pas vraiment expliquer pourquoi elles étaient nécessaires. Pour le junior, cela aurait été excusable, mais le poste du senior n'était plus tiré au sort. Comment ce développeur parviendrait-il à éliminer les bogues d'une chaîne complexe avec des promesses et à expliquer aux autres ce qu'il a fait exactement?
Les développeurs considèrent que le code prêt à l'emploi va de soi
Dans le processus de développement, nous rencontrons constamment des matériaux reproductibles. Nous transférons des fragments de code afin de ne pas avoir à les enregistrer à chaque fois. Par conséquent, en concentrant toute notre attention sur les parties clés, nous considérons le code fini avec lequel nous travaillons comme quelque chose qui va de soi - nous supposons simplement que tout fonctionnera comme il le devrait.
Et généralement, cela fonctionne vraiment, mais lorsque des difficultés surviennent, une compréhension de sa mécanique est plus que payante.
Ainsi, notre candidat au poste de développeur senior considérait que les objets promis étaient évidents. Il a probablement imaginé comment les traiter lorsqu'ils se rencontraient quelque part dans le code de quelqu'un d'autre, mais il ne comprenait pas le principe général et ne pouvait pas le répéter lui-même lors de l'entretien. Il s'est peut-être souvenu du fragment par cœur - ce n'est pas si difficile:
return new Promise((resolve, reject) => { functionWithCallback((err, result) => { return err ? reject(err) : resolve(result); }); });
Je l'ai fait aussi - oui, nous l'avons tous probablement fait un jour. Ils ont simplement mémorisé un morceau de code, afin de pouvoir ensuite l'utiliser dans leur travail, tout en imaginant de manière générale comment tout fonctionne là-bas. Mais si le développeur comprenait vraiment le concept, il n'aurait rien à mémoriser - il saurait simplement comment le faire et reproduirait facilement tout ce qui est nécessaire dans le code.
Aller aux racines
En 2012, alors que la domination des frameworks frontaux n'était pas encore établie, le monde des règles jQuery et moi avons lu le livre
Secrets of the JavaScript Ninja , écrit par John Rezig, créateur de jQuery.
Le livre enseigne au lecteur comment créer votre propre jQuery à partir de zéro et offre une occasion unique de se joindre à la réflexion qui a conduit à la création de la bibliothèque. Ces dernières années, jQuery a perdu son ancienne popularité, mais je recommande toujours fortement le livre. Ce qui m'a le plus frappé chez elle, c'est le sentiment persistant que je pouvais penser à tout cela moi-même. Les étapes que l'auteur a peintes semblaient si logiques, si compréhensibles qu'il me semblait sérieusement que je pouvais facilement créer jQuery, si seulement je me mettais au travail.
Bien sûr, en réalité, je n'aurais pas maîtrisé quelque chose comme ça - j'aurais décidé que c'était extrêmement difficile. Mes propres décisions me sembleraient trop simples et naïves pour travailler, et j'abandonnerais. J'attribuerais jQuery à des choses qui vont de soi, dont il vous suffit de croire aveuglément le bon fonctionnement. Par la suite, je n'aurais guère perdu de temps à me plonger dans la mécanique de cette bibliothèque, mais l'aurais simplement utilisée comme une sorte de boîte noire.
Mais apprendre à connaître ce livre a fait de moi une personne différente. J'ai commencé à lire le code source et j'ai constaté que la mise en œuvre de nombreuses solutions est en fait très transparente, voire évidente. Non, bien sûr, de penser à une telle chose vous-même - cela vient d'un autre opéra. Mais c’est l’étude du code de l’autre et la reproduction des solutions existantes qui nous aident à trouver quelque chose qui nous appartient.
L'inspiration que vous dessinez et les modèles que vous commencez à remarquer vous changeront en tant que développeur. Vous constaterez que la belle bibliothèque que vous utilisez constamment et que vous êtes habitué à considérer comme un artefact magique, ne fonctionne pas du tout avec la magie, mais résout simplement le problème de manière succincte et ingénieuse.
Parfois, il sera nécessaire de parcourir le code, de le démonter étape par étape, mais tout comme cela, en se déplaçant par petites étapes consécutives, vous pouvez répéter le chemin de l'auteur vers la solution. Cela vous permettra d'approfondir le processus d'écriture de code et de donner plus de confiance lors de la recherche de vos propres solutions.
Quand j'ai commencé à travailler avec des promesses, il me semblait que c'était de la pure magie. Ensuite, j'ai découvert qu'ils étaient basés sur les mêmes rappels, et mon monde de programmation a basculé. Autrement dit, un modèle dont le but est de nous sauver des rappels est lui-même implémenté à l'aide de rappels?!
Cela m'a aidé à regarder la question avec des yeux différents et à réaliser qu'il n'y a pas de morceaux de code abstrus devant moi, la complexité transcendante que je ne comprendrai jamais dans ma vie. Ce ne sont que des modèles qui peuvent être facilement compris avec une curiosité et une immersion profonde. C'est ainsi que les gens apprennent à programmer et à grandir en tant que développeurs.
Réinventez cette roue
Alors, n'hésitez pas à réinventer les roues: écrivez le code de la liaison de données vous-même, créez une promesse locale ou même prenez une décision pour gérer vos conditions de vos propres mains.
Peu importe que personne n'utilise jamais tout cela - mais maintenant vous pouvez le faire. Et si vous avez la possibilité d'utiliser ultérieurement de tels développements dans vos propres projets, alors c'est génial. Vous pouvez les développer et apprendre autre chose.
Il ne s'agit pas ici d'envoyer votre code en production, mais d'apprendre quelque chose de nouveau. Prescrire la mise en œuvre d'une solution existante par vous-même est un excellent moyen d'apprendre des meilleurs programmeurs et ainsi d'affiner vos compétences.