Quelques points clés sur la programmation défensive Destinée à assurer la fonction continue d'un logiciel dans des circonstances imprévues 227PARTAGES 8 3 Quels sont, selon vous, les points clés pour une programmation défensive ? La programmation défensive ! Cette philosophie, qui consiste à écrire son code de façon à sattendre au pire, est décrite comme étant « une forme de conception défensive destinée à assurer la fonction continue d'un logiciel dans des circonstances imprévues ». Cette approche est souvent le leitmotiv dans des situations où la haute disponibilité, la sûreté ou la sécurité sont nécessaires.



Diego Mariani, évangeliste PHP pour le compte de Trivago, a proposé quelques points clés pour adopter une approche de programmation défensive.



Ne faites jamais confiance aux données entrées par l'utilisateur :



Supposez toujours que vous allez recevoir quelque chose d'inattendu. Ce devrait être votre approche en tant que programmeur défensif : vous méfier des données entrées par des utilisateurs, ou en général de toutes données qui entrent dans dans votre système. Il faut donc essayer d'être aussi strict que possible. Assurez-vous que vos valeurs d'entrée correspondent à vos attentes. Autrement vous pourrez finir avec des erreurs sur la validité de vos valeurs (exemple valeur négative pour une durée).



Il peut être plus utile et simple de faire des listes blanches que des listes noires par exemple pour valider des extensions dimage : ne recherchez pas les types invalides, mais recherchez plutôt les types valides et excluez le reste. Vous pouvez également vous servir de bibliothèques open source de validation.



Utilisez une abstraction de base de données :



La première des 10 vulnérabilités de sécurité figurant dans la liste d'OWASP (Open Web Application Security Project, un organisme à but non lucratif voué à fournir des informations impartiales et pratiques sur la sécurité des applications) est linjection. Cela signifie quil y a encore beaucoup de personnes qui ne se servent pas, ou se servent mal, d'outils sécurisés pour faire des requêtes sur leurs bases de données. Il serait préférable dutiliser des packages et des bibliothèques pour faire de labstraction de données. En PHP par exemple il y a la PDO (Php Data Object) qui est une couche d'abstraction des fonctions d'accès aux bases de données.



Ne réinventez pas la roue :



« Vous ne vous servez pas dun framework (ou dun micro-framework) ? Eh bien !!! Vous devez aimer faire du travail supplémentaire sans aucune raison, félicitations ! ». Il ne s'agit pas seulement de framework, mais de nouvelles fonctionnalités que vous voulez déployer et que vous pouvez facilement prendre dans des paquets testés et approuvés par des milliers de développeurs plutôt que de commencer à élaborer quelque chose par vous-même. Lune des raisons principales qui devraient vous motiver à aller dans ce sens est de créer quelque chose qui nexiste pas encore ou alors qui existe mais ne correspond pas à vos besoins (mauvaises performances, fonctionnalités manquantes, etc.).





Diego Mariani

Ne faites pas confiance aux développeurs :



La programmation défensive peut être liée à la notion de conduite défensive dans laquelle nous supposons que tout le monde autour de nous peut potentiellement et probablement faire des erreurs. Nous devons donc faire attention aux comportements des autres. Le même concept s'applique à la programmation défensive où nous, en tant que développeurs, ne devons pas faire confiance au code des autres développeurs. Nous ne devons pas faire confiance au nôtre non plus.



À ce propos, dans son blog nommé Building Real Software, Jim Bird, directeur de technologie chez BIDS Trading, évoquait les Code Reviews comme étant lune des clés pour obtenir de meilleurs logiciels. le but étant de relire le code pour repérer les erreurs à un stade précoce. Toutefois, il a rappelé que les reviews coûtent quand même cher et quil ne faut pas faire perdre le temps des reviewers à chercher des problèmes futiles.



Pour Mariani, dans les grands projets où de nombreuses personnes sont impliquées, nous pouvons avoir de nombreuses façons d'écrire et d'organiser le code. Cela peut également conduire à la confusion et apporter encore plus de bogues.



Écrire un code SOLID (un acronyme représentant cinq principes de bases pour la programmation orientée objet) :



