Le vide que les jours de JavaScript de LeetCode comblent réellement

La plupart des défis de codage vous apprennent à résoudre des énigmes. Le plan d'étude 30 jours de JavaScript de LeetCode fait quelque chose de différent : il vous montre comment les pièces d'un puzzle peuvent se transformer en briques, prêtes à construire des projets du monde réel.

Cette distinction est importante. Lorsque vous résolvez un problème algorithmique typique, vous entraînez votre esprit à penser de manière abstraite. Mais lorsque vous implémentez une fonction anti-rebond¹ ou créez un émetteur d'événements², vous apprenez comment fonctionne un vrai logiciel.

J'ai découvert cela en relevant moi-même les défis. L’expérience ressemblait moins à la résolution d’énigmes qu’à l’archéologie – découvrir des concepts JavaScript spécifiques et modernes. Chaque section s'est concentrée sur un autre élément des fonctionnalités modernes de JS.

La particularité de ce plan d'étude est qu'il ne vous apprendra pas JavaScript. En fait, je pense que vous devez déjà assez bien connaître JavaScript pour en bénéficier. Ce qu'il enseigne à la place, c'est comment JavaScript est réellement utilisé pour résoudre de vrais problèmes d'ingénierie.

Considérez le défi Memoize³. En apparence, il s'agit de mettre en cache les résultats des fonctions. Mais ce que vous apprenez vraiment, c'est pourquoi des bibliothèques comme React ont besoin d'une mémorisation pour gérer efficacement le rendu des composants. Ou prenez le problème Debounce¹ : il ne s'agit pas seulement de mettre en œuvre des retards ; cela vous aide à comprendre, de première main, pourquoi chaque framework frontend moderne, ascenseur et fondamentalement tout système doté d'une interface utilisateur interactive, a besoin de ce modèle.

Cette concentration sur les modèles pratiques plutôt que sur les bases du langage crée une contrainte intéressante ; vous devez occuper l'une des deux positions suivantes pour en bénéficier :

1. Vous comprenez les fondamentaux de CS (en particulier les structures de données et les algorithmes) et êtes à l'aise avec JavaScript
2. Vous êtes fort en théorie CS et avez déjà été exposé à JavaScript

Relier CS et génie logiciel

Quelque chose d'étrange se produit entre l'apprentissage de l'informatique et la pratique du génie logiciel. La transition donne l'impression d'apprendre la théorie des échecs pendant des années, pour ensuite se retrouver à jouer à un jeu complètement différent - un jeu où les règles ne cessent de changer et où la plupart des mouvements ne figurent dans aucun livre.

Dans CS, vous apprenez comment fonctionne un arbre binaire. En génie logiciel, vous passez des heures à déboguer votre API, à essayer de comprendre pourquoi la mise en cache des réponses ne fonctionne pas. De loin, le chevauchement entre ces mondes peut sembler bien plus important qu’il ne l’est en réalité. Il existe une lacune qui peut souvent choquer les diplômés en CS lorsqu'ils débutent leur carrière. Malheureusement, la plupart des ressources éducatives ne parviennent pas à y remédier. Ils restent soit purement théoriques (« voici comment fonctionne le tri rapide »), soit purement pratiques (« voici comment déployer une application React »).

Ce qui rend ce plan d'étude JavaScript intéressant, ce n'est pas qu'il soit particulièrement bien conçu, c'est qu'il crée des liens entre ces mondes. Prenez le problème de mémorisation : 2623. Mémoriser³. En termes CS, il s'agit de mettre en cache les valeurs calculées. Mais sa mise en œuvre vous oblige à composer avec les particularités de JavaScript en matière de références d'objets, de contextes de fonctions et de gestion de la mémoire. Soudain,
vous n'apprenez pas seulement un algorithme - vous commencez à comprendre pourquoi quelque chose comme Redis existe.

Ce style se répète tout au long des défis. L'implémentation d'Event Emitter² ne concerne pas seulement un modèle d'observateur de manuel - vous pouvez le considérer comme la raison pour laquelle retirer le moteur V8 du navigateur et construire Node.js autour de lui avait réellement du sens. . Le Promise Pool⁴ s'attaque à l'exécution parallèle, c'est-à-dire la raison pour laquelle votre base de données a besoin d'une limitation de connexion.

Le programme caché

L'enchaînement des problèmes dans ce plan d'étude n'est pas aléatoire. Il s'agit de construire un modèle mental de JavaScript moderne, couche par couche.

Ça commence par les fermetures. Non pas parce que les fermetures sont le concept le plus simple - elles sont notoirement déroutantes - mais parce qu'elles sont fondamentales dans la façon dont JavaScript gère l'état.

function createCounter(init) {
    let count = init;
    return function() {
        return count++;
    }
}

const counter1 = createCounter(10);
console.log(counter1()); // 10
console.log(counter1()); // 11
console.log(counter1()); // 12

// const counter1 = createCounter(10);
// when this^ line executes:
// - createCounter(10) creates a new execution context
// - local variable count is initialized to 10
// - a new function is created and returned
// - this returned function maintains access 
// to the count variable in its outer scope
// - this entire bundle 
// (function (the inner one) + its access to count) 
// is what we call a closure

