Si tu veux réduire le nombre de bug dans tes applis ce n'est pas le fait d'avoir du typage statique ou non qui va jouer là dessus.
Ce n'est pas parce que ton programme compile qu'il :
- ne provoquera pas de crash à l'exécution
- est valide fonctionnellement (qu'il satisfait le besoin)
Pour savoir ça il n'y a qu'une bonne politique de test. Et avec une bonne politique de test tu vas couvrir les problèmes levés par le typage statique dans la foulée. Comment ton test peut-il s'exécuter si tu as un undefined au runtime ? Tu vois ça immédiatement.
Perso j'ai fait plusieurs années de Java pour passer à du JavaScript et je ne constate pas une hausse du nombre de bugs du à l'absence de typage que ce soit de mon fait ou de celui des autres devs.
C'est très très rare dans les faits.
Là où le typage statique est surtout intéressant c'est qu'il documente et clarifie considérablement le code et sa conception. Pour avoir migré des projets de JS vers TS j'ai constaté ça. Ca n'a pas levé de bugs, par contre ça a forcé à clarifier les contrats et donc le code.
Donc le typage statique a indéniablement un impact sur le cout de la TMA en faisant baisser le brain overloading du développeur parce qu'il force une clarification explicite des entrées / sorties des fonctions.
Mais ça n'a pas de rapport avec les bugs, ça c'est du ressort des tests automatisés.
Si tu as des bugs dont la source est l'absence de typage statique, la bonne conclusion ce n'est pas qu'il te faudrait un langage à typage statique mais c'est que tu testes mal ton application. Tu dois voir ces problèmes immédiatement.
Pour être plus concret si ton commit ne contient les tests qui valident la révision, tu as un problème et ça n'a rien à voir avec la présence ou l'absence de typage statique.
Partager