SOLID :

S : principe de responsabilité unique (Single Responsibility Principle) ; une classe doit avoir une et une seule responsabilité

O : ouvert/fermé (open/close principle) ; une classe doit être ouverte à l'extension, mais fermée à la modification

L : substitution de Liskov (Liskov substitution Principle) ; une instance de type T doit pouvoir être remplacée par une instance de type G, tel que G sous-type de T, sans que cela ne modifie la cohérence du programme

I : ségrégation des interfaces (Interface segregation principle) ; préférer plusieurs interfaces spécifiques pour chaque client plutôt qu'une seule interface générale

D : Inversion des dépendances (Dependency Inversion Principle) ; il faut dépendre des abstractions, pas des implémentations

« Il sagit de la partie difficile pour un programmeur défensif : lécriture dun code qui ne soit pas merdique. Cest une chose que beaucoup de gens savent, beaucoup de gens en parlent mais peu sont ceux qui se soucient vraiment ou mettent suffisamment dattention et deffort dans lécriture dun code SOLID ».



Voici un mauvais exemple à ne pas suivre : oublier dinitialiser des propriétés :



Code : Sélectionner tout 1

2

3

4

5

6

7

8

9

10

11

12

13

<?php class BankAccount { protected $currency = null; public function setCurrency($currency) { ... } public function payTo(Account $to, $amount) { // sorry for this silly example $this->transaction->process($to, $amount, $this->currency); } } // I forgot to call $bankAccount->setCurrency('GBP'); $bankAccount->payTo($joe, 100);



Plusieurs problèmes peuvent être détectés pour un programme qui nest pas consistant. Cela peut conduire ou être manifesté par exemple par :

un temps de compilation anormalement long (qui peut être la résultante dune non utilisation de bibliothèque, de technique daccélération, etc.) ;

des fichiers sources inclus dans un projet mais qui ne sont pas utilisés ;

la mémoire dynamique qui nest pas libérée ;

de nombreux avertissements lors de la compilation (qui peuvent cacher un bogue).

Écrire des tests



Avons-nous besoin de le rappeler ? Mariani estime quécrire des tests unitaire va non seulement vous aider à tester des modules, mais également de vérifier la façon dont vous avez structuré vos objets.



Source : une définition de la programmation défensive



Et vous ?



Quels sont, selon vous, les points clés de la programmation défensive ?



Avec quel type de projet vous semble-t-elle le plus adaptée ?



Appliquez-vous cette philosophie ? Pour quelles raisons ?



Voir aussi



Que faut-il faire pour avoir de meilleurs logiciels ? Selon un développeur senior, il faut miser sur les techniques d'ingénierie du génie logiciel



Comprendre PDO La programmation défensive ! Cette philosophie, qui consiste à écrire son code de façon à sattendre au pire, est décrite comme étant « une forme de conception défensive destinée à assurer la fonction continue d'un logiciel dans des circonstances imprévues ». Cette approche est souvent le leitmotiv dans des situations où la haute disponibilité, la sûreté ou la sécurité sont nécessaires.Diego Mariani, évangeliste PHP pour le compte de Trivago, a proposé quelques points clés pour adopter une approche de programmation défensive.Supposez toujours que vous allez recevoir quelque chose d'inattendu. Ce devrait être votre approche en tant que programmeur défensif : vous méfier des données entrées par des utilisateurs, ou en général de toutes données qui entrent dans dans votre système. Il faut donc essayer d'être aussi strict que possible. Assurez-vous que vos valeurs d'entrée correspondent à vos attentes. Autrement vous pourrez finir avec des erreurs sur la validité de vos valeurs (exemple valeur négative pour une durée).Il peut être plus utile et simple de faire des listes blanches que des listes noires par exemple pour valider des extensions dimage : ne recherchez pas les types invalides, mais recherchez plutôt les types valides et excluez le reste. Vous pouvez également vous servir de bibliothèques open source de validation.La première des 10 vulnérabilités de sécurité figurant dans la liste d'OWASP (Open Web Application Security Project, un organisme à but non lucratif voué à fournir des informations impartiales et pratiques sur la sécurité des applications) est linjection. Cela signifie quil y a encore beaucoup de personnes qui ne se servent pas, ou se servent mal, d'outils sécurisés pour faire des requêtes sur leurs bases de données. Il serait préférable dutiliser des packages et des bibliothèques pour faire de labstraction de données. En PHP par exemple il y a la PDO (Php Data Object) qui est une couche d'abstraction des fonctions d'accès aux bases de données.« Vous ne vous servez pas dun framework (ou dun micro-framework) ? Eh bien !!! Vous devez aimer faire du travail supplémentaire sans aucune raison, félicitations ! ». Il ne s'agit pas seulement de framework, mais de nouvelles fonctionnalités que vous voulez déployer et que vous pouvez facilement prendre dans des paquets testés et approuvés par des milliers de développeurs plutôt que de commencer à élaborer quelque chose par vous-même. Lune des raisons principales qui devraient vous motiver à aller dans ce sens est de créer quelque chose qui nexiste pas encore ou alors qui existe mais ne correspond pas à vos besoins (mauvaises performances, fonctionnalités manquantes, etc.).La programmation défensive peut être liée à la notion de conduite défensive dans laquelle nous supposons que tout le monde autour de nous peut potentiellement et probablement faire des erreurs. Nous devons donc faire attention aux comportements des autres. Le même concept s'applique à la programmation défensive où nous, en tant que développeurs, ne devons pas faire confiance au code des autres développeurs. Nous ne devons pas faire confiance au nôtre non plus.À ce propos, dans son blog nommé Building Real Software, Jim Bird, directeur de technologie chez BIDS Trading, évoquait les Code Reviews comme étant lune des clés pour obtenir de meilleurs logiciels. le but étant de relire le code pour repérer les erreurs à un stade précoce. Toutefois, il a rappelé que les reviews coûtent quand même cher et quil ne faut pas faire perdre le temps des reviewers à chercher des problèmes futiles.Pour Mariani, dans les grands projets où de nombreuses personnes sont impliquées, nous pouvons avoir de nombreuses façons d'écrire et d'organiser le code. Cela peut également conduire à la confusion et apporter encore plus de bogues.SOLID :« Il sagit de la partie difficile pour un programmeur défensif : lécriture dun code qui ne soit pas merdique. Cest une chose que beaucoup de gens savent, beaucoup de gens en parlent mais peu sont ceux qui se soucient vraiment ou mettent suffisamment dattention et deffort dans lécriture dun code SOLID ».Voici un mauvais exemple à ne pas suivre : oublier dinitialiser des propriétés :Dans ce cas, nous devons nous rappeler que pour émettre un paiement, nous devons appeler en premier setCurrency. C'est vraiment une mauvaise chose, une opération de changement d'état comme celui-ci (émettre un paiement) ne devrait pas être fait en deux étapes, en utilisant deux (n) méthodes publiques. Nous pouvons encore avoir beaucoup de méthodes pour faire le paiement, mais nous devons avoir une seule méthode publique simple pour changer le statut (les objets ne devraient jamais être dans un état inconsistant).Plusieurs problèmes peuvent être détectés pour un programme qui nest pas consistant. Cela peut conduire ou être manifesté par exemple par :Avons-nous besoin de le rappeler ? Mariani estime quécrire des tests unitaire va non seulement vous aider à tester des modules, mais également de vérifier la façon dont vous avez structuré vos objets.Source : billet Diego Mariani Quels sont, selon vous, les points clés de la programmation défensive ?Avec quel type de projet vous semble-t-elle le plus adaptée ?Appliquez-vous cette philosophie ? Pour quelles raisons ? Une erreur dans cette actualité ? Signalez-le nous ! Votre nom : Votre e-mail : Décrivez l'erreur que vous souhaitez porter à notre connaissance : 68 commentaires Poster une réponse Signaler un problème Les mieux notés Les plus récents Ordre chronologique Modérateur https://www.developpez.com Envoyé par NSKis Envoyé par Pour être plus sérieux, qu'est-ce que c'est pour une théorie fumeuse? C'est quoi sa "programmation défensive"? Moi j'appèle cela "gestion des exceptions" ou "traitement des erreurs"...

La programmation défensive consiste à gérer et digérer, principalement, des situations et des données tout à fait correctes sur le plan formel, mais inattendues et erronées sur le plan sémantique. Dans 90% des cas ces situations ne feront pas planter le programme, ne génèreront pas d'erreurs, mais, parce qu'elles sont inattendues et pas conforme à ce qui est attendu dans la cas contexte, provoqueront des résultats aberrants tout en étant formellement justes.



Imagine un régulateur de vitesse qui doit réguler à 100km/h, si, à moment donné, il lit une vitesse à 10km/h, il va en déduire qu'il doit fortement accélérer. Ce qui est logique, normal et formellement juste.

Mais si cette vitesse lue à 10km/h est un artéfact au milieu d'une série de mesure autour des 100km/h, la mesure reste formellement juste (10km/h est une données valide) mais sémantiquement fausse (ce n'est pas une données correcte au milieu des autres). Le comportement du régulateur (forte accélération) reste formellement juste mais complètement aberrant dans le contexte (il ne doit pas accélérer, il est déjà dans la plage de régulation).

Et pourtant, à aucun moment, il n'y a eu génération d'erreurs ou dexceptions.



Évidemment, ici, la solution est que le régulateur ne se base pas sur une seule mesure pour déterminer la vitesse réelle, mais sur la moyenne d'une série de mesures successive, avec éventuellement un algorithme d'exclusion des valeurs excentriques.



Envoyé par Stéphane le calme Envoyé par

« Vous ne vous servez pas dun framework (ou dun micro-framework) ? Eh bien !!! Vous devez aimer faire du travail supplémentaire sans aucune raison, félicitations ! ».

Si l'argument est valable, il est sérieusement incomplet.

Utiliser un framework, c'est bien, mais l'utiliser à bon escient c'est encore mieux.

Combien sont les projets qui utilisent un framework pour ne pas réinventer la roue, mais qui au final n'en utilise même pas 1% ?

Combien sont les projets qui embarquent des véritables usines à gaz, non maitrisées (car on ne sait pas , ou on ne sintéresse pas forcément au code du framework lui-même) alors que quelques lignes de codes, parfaitement maitrisées, elles, auraient suffit?

Utiliser un framework, c'est bien, c'est embarquer toute la puissance de la chose, ça ouvrent des horizon, etc. Mais c'est aussi embarquer toutes les faiblesses, les failles, etc... Et il s'en découvre tout les jours dans les frameworks actuels.

Utiliser un framework, c'est bien, mais utiliser un framework qui ne sera plus mis en jour une fois en production parce que trop compliqué, niveau programmation défensive, c'est un peu programmer des brèches dans la carapace.



Bref, personnellement, même si j'en utilise, plus on me parle de framework, plus j'ai justement tendance à les fuir. 12 0 La programmation défensive ne se limite pas à la gestion des erreurs et exception, j'aurais même envie de dire que ça n'en fait même pas partie.La programmation défensive consiste à gérer et digérer, principalement, des situations et des données tout à fait correctes sur le plan formel, mais inattendues et erronées sur le plan sémantique. Dans 90% des cas ces situations ne feront pas planter le programme, ne génèreront pas d'erreurs, mais, parce qu'elles sont inattendues et pas conforme à ce qui est attendu dans la cas contexte, provoqueront des résultats aberrants tout en étant formellement justes.Imagine un régulateur de vitesse qui doit réguler à 100km/h, si, à moment donné, il lit une vitesse à 10km/h, il va en déduire qu'il doit fortement accélérer. Ce qui est logique, normal et formellement juste.Mais si cette vitesse lue à 10km/h est un artéfact au milieu d'une série de mesure autour des 100km/h, la mesure reste formellement juste (10km/h est une données valide) mais sémantiquement fausse (ce n'est pas une données correcte au milieu des autres). Le comportement du régulateur (forte accélération) reste formellement juste mais complètement aberrant dans le contexte (il ne doit pas accélérer, il est déjà dans la plage de régulation).Et pourtant, à aucun moment, il n'y a eu génération d'erreurs ou dexceptions.Évidemment, ici, la solution est que le régulateur ne se base pas sur une seule mesure pour déterminer la vitesse réelle, mais sur la moyenne d'une série de mesures successive, avec éventuellement un algorithme d'exclusion des valeurs excentriques.Par contre, je suis très dubitatif sur ce point.Si l'argument est valable, il est sérieusement incomplet.Utiliser un framework, c'est bien, mais l'utiliser à bon escient c'est encore mieux.Combien sont les projets qui utilisent un framework pour ne pas réinventer la roue, mais qui au final n'en utilise même pas 1% ?Combien sont les projets qui embarquent des véritables usines à gaz, non maitrisées (car on ne sait pas , ou on ne sintéresse pas forcément au code du framework lui-même) alors que quelques lignes de codes, parfaitement maitrisées, elles, auraient suffit?Utiliser un framework, c'est bien, c'est embarquer toute la puissance de la chose, ça ouvrent des horizon, etc. Mais c'est aussi embarquer toutes les faiblesses, les failles, etc... Et il s'en découvre tout les jours dans les frameworks actuels.Utiliser un framework, c'est bien, mais utiliser un framework qui ne sera plus mis en jour une fois en production parce que trop compliqué, niveau programmation défensive, c'est un peu programmer des brèches dans la carapace.Bref, personnellement, même si j'en utilise, plus on me parle de framework, plus j'ai justement tendance à les fuir. Membre expert https://www.developpez.com ne pas réinventer la roue) ? 7 0 On ne doit pas faire confiance aux développeurs mais utiliser leurs frameworks et fonctionnalités () ? Membre expérimenté https://www.developpez.com Diego Mariani, évangeliste PHP 6 Diego Mariani, évangeliste PHP 6 6 0 Ca doit être sympa comme boulot, et pas trop fatigant ! En attente de confirmation mail https://www.developpez.com Ne faites pas confiance aux développeurs : Ne faites pas confiance aux développeurs : 5 0 Et encore moins aux évangélistes!!! Modérateur https://www.developpez.com Utilisez une abstraction de base de données : Utilisez une abstraction de base de données :

J'aurais même tendance à dire que les FW en général on l'effet pervers de nous faire croire que l'on est protégé alors que ce n'est pas forcément toujours le cas. 5 0 PDo ou tout autre abstraction mal utilisée ca reste la même passoire que l'API de base.J'aurais même tendance à dire que les FW en général on l'effet pervers de nous faire croire que l'on est protégé alors que ce n'est pas forcément toujours le cas. Expert éminent sénior https://www.developpez.com



Le reste, ce sont des bonnes pratiques, hélas encore trop ignorées.



Cette histoire de framework, à mon sens, ça dépend. Quand je vois des jeux codés avec les pieds, avec un contenu multimédia dérisoire, mais pesant 2.5GO et donc non achetables en ligne pour qui a une petite liaison, parce-que faits sur un moteur qui s'étale, je tiens quand même à dire qu'un framework, ce n'est pas la panaçée.



Bon, nous, on vend un logiciel hospitalier, avec comme point fort la partie comptable. Utiliser un framework pour l'affichage, pourquoi pas. Après tout, nos clients ne sont pas très regardants sur l'affichage, on ne fait pas du jeu vidéo, c'est un hôpital, et des écrans moches, ils ont l'habitude. Utiliser un framework pour la partie comptable, et perdre ainsi notre principal argument de vente? Non, quand bien même il y aurait un open source sur le sujet(des gens ont essayé, ils ne sont pas allé bien loin), nous continuerions à mettre le paquet pour être impeccable là dessus, et toujours à jour, et avec le taux de rejet par la sécu le plus bas du marché(c'est notre principal argument de vente).



Donc, si demain je veux créer ma boite et faire du pari en ligne, utiliser des solutions framework pour la sécurité, pourquoi pas. Ca ne sera pas mon cur de métier. Mais le calcul de probabilités, l'interface clients seront mes gagne-pains, et j'aurais intérêt à faire mieux que les autres. Beaucoup mieux. Ca passe par réinventer la roue. 5 0 J'ai voté oui à tout, sauf à cette histoire de framework...qui d'ailleurs est celle qui a provoqué le plus gros débat.Le reste, ce sont des bonnes pratiques, hélas encore trop ignorées.Cette histoire de framework, à mon sens, ça dépend. Quand je vois des jeux codés avec les pieds, avec un contenu multimédia dérisoire, mais pesant 2.5GO et donc non achetables en ligne pour qui a une petite liaison, parce-que faits sur un moteur qui s'étale, je tiens quand même à dire qu'un framework, ce n'est pas la panaçée. J'ajouterais ce vieux plaidoyer de Joel Spolsky pour le code maison, au moins pour les fonctions coeur de la société Bon, nous, on vend un logiciel hospitalier, avec comme point fort la partie comptable. Utiliser un framework pour l'affichage, pourquoi pas. Après tout, nos clients ne sont pas très regardants sur l'affichage, on ne fait pas du jeu vidéo, c'est un hôpital, et des écrans moches, ils ont l'habitude. Utiliser un framework pour la partie comptable, et perdre ainsi notre principal argument de vente? Non, quand bien même il y aurait un open source sur le sujet(des gens ont essayé, ils ne sont pas allé bien loin), nous continuerions à mettre le paquet pour être impeccable là dessus, et toujours à jour, et avec le taux de rejet par la sécu le plus bas du marché(c'est notre principal argument de vente).Donc, si demain je veux créer ma boite et faire du pari en ligne, utiliser des solutions framework pour la sécurité, pourquoi pas. Ca ne sera pas mon cur de métier. Mais le calcul de probabilités, l'interface clients seront mes gagne-pains, et j'aurais intérêt à faire mieux que les autres. Beaucoup mieux. Ca passe par réinventer la roue. Expert éminent sénior https://www.developpez.com Cette approche est souvent le leitmotiv dans des situations où la haute disponibilité, la sûreté ou la sécurité sont nécessaires.





Par exemple, renvoyer une erreur si on reçoit un paramètre null, ce n'est pas valider le contrat "pas de paramètre null", mais l'élargir à "en cas de param null, une erreur sera renvoyée" (si c'est spécifié, c'est toujours du contrat, pas du hors contrat!). Et donc une erreur de programmation qui auparavant provoquait la mort du programme (bonne pratique en terme de sécurité) est ignorée au profit de la disponibilité (ça continue de tourner mais ça fait peut être n'importe quoi...).



Envoyé par NSKis Envoyé par C'est quoi sa "programmation défensive"? Moi j'appèle cela "gestion des exceptions" ou "traitement des erreurs"...





Normalement, on valide un contrat via des assertions (désactivables selon les besoins) pour les pré-conditions, et des tests unitaires pour les post-conditions.



Mais il m'arrive de valider (assertion) certaines post conditions dans le code de production que je sais sensible. Par exemple :



Code cpp : Sélectionner tout 1

2

3

4

5

6

7

8

void processElements ( ) { // c'est un exemple :) for ( int i = 0 ; i < elements.size ( ) ; ) { int nbElements = extractNextElementGroup ( elements, i ) ; ASSERT ( nbElements > 0 ) ; // attention à la boucle infinie i += nbElements; } }

Typiquement, ça permet de détecter des erreurs suites à un refactoring de code sensible / difficile à tester unitairement. Ca s'est révélé utile plus d'une fois.



C'est là que je me dis que c'est de la "programmation défensive". 5 1 Le "ou" est important. Disponibilité et sécurité sont des concepts antagonistes : plus on privilégie la sécurité, plus le système aura tendance à se mettre hors service à la moindre suspicion de problème.Par exemple, renvoyer une erreur si on reçoit un paramètre null, ce n'est pas valider le contrat, mais l'élargir à(si c'est spécifié, c'est toujours du contrat, pas du hors contrat!). Et donc une erreur de programmation qui auparavant provoquait la mort du programme (bonne pratique en terme de sécurité) est ignorée au profit de la disponibilité (ça continue de tourner mais ça fait peut être n'importe quoi...).Moi aussi j'ai du mal à trouver une définition claire de programmation défensive. Il semble que ce soit une sorte de mode "ceinture et bretelles". Là où je suis gêné c'est l'association avec la sécurité. Comme expliqué juste avant, la sécurité pousse à arrêter le système au moindre soucis. Or souvent les exemples de prog défensive tendant à dissimuler les erreurs de programmation / sécurité en les traitant comme de simples erreurs logiques.Normalement, on valide un contrat via des assertions (désactivables selon les besoins) pour les pré-conditions, et des tests unitaires pour les post-conditions.Mais il m'arrive de valider (assertion) certaines post conditions dans le code de production que je sais sensible. Par exemple :Typiquement, ça permet de détecter des erreurs suites à un refactoring de code sensible / difficile à tester unitairement. Ca s'est révélé utile plus d'une fois.C'est là que je me dis que c'est de la "programmation défensive". Modérateur https://www.developpez.com Envoyé par Aurelien.Regat-Barrel Envoyé par Ton exemple est intéressant, mais pour moi c'est pas au régulateur de vitesse de décider si les données qu'on lui donne sont bonnes ou pas. Selon le principe du "faire une seule chose et le faire bien" (SRP), c'est à un autre module spécialisé dans le traitement des valeurs retournées par le capteur de vitesse de faire ce boulot. A chacun son rôle, sinon ça devient vite très compliqué de s'y retrouver (rien n'est vraiment fait ni à faire). Non?

La données est correcte, la réponse est conforme, dans l'absolu !



C'est bien en amont que doit être filtrer la donnée. Sila donnée est correcte, dans le contexte elle est aberrante et doit être rejetée.



La programmation défensive c'est bien cela aussi, fournir des données correctes dans le contexte au process qui doit les traiter et filtrer celles qui ne le sont pas.



Quant à dire que la programmation défensive va à l'encontre de la sécurité, si, en cas de sécurité, arrêt du système signifie plantage du système, ok, c'est sécuritaire mais pas propre. Si arrêt du système ça veut dire arrêt propre et maitrisé du système parce qu'une donnée incorrecte a été détectée, c'est déjà de la programmation défensive.

Programmation défensive ne signifie pas "On continue à fonctionner coute que coute". Non, programmation défensive signifie On fait en sorte de ne pas avoir de données erronées à traiter pour ne pas avoir de comportement inappropriée. Et cela peut signifie, suivant les système, justement un arrêt (propre) du système pour, justement, raison de sécurité. 4 0 Et c'est exactement ce que je décris dans mon exemple. Le régulateur ne fait que réagir correctement à l'information qu'il reçoit. Il reçoit 10km/h, il accélère, rien d'autre.La données est correcte, la réponse est conforme, dans l'absolu !C'est bien en amont que doit être filtrer la donnée. Sila donnée est correcte, dans le contexte elle est aberrante et doit être rejetée.La programmation défensive c'est bien cela aussi, fournir des données correctes dans le contexte au process qui doit les traiter et filtrer celles qui ne le sont pas.Quant à dire que la programmation défensive va à l'encontre de la sécurité, si, en cas de sécurité, arrêt du système signifie plantage du système, ok, c'est sécuritaire mais pas propre. Si arrêt du système ça veut dire arrêt propre et maitrisé du système parce qu'une donnée incorrecte a été détectée, c'est déjà de la programmation défensive.Programmation défensive ne signifie pas "On continue à fonctionner coute que coute". Non, programmation défensive signifie On fait en sorte de ne pas avoir de données erronées à traiter pour ne pas avoir de comportement inappropriée. Et cela peut signifie, suivant les système, justement un arrêt (propre) du système pour, justement, raison de sécurité. Expert confirmé https://www.developpez.com Ne pas faire confiance aux données entrées par les utilisateurs





Utiliser une abstraction de base de données





Ne pas réinventer pas la roue





Ne pas faire confiance aux développeurs



Exemple un anti-virus ne peut pas faire confiance à l'OS; un site Web fera confiance au serveur Web (Apache ou autre) et à l'OS.

Notre code (le notre personnellement; ou celui des autres devs de l'équipe) est par contre de confiance; dans tous les cas.



Écrire un code CONSISTANT



(L'idéal étant bien sur de refactoriser ça, mais ça prend du temps).



Écrire des tests





Mais tout ça n'a pas grand chose à voir avec la prog défensive; à part peut être la touche de paranoïa ?



edit:

Envoyé par hotcryx Envoyé par



Déjà en voyant l'instanciation dans la boucle => ça attire déjà l'attention juste en regardant sans essayer de trop comprendre, on voit l'instanciation, l'affectation et le +1 => mmmmm ça sent pas bonDéjà en voyant l'instanciation dans la boucle => ça attire déjà l'attention

Code c++ : Sélectionner tout 1

2

3

4

5

6

7

int tab [ 42 ] ; int i= 0 ; while ( i< 42 ) { int nbElt = tab [ i ] ; assert ( nbElt > 0 ) ; i += nbElt; } unsigned int dans le tableau, et virer l' assert .

Je sais bien que c'est un exemple; mais ça montre un soucis souvent associé à la prog défensive : rajouter des tests pour corriger une erreur précédente. 4 0 On ne peut pas faire confiance à un utilisateur, c'est la base de la sécurité.Si on utilise d'autres langages que l'assembleur c'est justement parce que l'abstraction a un intérêt; pourquoi est-ce qu'on gérerait les DB différemment ?Si une lib répond à nos besoin, c'est une bonne idée d'y jeter un oeil; mais faut pas tomber dans l'excès non plus: rajouter une dépendance à une lib énorme (genre boost) pour n'en utiliser qu'une infime partie c'est pas forcément une bonne idée.Là, c'est de la paranoïa, il faut bien faire confiance à quelqu'un / quelque chose. Le besoin / contexte nous dit qui (ou quoi) croire.Exemple un anti-virus ne peut pas faire confiance à l'OS; un site Web fera confiance au serveur Web (Apache ou autre) et à l'OS.Notre code (le notre personnellement; ou celui des autres devs de l'équipe) est par contre de confiance; dans tous les cas.Très bon conseil, et j'irai même jusquà dire que si quelque chose est mal fait dans l'application et qu'on doit faire quelque chose de similaire : alors il faut continuer sur le même principe (refaire ça mal) pour que le code soit consistant.(L'idéal étant bien sur de refactoriser ça, mais ça prend du temps).Tant qu'on ne tombe pas dans l'excès, ça ne fait pas de mal. Et ça permet d'éviter tous ces tests inutiles au runtime qui ruinent les perfs.Mais tout ça n'a pas grand chose à voir avec la prog défensive; à part peut être la touche de paranoïa ?edit:Réécrit de manière plus simple, ça donnePas de problème particulier, à part que si on veut des nombres positifs, on peut utiliser desdans le tableau, et virer l'Je sais bien que c'est un exemple; mais ça montre un soucis souvent associé à la prog défensive : rajouter des tests pour corriger une erreur précédente. Membre éprouvé https://www.developpez.com



Dans l'article le monsieur parle de "solid code", j'imagine que je comprends ça (je passe la critique évidente sur sa compétence et la pertinence d'un article pareil...). Le dictionnaire pour "consistant" me donne des définitions que je ne parviens pas à mettre en contexte. Je pensais au début à une mauvaise traduction littérale, de "consistent" vers "consistant", mais visiblement ce n'est pas le cas.



Vous parlez de quoi ? "Consistant", c'est un code quand on a fini de le lire on se sent gavé ? 4 0 Je lis le sujet distraitement, on sait jamais parfois on apprend des trucs sur dvp. Et là je me pose une question : c'est quoi un code "consistant" ?Dans l'article le monsieur parle de "solid code", j'imagine que je comprends ça (je passe la critique évidente sur sa compétence et la pertinence d'un article pareil...). Le dictionnaire pour "consistant" me donne des définitions que je ne parviens pas à mettre en contexte. Je pensais au début à une mauvaise traduction littérale, de "consistent" vers "consistant", mais visiblement ce n'est pas le cas.Vous parlez de quoi ? "Consistant", c'est un code quand on a fini de le lire on se sent gavé ? Poster une réponse Signaler un problème