Ce modèle est la graine de toute gestion d’état en JavaScript. Une fois que vous avez compris comment fonctionne ce compteur, vous comprenez comment fonctionne useState de React sous le capot. Vous comprenez pourquoi les modèles de modules sont apparus dans le JavaScript pré-ES6.

Ensuite, le plan passe aux transformations fonctionnelles. Ceux-ci vous apprennent la décoration de fonctions - où les fonctions enveloppent d'autres fonctions pour modifier leur comportement. Ce n'est pas seulement une astuce technique ; c'est ainsi que fonctionnent les middlewares Express, comment fonctionnent les composants d'ordre supérieur de React,
et aussi comment fonctionnent les décorateurs TypeScript.

Au moment où vous atteignez les défis asynchrones, vous n'apprenez pas seulement les promesses - vous découvrez pourquoi JavaScript en avait besoin en premier lieu. Le problème Promise Pool⁴ ne vous apprend pas un concept JS innovant et original ; cela vous montre pourquoi le regroupement de connexions existe dans chaque moteur de base de données.

Voici une cartographie approximative des sections du plan d'étude avec les concepts du monde réel du génie logiciel :

• Fermetures → Gestion de l'État
• Transformations de base des tableaux → Compétence de base (auxiliaire) ; Exemple pratique : manipulation de données
• Transformations de fonctions → Modèles middleware
• Promesses et délais -> Flux de contrôle asynchrone
• JSON -> Compétence de base (auxiliaire); Exemple pratique : sérialisation des données, communication API
• Classes (notamment dans le contexte des émetteurs d'événements) → Systèmes de transmission de messages
• Bonus (Premium verrouillé) -> Mélange de défis plus difficiles qui auraient pu être inclus dans les sections mentionnées ci-dessus ; Promise Pool⁴ est mon préféré de cette section

Reconnaissance de formes, pas résolution de problèmes

Disséquons quelques problèmes qui mettent en valeur la réelle valeur de ce plan d'étude.

1. Mémoire (#2623)

Considérez le défi Memoize. Ce que j'aime, c'est le fait que la meilleure solution (que j'ai pu trouver)
est si simple, c'est comme si le code lui-même vous disait gentiment ce qu'il fait (j'ai quand même inclus quelques commentaires).

Cela ne fait en aucun cas du #2623 un problème facile. J'avais besoin de 2 itérations précédentes pour le rendre aussi propre :

function createCounter(init) {
    let count = init;
    return function() {
        return count++;
    }
}

const counter1 = createCounter(10);
console.log(counter1()); // 10
console.log(counter1()); // 11
console.log(counter1()); // 12

// const counter1 = createCounter(10);
// when this^ line executes:
// - createCounter(10) creates a new execution context
// - local variable count is initialized to 10
// - a new function is created and returned
// - this returned function maintains access 
// to the count variable in its outer scope
// - this entire bundle 
// (function (the inner one) + its access to count) 
// is what we call a closure

1. Anti-rebond (#2627)

Imaginez que vous êtes dans un ascenseur et qu'il y a une personne qui appuie frénétiquement sur le bouton « fermer la porte » à plusieurs reprises.

appuyez appuyez appuyez appuyez appuyez

Sans rebondir : l'ascenseur essaierait de fermer la porte à chaque pression, ce qui rendrait le mécanisme de la porte inefficace et pourrait éventuellement se briser.

Avec anti-rebond : L'ascenseur attend que la personne ait arrêté d'appuyer pendant un certain temps (disons 0,5 seconde) avant d'essayer réellement de fermer la porte. C'est beaucoup plus efficace.

Voici un autre scénario :

Imaginez que vous implémentez une fonctionnalité de recherche qui récupère les résultats lorsqu'un utilisateur tape :

Sans rebondir :

/**
 * @param {Function} fn
 * @return {Function}
 */
function memoize(fn) {
    // Create a Map to store our results
    const cache = new Map();

    return function(...args) {
        // Create a key from the arguments
        const key = JSON.stringify(args);

        // If we've seen these arguments before, return cached result
        if (cache.has(key)) {
            return cache.get(key);
        }

        // Otherwise, calculate result and store it
        const result = fn.apply(this, args);
        cache.set(key, result);
        return result;
    }
}

const memoizedFn = memoize((a, b) => {
    console.log("computing...");
    return a + b;
});

console.log(memoizedFn(2, 3)); // logs "computing..." and returns 5
console.log(memoizedFn(2, 3)); // just returns 5, no calculation
console.log(memoizedFn(3, 4)); // logs "computing..." and returns 7


// Explanantion:
// It's as if our code had access to an external database

// Cache creation
// const cache = new Map();
// - this^ uses a closure to maintain the cache between function calls
// - Map is perfect for key-value storage

// Key creation
// const key = JSON.stringify(args);
// - this^ converts arguments array into a string
// - [1,2] becomes "[1,2]"
// - we are now able to use the arguments as a Map key

// Cache check
// if (cache.has(key)) {
//     return cache.get(key);
// }
// - if we've seen these arguments before, return cached result;
// no need to recalculate

Cela ferait 10 appels API. La plupart d'entre eux sont inutiles puisque l'utilisateur est toujours en train de taper.

Avec anti-rebond (délai de 300 ms) :

// typing "javascript"
'j' -> API call
'ja' -> API call
'jav' -> API call
'java' -> API call
'javas' -> API call
'javasc' -> API call
'javascr' -> API call
'javascri' -> API call
'javascrip' -> API call
'javascript' -> API call

L'anti-rebond revient à dire à votre code : "Attendez que l'utilisateur ait arrêté de faire quelque chose pendant X millisecondes avant d'exécuter réellement cette fonction."

Voici la solution au LeetCode #2627 :

// typing "javascript"
'j'
'ja'
'jav'
'java'
'javas'
'javasc'
'javascr'
'javascri'
'javascrip'
'javascript' -> API call (only one call, 300ms after user stops typing)

Autres cas d'utilisation courants dans le monde réel pour l'anti-rebond (en dehors des barres de recherche) :

• Enregistrer les brouillons (attendre que l'utilisateur arrête de modifier)
• Bouton Soumettre (éviter les doubles soumissions)

Ce qui ne va pas

J'espère que, d'après le ton globalement positif de cet article, mon opinion sur 30 Days of JS est devenue claire à présent.

Mais aucune ressource pédagogique n’est parfaite et, lorsqu’il s’agit de limites, l’honnêteté est précieuse. Ce plan d'étude comporte plusieurs angles morts qui méritent d'être examinés.

Premièrement, le plan d'études suppose un certain niveau de connaissances préalables.
Si vous n'êtes pas déjà à l'aise avec JavaScript, certains défis peuvent être insurmontables. Cela peut être décourageant pour les débutants qui auraient pu avoir d'autres attentes par rapport au plan d'études.

Deuxièmement, les défis sont présentés de manière isolée.
Cela a du sens au début, mais peut être décevant à réaliser à mesure que vous progressez dans le plan. Les problèmes du monde réel nécessitent souvent de combiner plusieurs modèles et techniques. Le plan d'étude pourrait bénéficier de défis plus intégrés qui nécessitent d'utiliser plusieurs concepts ensemble (exception : nous utilisons des fermetures tout au long du plan). Ceux-ci pourraient bien s'intégrer dans la section Bonus (qui est déjà réservée aux utilisateurs premium).

Enfin, la principale faiblesse de cet ensemble de défis réside dans ses explications conceptuelles. Issu d'une programmation compétitive,
J'ai l'habitude de clarifier les définitions de nouveaux termes et concepts dans les énoncés de problèmes. Cependant, les descriptions de LeetCode sont souvent inutilement complexes - comprendre leur explication d'une fonction anti-rebond est plus difficile que de mettre en œuvre la solution réelle.

Malgré ses lacunes, le plan d'étude est une ressource précieuse pour comprendre le JavaScript moderne.

Au-delà des 30 jours

Comprendre ces modèles n'est que le début.
Le véritable défi consiste à reconnaître quand et comment les appliquer dans le code de production. Voici ce que j'ai découvert après avoir rencontré ces modèles dans la nature.

Premièrement, ces modèles apparaissent rarement de manière isolée. Les véritables bases de code les combinent d'une manière que les défis ne peuvent pas explorer. Considérons une fonctionnalité de recherche, implémentée à partir de zéro. Vous pourriez vous retrouver à utiliser :

• Anti-rebond pour la gestion des entrées
• Mémoisation pour la mise en cache des résultats
• Délai d'expiration des promesses pour les appels d'API
• Émetteurs d'événements pour la gestion de l'état de recherche

Tous ces modèles interagissent, créant une complexité à laquelle aucun défi ne vous prépare. Mais, après avoir implémenté chaque élément vous-même, vous obtenez une idée générale de la façon dont l'ensemble de la mise en œuvre est censé fonctionner.

Contre-intuitivement, la compétence la plus précieuse que vous acquerrez n'est pas de mettre en œuvre ces modèles, mais de les reconnaître dans le code d'autres personnes.

Pensées finales

Après avoir terminé ce plan d'étude, les entretiens de codage ne sont pas le seul endroit où vous reconnaîtrez ces modèles.

Vous les repérerez dans le code open source, dans les pull request de vos collègues, et pourriez commencer à les remarquer dans vos projets passés. Vous les aviez peut-être déjà mis en œuvre auparavant, sans même vous en rendre compte. Plus important encore, vous comprendrez pourquoi ils sont là.

Ce qui a commencé par la résolution d'énigmes s'est transformé en une compréhension plus approfondie de l'écosystème JavaScript moderne.

C'est la lacune que ce plan d'études comble : relier les connaissances théoriques à la sagesse pratique de l'ingénierie.

---

---

1. 2627. Anti-rebond (promesses et temps) ↩

2. 2694. Émetteur d'événements (Classes) ↩

3. 2623. Mémoize (Transformations de fonctions) ↩

4. 2636. Pool de promesses (Bonus) ↩

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!