Software Development

Qu’est-ce qu’une closure en JavaScript ? 1 2 3 4 5 6 7 8 9 10 11 12 function makeCounter() { let count = 0; return function () { count += 1; return count; }; } const counter = makeCounter(); console.log(counter()); // 1 console.log(counter()); // 2 console.log(counter()); // 3 makeCounter s’exécute une fois, renvoie une fonction, et c’est tout : son stack frame n’existe plus. Pourtant, chaque appel à counter() lit et met à jour count, une variable déclarée à l’intérieur d’une fonction déjà terminée. count ne revient pas à 0, et n’est pas copiée. C’est la même variable, toujours vivante, trois appels plus tard. ...

Un test écrit après le code tend à vérifier ce que le code fait, pas ce qu’il était censé faire. Le développement piloté par les tests (TDD) corrige cela en inversant l’ordre : vous écrivez le test, vous le regardez échouer, puis vous écrivez le plus petit bout de code qui le fait réussir. Comme le test existe avant le code qu’il vérifie, il ne peut pas valider silencieusement tout ce que le code renvoie. Kent Beck a formalisé cette boucle sous le nom red, green, refactor dans son livre de 2002 Test-Driven Development: By Example. Le nom est resté. ...

Déconnectez un utilisateur d’une application basée sur les sessions, et le serveur l’oublie dès la requête suivante. Déconnectez-le d’une application basée sur JWT et, à moins d’avoir mis en place un mécanisme supplémentaire, le token qu’il détient reste valide jusqu’à son expiration. Cette différence est la vraie décision derrière « JWT contre session ». Tout le reste en découle. Ce qu’une session stocke réellement Une session garde l’état de l’utilisateur sur le serveur et ne transmet au navigateur qu’une clé de référence. ...

Enveloppez un appel fetch() dans un try/catch, ciblez un endpoint qui renvoie un 404, et le bloc catch ne s’exécute jamais. La promise se résout. res.json() analyse le corps renvoyé par le serveur, souvent un payload d’erreur du type {"error": "user not found"}, et le reste de la fonction le traite comme l’enregistrement demandé. Aucune exception, aucun avertissement dans la console. La mauvaise donnée continue son chemin jusqu’à ce qu’autre chose se casse à cause d’elle. ...

Une fonction qui s’appelle elle-même a une profondeur maximale, et elle est plus petite que ce que la plupart des gens imaginent : 1 000 appels dans CPython par défaut, à peu près 10 000 à 15 000 dans Node et dans les moteurs des navigateurs, selon ce que chaque frame contient. Dépasser cette limite ne ralentit pas le programme. Il plante. Python lève RecursionError: maximum recursion depth exceeded ; JavaScript lève RangeError: Maximum call stack size exceeded. ...

Vous construisez un dashboard : un header, une sidebar, une zone de contenu principal, un footer. Vous partez sur Flexbox parce que c’est l’outil de mise en page que vous connaissez, et vingt minutes plus tard vous avez trois conteneurs display: flex imbriqués, une sidebar qui ne garde sa largeur qu’avec un nombre magique, et un footer qui flotte à mi-hauteur de la page quand le contenu est court. Rien de tout cela n’est un bug de Flexbox. Vous utilisez un outil à une dimension sur un problème à deux dimensions. ...

Placez go devant un appel de fonction et cette fonction s’exécute en concurrence avec le reste du programme, gérée par le runtime de Go plutôt que par le système d’exploitation. La lancer est la partie facile. La partie difficile, c’est faire passer un résultat entre deux goroutines sans qu’elles se marchent dessus sur un état partagé, et c’est le travail des channels. Qu’est-ce qu’une goroutine ? Une goroutine est une fonction qui s’exécute indépendamment de celle qui l’a lancée, gérée par le runtime de Go et non par le système d’exploitation. Un thread du système d’exploitation réserve un mégaoctet ou plus de stack et coûte au noyau un vrai temps de planification. Une goroutine démarre avec un stack d’environ 2 Ko qui grandit selon les besoins, et le runtime multiplexe de nombreuses goroutines sur une poignée de threads du système d’exploitation. En lancer des milliers à la fois est normal. ...

Une classe qui enregistre un utilisateur en base, lui envoie un email de bienvenue et met en forme un reçu n’est qu’à un changement de casser deux fonctionnalités qui n’ont rien à voir entre elles. Vous touchez le template de l’email et vous risquez l’écriture en base. Vous touchez la mise en page du reçu et vous risquez l’email. SOLID, ce sont cinq règles qui attaquent ce type d’enchevêtrement sous des angles différents, et elles partagent une idée : une classe doit changer pour une seule raison, et le reste du code doit dépendre de ce qu’une chose promet de faire, pas de la façon dont elle le fait. ...

Deux requêtes arrivent sur le même endpoint “retirer 100 €” à un demi-milliseconde d’intervalle. Le compte contient 150 €. Les deux requêtes lisent ce solde, les deux voient des fonds suffisants, les deux approuvent, les deux soustraient 100 €. Le compte termine à -50 €, et aucune branche du code n’aurait dû permettre cela. C’est une race condition : le résultat dépend de l’opération qui termine la première, et “la première” n’a jamais été quelque chose que le code a décidé. ...

Un champ de recherche qui envoie une requête à chaque frappe en envoie cinq pour “redis”, et quatre arrivent périmées avant que la réponse ne revienne. Un handler de scroll qui recalcule le layout s’exécute des centaines de fois par seconde et fait saccader la page. Même problème dans les deux cas : l’événement du DOM se déclenche bien plus souvent que ce dont le handler a besoin. Debounce et throttle règlent ça de deux façons différentes. ...