Récemment, j'ai mené un entretien avec un développeur JavaScript qui postulait pour un poste de senior. Un collègue, également présent lors de l'entretien, a demandé au candidat d'écrire une fonction qui effectuerait une requête HTTP et, en cas d'échec, essaierait plusieurs fois.
Il écrivait le code directement sur le tableau, donc il suffisait de dessiner quelque chose de approximatif. S'il avait simplement montré qu'il comprenait bien le principe, nous aurions été tout à fait satisfaits. Mais, malheureusement, il ne parvenait pas à trouver une solution adéquate. Alors, en mettant cela sur le compte du stress, nous avons décidé de simplifier la tâche un peu et lui avons demandé de transformer la fonction avec des rappels en une fonction basée sur des promesses.
Mais hélas. Oui, il était évident qu'il avait déjà vu ce genre de code auparavant. Il savait en gros comment cela fonctionnait. Un simple croquis de solution montrant qu'il comprenait le concept nous aurait suffi. Cependant, le code que le candidat écrivait sur le tableau était complètement absurde. Il avait une idée extrêmement floue de ce que sont les promesses en JavaScript et ne pouvait pas vraiment expliquer pourquoi elles sont nécessaires. Pour un junior, cela aurait encore été compréhensible, mais pour un poste de senior, ce n'était pas acceptable. Comment ce développeur aurait-il pu résoudre des bugs dans une chaîne complexe de promesses et expliquer aux autres ce qu'il avait fait ?
Les développeurs considèrent le code prêt comme une évidence.
Dans le processus de développement, nous faisons constamment face à des matériaux reproductibles. Nous déplaçons des morceaux de code pour ne pas avoir à les réécrire à chaque fois. Ainsi, en concentrant toute notre attention sur les parties clés, nous voyons le code prêt avec lequel nous travaillons comme quelque chose d'évident – nous supposons simplement qu'il fonctionnera comme il se doit.
Et en général, cela fonctionne vraiment, mais lorsque des difficultés surviennent, comprendre sa mécanique en vaut largement la peine.
Ainsi, notre candidat pour le poste de développeur senior considérait les objets promise comme évidents. Il devait imaginer comment les gérer lorsqu'ils apparaissent dans du code d'un autre, mais il ne comprenait pas le principe général et n'a pas pu le reproduire lors de l'entretien. Peut-être avait-il mémorisé un extrait 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 jour. Nous apprenions simplement un morceau de code pour l'utiliser ensuite au travail, n'ayant qu'une idée générale de son fonctionnement. Mais si un développeur comprenait vraiment le concept, il n'aurait rien à mémoriser - il saurait simplement comment cela fonctionne et reproduirait tout ce qu'il faut dans le code sans effort.
Retournez à l'origine
En 2012, quand le règne des frameworks front-end n'était pas encore installé, jQuery dominait le monde et je lisais un livre , écrit par John Resig, le créateur de jQuery.
Le livre enseigne au lecteur comment créer son propre jQuery à partir de zéro et offre une occasion unique de comprendre le cheminement de pensée qui a conduit à la création de la bibliothèque. Bien que jQuery ait perdu de sa popularité ces dernières années, je recommande tout de même ce livre. Ce qui m'a le plus frappé, c'est ce sentiment persistant que j'aurais pu y penser moi-même. Les étapes décrites par l'auteur semblaient tellement logiques, tellement claires que j'ai sérieusement commencé à croire que je pourrais facilement créer jQuery si je m'y mettais.
Bien sûr, dans la réalité, je n'aurais rien accompli de tel - je penserais que c'était trop difficile. Mes propres solutions me sembleraient trop simples et naïves pour fonctionner, et j'abandonnerais. Je considérerais jQuery comme quelque chose d'évident dans lequel il faut croire aveuglément. Par la suite, il est peu probable que je perde du temps à comprendre la mécanique de cette bibliothèque et je l'utiliserais simplement comme une boîte noire.
Mais découvrir ce livre m'a changé. J'ai commencé à examiner le code source et j'ai découvert que la mise en œuvre de nombreuses solutions est en réalité très claire, voire évidente. Non, bien sûr, parvenir à un tel résultat par soi-même relève d'un autre domaine. Mais l'étude du code des autres et la reproduction de solutions déjà existantes nous aident à inventer quelque chose de nouveau.
L'inspiration que vous tirerez et les schémas que vous commencerez à remarquer vous transformeront en tant que développeur. Vous découvrirez que cette magnifique bibliothèque que vous utilisez constamment, et que vous avez pris l'habitude de considérer comme un artefact magique, fonctionne en réalité non pas grâce à la magie, mais résout simplement un problème de manière concise et astucieuse.
Parfois, vous devrez vous attarder sur le code, en l'examinant pas à pas, mais c'est exactement ainsi, en avançant par petites étapes successives, que vous pourrez reproduire le chemin de l'auteur vers la solution. Cela vous permettra de plonger plus profondément dans le processus d'écriture de code et vous donnera plus de confiance dans la recherche de vos propres solutions.
Quand j'ai commencé à travailler avec des promesses, j'avais l'impression que c'était de la magie pure. Puis j'ai appris que leur fonctionnement repose sur les mêmes callbacks, et mon univers de développeur a été bouleversé. C'est-à-dire que le schéma dont le but est de nous libérer des callbacks est en réalité réalisé grâce à des callbacks ?!
Cela m'a aidé à voir les choses sous un autre angle et à réaliser que je n'avais pas devant moi de morceaux de code obscurs d'une complexité insurmontable. Ce ne sont que des schémas que l'on peut comprendre facilement avec la curiosité appropriée et une immersion profonde. C'est ainsi que les gens apprennent à programmer et grandissent en tant que développeurs.
Réinventez la roue.
N'hésitez pas à réinventer des roues : écrivez vous-même le code pour lier des données, créez une promesse maison ou même élaborez votre propre solution pour la gestion des états.
Peu importe que personne n'utilise cela un jour – vous savez maintenant le faire. Et si vous avez l'occasion d'utiliser ces travaux dans vos propres projets par la suite, c'est encore mieux. Vous pourrez les développer et apprendre encore plus.
L'idée ici n'est pas d'envoyer votre code en production, mais d'apprendre quelque chose de nouveau. Écrire vous-même l'implémentation d'une solution existante est un excellent moyen d'apprendre des meilleurs programmeurs et de perfectionner votre art.
Source : habr.com
