Software Development

Ce qu’un décorateur fait vraiment à votre fonction Vous voulez mesurer le temps de chaque fonction qui appelle une API externe lente. Vous pouvez coller des appels à time.perf_counter() dans chacune, ou écrire la mesure une seule fois et l’appliquer partout. Un décorateur est la deuxième option : c’est une fonction qui prend une autre fonction, l’enveloppe dans un comportement supplémentaire et renvoie la version enveloppée sous le même nom. ...

Exécutez 0.1 + 0.2 dans un shell Python et vous n’obtenez pas 0.3. Vous obtenez 0.30000000000000004. Essayez en JavaScript, Java, Go, C ou Rust et vous retrouvez la même traîne de dix-sept chiffres. Chacun de ces langages fait exactement ce que lui impose le matériel. Un nombre qui demanderait une infinité de chiffres binaires est compressé dans 64 bits, et quelque chose doit céder. Pourquoi 0.1 ne peut pas être stocké exactement en binaire Les ordinateurs stockent les nombres à virgule flottante en base 2. En base 2, la fraction 1/10 a un développement périodique, tout comme 1/3 se répète indéfiniment en base 10 (0.3333...). Développé en détail, 0.1 en binaire commence ainsi : ...

Une recherche dans un dictionnaire Python prend environ 100 nanosecondes, que le dictionnaire contienne 1 000 clés ou 1 000 000. Une double boucle qui cherche des doublons dans une liste prend une demi-milliseconde sur 200 éléments et 136 millisecondes sur 3 200. Seize fois l’entrée, presque 280 fois l’attente. Même machine, même Python. La notation Big O est le nom de cette différence. Ce que mesure la notation Big O Big O décrit comment le temps d’exécution (ou l’utilisation de la mémoire) d’un morceau de code croît quand l’entrée grandit. Ce n’est pas une mesure au chronomètre, et peu importe que votre ordinateur soit rapide ou lent. Ce qui compte, c’est la forme de la courbe de croissance : quand vous doublez l’entrée, le temps double-t-il, quadruple-t-il, ou bouge-t-il à peine ? ...

Lancez git reset --hard sur un commit que votre équipe a déjà récupéré par pull, et votre historique local se met à diverger du leur. Lancez git revert sur une simple faute de frappe que vous n’avez pas encore poussée, et vous ajoutez un commit inutile au log. Git propose quatre commandes pour annuler un changement, restore, reset, commit --amend et revert, et elles ne sont pas interchangeables. Choisissez la mauvaise et elle ne fait rien, ou elle fait bien plus que ce que vous vouliez. ...

Voici une classe que vous ne pouvez pas tester unitairement sans une base de données active et un serveur SMTP opérationnel : 1 2 3 4 5 6 7 8 9 10 11 public class OrderService { private readonly SqlOrderRepository _repository = new SqlOrderRepository("Server=prod-db;Database=Orders;..."); private readonly SmtpEmailSender _emailSender = new SmtpEmailSender("smtp.company.com"); public void PlaceOrder(Order order) { _repository.Save(order); _emailSender.Send(order.CustomerEmail, "Order confirmed"); } } OrderService construit lui-même ses SqlOrderRepository et SmtpEmailSender avec new, chaîne de connexion comprise. Chaque test qui touche à PlaceOrder a besoin d’une vraie base de données Orders et d’un vrai serveur de mail, sinon il échoue avant même que votre assertion s’exécute. La logique que vous voulez tester tient en deux lignes : enregistrer la commande, envoyer la confirmation. Elle est soudée à deux classes concrètes que vous ne pouvez pas remplacer. ...

Une fonction peut avoir 100 % de couverture de tests unitaires, et la page qui l’appelle peut quand même renvoyer une 500 en production. Ce n’est pas une contradiction. Les tests unitaires, d’intégration et end-to-end vérifient des choses différentes, et une suite chargée sur l’un et légère sur l’autre présente un trou précis et prévisible. Ce que vérifient les tests unitaires, d’intégration et end-to-end Prenez une fonctionnalité d’inscription : une fonction valide la saisie, écrit une ligne dans une base de données et envoie un email de bienvenue. Trois tests peuvent la couvrir, et chacun répond à une question différente. ...

Exécutez ceci dans Node ou dans la console d’un navigateur : 1 2 3 4 console.log("1"); setTimeout(() => console.log("2"), 0); Promise.resolve().then(() => console.log("3")); console.log("4"); Le résultat est 1 4 3 2. Un setTimeout avec un délai de 0ms s’exécute quand même après le callback de la promise, et les deux attendent que chaque ligne de code synchrone en dessous se termine. async/await repose sur cet ordre, ce n’est pas un mécanisme différent. La plupart des comportements surprenants du JavaScript asynchrone viennent du fait qu’on écrit await comme s’il mettait en pause tout le programme, alors qu’il ne met en pause que la fonction dans laquelle il se trouve. ...

Votre frontend tourne sur http://localhost:5173, votre API sur http://localhost:4000, et l’appel fetch qui fonctionnait sans problème dans Postman échoue dans le navigateur avec un mur de texte rouge : Access to fetch at 'http://localhost:4000/api/users' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Votre serveur a très bien pu traiter cette requête et renvoyer un 200. Le navigateur, lui, a refusé de transmettre la réponse à votre JavaScript. ...

Déboguer un bug qui n’apparaît que sur une machine sans Visual Studio Un bug se reproduit sur le serveur de test et pas sur votre ordinateur portable. Le serveur de test n’a pas Visual Studio, et installer un IDE complet dessus pour poser un seul breakpoint n’est pas envisageable. Le débogage à distance est fait pour ce cas. Un petit programme autonome tourne sur la machine cible, votre Visual Studio local s’y connecte par le réseau, et vous obtenez des breakpoints et l’inspection de variables sur un process qui ne tourne nulle part près de votre bureau. ...