Pour arriver un peu à la même chose, je raisonne en cas de testes. Dans un monde rêvé, où tous les cas seraient testés, combien de tests cela fait ? Cela détermine le nombre d'état possible du code, et autant de problèmes potentiels, surtout après modification (non régression plus complexe).
Cela permet de se rendre compte de la qualité d'un code "stateless", ce qui évite une grande quantité de teste finalement inutile. Cela permet de séparer très clairement les données du logiciel, des données temporaires inutiles. Cela permet d'identifier des "états stables" qui permet d'y retourner en cas de plantage ou d'exception non prévu, voir d'avoir un "reset()" propre, qui évite de recréer toujours le même objet. Cela permet de limiter les données du logiciel aux stricts nécessaire aux traitements, ce qui évite de trainer toutes les entrées et ne plus savoir ce qui est valide ou non, modifier ou non, etc... Pour faire cela, cela impose de gérer les erreurs avant le traitement, cela simplifie le traitement qui considère les entrées juste, et cela permet de faire de très joli message d'erreur, car on est très proche de l'entrée de pipeline de traitement (on dispose de tous les fichiers et leur numéro de ligne).
[^] # Re: chi va piano va sano
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lutter contre l'overengineering. Évalué à 3.
Pour arriver un peu à la même chose, je raisonne en cas de testes. Dans un monde rêvé, où tous les cas seraient testés, combien de tests cela fait ? Cela détermine le nombre d'état possible du code, et autant de problèmes potentiels, surtout après modification (non régression plus complexe).
Cela permet de se rendre compte de la qualité d'un code "stateless", ce qui évite une grande quantité de teste finalement inutile. Cela permet de séparer très clairement les données du logiciel, des données temporaires inutiles. Cela permet d'identifier des "états stables" qui permet d'y retourner en cas de plantage ou d'exception non prévu, voir d'avoir un "reset()" propre, qui évite de recréer toujours le même objet. Cela permet de limiter les données du logiciel aux stricts nécessaire aux traitements, ce qui évite de trainer toutes les entrées et ne plus savoir ce qui est valide ou non, modifier ou non, etc... Pour faire cela, cela impose de gérer les erreurs avant le traitement, cela simplifie le traitement qui considère les entrées juste, et cela permet de faire de très joli message d'erreur, car on est très proche de l'entrée de pipeline de traitement (on dispose de tous les fichiers et leur numéro de ligne).
"La première sécurité est la liberté"