Si tu as un bug, tu peux juste imaginer ce que cela t'aurait coûté de ne pas l'avoir, mais si tu n'as pas de bug, c'est dur de savoir combien tu as économisé grâce à ta solution actuelle.
Je parle à l'inverse : quelle sont les bugs qui, actuellement, dans les applications actuelles, ont couté hyper chère, et que l'on aurait détecté plus tôt.
Qu'est ce que tu aimerais ?
C'est assez rare de maitriser le client et le serveur en même temps. L'un évolue et pas l'autre, ou ne dépende pas de la même équipe ou société. On peut aussi avoir le problème de la gestion de version.
Alors ça c'est un super problème, mais je pense que c'est indépendant du problème de typeage décrit dans ce journal.
Oui, j'englobe le typage dans toutes les techniques statiques pour trouver les bugs. Et la gestion des versions de dépendances est vraiment un problème chiant. (dépendance trop vieille et tu as des failles de sécurité, trop jeune, tu as un risque de non compatibilité avec ton code)
D'ailleurs, je me demandais à quel point des projets de fuzzer comme https://github.com/rohanpadhye/jqf pourrait aider. Imaginons le refactoring d'une méthode : l'outil irait chercher l'ancienne version et la nouvelle pour lancer des tests fuzzing pour détecter des modifications de comportements. On pourrait imaginer comparer l'interface REST ./V1/ entre le vieux et le nouveau code qui aura aussi une interface ./V2/. Des tests unitaires peuvent aider, mais encore faut-il qu'ils existent.
[^] # Re: Nombre dans les types
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Explorer des langages de programmation - édition 2020. Évalué à 3.
Je parle à l'inverse : quelle sont les bugs qui, actuellement, dans les applications actuelles, ont couté hyper chère, et que l'on aurait détecté plus tôt.
C'est assez rare de maitriser le client et le serveur en même temps. L'un évolue et pas l'autre, ou ne dépende pas de la même équipe ou société. On peut aussi avoir le problème de la gestion de version.
Oui, j'englobe le typage dans toutes les techniques statiques pour trouver les bugs. Et la gestion des versions de dépendances est vraiment un problème chiant. (dépendance trop vieille et tu as des failles de sécurité, trop jeune, tu as un risque de non compatibilité avec ton code)
D'ailleurs, je me demandais à quel point des projets de fuzzer comme https://github.com/rohanpadhye/jqf pourrait aider. Imaginons le refactoring d'une méthode : l'outil irait chercher l'ancienne version et la nouvelle pour lancer des tests fuzzing pour détecter des modifications de comportements. On pourrait imaginer comparer l'interface REST ./V1/ entre le vieux et le nouveau code qui aura aussi une interface ./V2/. Des tests unitaires peuvent aider, mais encore faut-il qu'ils existent.
"La première sécurité est la liberté"