L'autre jour, j'ai interviewé un développeur JavaScript qui postulait pour un poste de direction. Un collègue, également présent lors de l'entretien, a demandé au candidat d'écrire une fonction qui ferait une requête HTTP et, en cas d'échec, de réessayer plusieurs fois.
Il a écrit le code directement au tableau, il suffirait donc de dessiner quelque chose d'approximatif. S'il avait simplement montré qu'il comprenait bien de quoi il s'agissait, nous aurions été très satisfaits. Mais malheureusement, il n’a pas réussi à trouver une solution satisfaisante. Ensuite, mettant cela sur le compte de l'enthousiasme, nous avons décidé de rendre la tâche un peu plus facile et lui avons demandé de transformer une fonction avec des rappels en une fonction construite sur des promesses.
Mais hélas. Oui, il était évident qu’il avait déjà rencontré un tel code. Il savait d'une manière générale comment tout fonctionnait là-bas. Tout ce dont nous avons besoin est une esquisse d’une solution qui démontre une compréhension du concept. Cependant, le code que le candidat a écrit au tableau était complètement absurde. Il avait une idée très vague de ce que contenaient les promesses en JavaScript et ne pouvait pas vraiment expliquer pourquoi elles étaient nécessaires. Pour un junior, cela aurait été pardonnable, mais il n'était plus adapté au poste de senior. Comment ce développeur serait-il capable de corriger les bugs dans une chaîne complexe de promesses et d’expliquer aux autres ce qu’il a fait exactement ?
Les développeurs considèrent que le code prêt à l'emploi va de soi
Au cours du processus de développement, nous rencontrons constamment des matériaux reproductibles. Nous transférons des fragments de code afin de ne pas avoir à les réécrire à chaque fois. En conséquence, en concentrant toute notre attention sur les éléments clés, nous considérons le code fini avec lequel nous travaillons comme une évidence - nous supposons simplement que tout fonctionnera comme il se doit.
Et généralement, cela fonctionne, mais lorsque les choses se compliquent, comprendre les mécanismes est plus que payant.
Ainsi, notre candidat au poste de développeur senior considérait les objets prometteurs comme allant de soi. Il avait probablement une idée de la façon de les gérer lorsqu'ils apparaissent quelque part dans le code de quelqu'un d'autre, mais il n'a pas compris le principe général et n'a pas pu le répéter lui-même lors de l'entretien. Peut-être qu'il s'est 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 – et nous l'avons probablement tous fait à un moment donné. Ils ont simplement mémorisé un morceau de code pour pouvoir l'utiliser plus tard dans leur travail, tout en n'ayant qu'une idée générale de la façon dont tout fonctionnait là-bas. Mais si le développeur comprenait vraiment le concept, il n'aurait à se souvenir de rien - il saurait simplement comment le faire et reproduirait facilement tout ce dont il a besoin dans le code.
Retour aux racines
En 2012, alors que la domination des frameworks front-end n'était pas encore établie, jQuery dirigeait le monde et j'ai lu le livre , rédigé par John Resig, créateur de jQuery.
Le livre enseigne au lecteur comment créer son propre jQuery à partir de zéro et fournit un aperçu unique du processus de 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 j'aurais pu penser à tout cela moi-même. Les étapes décrites par l'auteur semblaient si logiques, si claires que j'ai sérieusement commencé à penser que je pourrais facilement créer jQuery si je m'y mettais.
Bien sûr, en réalité, je n'aurais pas pu faire quelque chose comme ça - j'aurais décidé que c'était insupportablement difficile. Mes propres solutions me sembleraient trop simples et naïves pour fonctionner, et j’abandonnerais. Je classerais jQuery comme des choses évidentes, au bon fonctionnement desquelles il suffit de croire aveuglément. Par la suite, je ne perdrais guère de temps à me plonger dans la mécanique de cette bibliothèque, mais je l'utiliserais simplement comme une sorte de boîte noire.
Mais la lecture de ce livre a fait de moi une personne différente. J'ai commencé à lire le code source et j'ai découvert que la mise en œuvre de nombreuses solutions était en fait très transparente, voire évidente. Non, bien sûr, penser seul à quelque chose comme ça est une autre histoire. Mais c’est l’étude du code d’autres personnes et la reproduction de solutions existantes qui nous aident à trouver quelque chose qui nous est propre.
L'inspiration que vous gagnerez et les modèles que vous commencerez à remarquer vous changeront en tant que développeur. Vous constaterez que cette merveilleuse bibliothèque que vous utilisez constamment et que vous avez l'habitude de considérer comme un artefact magique ne fonctionne pas du tout sur la magie, mais résout simplement un problème de manière laconique et ingénieuse.
Parfois, vous devrez examiner le code et l'analyser étape par étape, mais c'est ainsi que, en avançant par petites étapes cohérentes, vous pourrez répéter le chemin de l'auteur vers la solution. Cela vous permettra d’approfondir le processus de codage et vous donnera plus de confiance pour trouver vos propres solutions.
Quand j’ai commencé à travailler avec des promesses, cela m’a semblé être de la pure magie. Puis j’ai découvert qu’ils étaient basés sur les mêmes rappels, et mon monde de la programmation a basculé. Donc le modèle, dont le but est de nous épargner les 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 ne s'agit pas d'un morceau de code abstrus devant moi, dont je ne comprendrai jamais la complexité prohibitive de ma vie. Ce ne sont que des modèles qui peuvent être compris sans problème avec la curiosité et une immersion profonde. C’est ainsi que les gens apprennent à coder et évoluent en tant que développeurs.
Réinventez cette roue
Alors n'hésitez plus et réinventez les roues : écrivez votre propre code de liaison de données, créez une promesse maison ou même créez votre propre solution de gestion d'état.
Peu importe que personne n'utilise jamais tout cela, mais vous savez maintenant comment le faire. Et si vous avez la possibilité d’utiliser ultérieurement de tels développements dans vos propres projets, c’est généralement très bien. Vous pourrez les développer et apprendre autre chose.
Le but ici n’est pas d’envoyer votre code en production, mais d’apprendre quelque chose de nouveau. Écrire votre propre implémentation d'une solution existante est un excellent moyen d'apprendre auprès des meilleurs programmeurs et ainsi de perfectionner vos compétences.
Source: habr.com