Affichage des résultats du sondage: Quels sont, selon vous, les points clés pour une programmation défensive ?

Votants
36. Vous ne pouvez pas participer à ce sondage.
  • Ne pas faire confiance aux données entrées par les utilisateurs

    30 83,33%
  • Utiliser une abstraction de base de données

    7 19,44%
  • Ne pas réinventer pas la roue :

    9 25,00%
  • Ne pas faire confiance aux développeurs

    10 27,78%
  • Écrire un code SOLID

    11 30,56%
  • Écrire des tests

    18 50,00%
  • Autres (à préciser en commentaire)

    5 13,89%
Sondage à choix multiple
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 4 1234 DernièreDernière
  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    2 657
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 2 657
    Points : 56 389
    Points
    56 389

    Par défaut Un développeur propose quelques points clés pour la programmation défensive

    Un développeur propose quelques points clés pour la programmation défensive,
    destinée à assurer la fonction continue d'un logiciel dans des circonstances imprévues

    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 - Visualiser dans une fenêtre à part
    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);
    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 :
    • 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 : billet Diego Mariani, 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

  2. #2
    Membre expérimenté
    Avatar de Jarodd
    Profil pro
    Inscrit en
    août 2005
    Messages
    784
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2005
    Messages : 784
    Points : 1 467
    Points
    1 467

    Par défaut

    Diego Mariani, évangeliste PHP 6
    Ca doit être sympa comme boulot, et pas trop fatigant !

  3. #3
    Membre émérite
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    713
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : janvier 2010
    Messages : 713
    Points : 2 572
    Points
    2 572

    Par défaut

    Citation Envoyé par Jarodd Voir le message
    Ca doit être sympa comme boulot, et pas trop fatigant !
    Et comme tout évangeliste qui se respecte, cela vit sur le compte de ceux qui l'écoutent!


    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"...

    N'importe quel développeur qui fait sérieusement son travail intègre cette gestion d'erreur dans son code!!! Il n'a pas attendu qu'on lui apporte "la bonne parole"...

  4. #4
    Membre éprouvé
    Avatar de fenkys
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    356
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 356
    Points : 978
    Points
    978

    Par défaut

    Ca rapporte bien quand tu es bon en communication. Il faut voir les show télévisés qu'ils font aux USA pour vanter leur religion et leur amour de dieux.

    Pour être plus sérieux, qu'est-ce que c'est pour une théorie fumeuse?
    C'est pas parce que tu n'en a jamais entendu parler avant aujourd'hui que ca n'existe pas depuis longtemps et que c'est une théorie fumeuse.

  5. #5
    Membre expérimenté
    Avatar de Jarodd
    Profil pro
    Inscrit en
    août 2005
    Messages
    784
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2005
    Messages : 784
    Points : 1 467
    Points
    1 467

    Par défaut

    « 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 ! »
    Argument idiot. Ce monsieur connaît mon besoin ? Mes délais ? La complexité de mon projet, sa dette technique ?

    Dans certains cas, il vaut mieux coder quelque chose même si cela existe avec des bibliothèques tierces ou avec un framework, que passer du temps à apprendre un framework, puis l'implémenter.

    Si on me demande d'ajouter une fonctionnalité de contact par e-mail, pourquoi devrais-je utiliser un framework, quand à la main cela prendre une centaine de lignes à ajouter à mon projet ? Ou si on me demande la fonctionnalité en urgence ?

    De plus, se baser sur un framework, c'est aussi prendre des risques, si le framework est abandonné, que plus personne ne sait l'utilisé. Voir l'actualité récente avec la faille critique de phpmailer, la faille est dévoilée pendant les fêtes, quand il n'y a pas forcément de dispo pour le corriger rapidement : ça laisse tout le temps nécessaire à un pirate de profiter de la faille dès qu'elle est dévoilée.

    Bref, encore un "expert" ( en plus PHP 6 ) qui pense tout savoir sur tout. Qu'il écrive des bouquins et nous laisse gérer nos projets !

  6. #6
    Membre émérite
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    713
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : janvier 2010
    Messages : 713
    Points : 2 572
    Points
    2 572

    Par défaut

    Citation Envoyé par fenkys Voir le message
    Ca rapporte bien quand tu es bon en communication. Il faut voir les show télévisés qu'ils font aux USA pour vanter leur religion et leur amour de dieux.


    C'est pas parce que tu n'en a jamais entendu parler avant aujourd'hui que ca n'existe pas depuis longtemps et que c'est une théorie fumeuse.

    Merci de nous faire savoir la différence entre "développement défensive" et une saine "gestion des exceptions"!!!

  7. #7
    Membre émérite
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    713
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : janvier 2010
    Messages : 713
    Points : 2 572
    Points
    2 572

    Par défaut

    Ne faites pas confiance aux développeurs :
    Et encore moins aux évangélistes!!!

  8. #8
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Architecte Web / Android
    Inscrit en
    août 2003
    Messages
    4 242
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Architecte Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 4 242
    Points : 10 838
    Points
    10 838

    Par défaut

    Utilisez une abstraction de base de données :
    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.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  9. #9
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    8 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 8 875
    Points : 23 508
    Points
    23 508

    Par défaut

    Citation Envoyé par NSKis Voir le message
    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 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.


    Citation Envoyé par Stéphane le calme Voir le message
    « 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 ! ».
    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.
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  10. #10
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 060
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 060
    Points : 1 675
    Points
    1 675

    Par défaut

    "Evangéliste"

    "Gardez-vous des faux-prophètes, ils viennent à vous en vêtement de brebis mais au dedans ce sont des loups ravisseurs.
    Vous les reconnaitrez à leurs fruits."

    Je n'avais pas entendu parlé de programmation défensive mais c'est effectivement intéressant.
    Dans la logique ça coule de source (avec l'expérience le code devient plus robuste, "normalement").

    Perso, je devais implémenter un export pdf (linux) sans installer de package => galère!
    Finalement j'avais trouvé une lib javascript mais j'ai préféré pour diverses raisons de ne pas l'utilisée, les données étaient bien trop sensibles.
    J'ai opté pour un export html (code perso) bien plus portable.

    => Faites attention à ce que vous mettez en PROD!

    @Sevyc64 => il faut aussi tenir compte que l'informatique évolue continuellement ainsi que le support des librairies (mettre à jour ou pas les libs), changer de FW plus robuste, populaire, passé de mode => exemple de Jquery à Angular 1?, 2?
    Tout cela à un coût.
    Si la réponse vous a aidé, pensez à cliquer sur +1

  11. #11
    Expert éminent

    Profil pro
    Inscrit en
    juin 2003
    Messages
    5 563
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : juin 2003
    Messages : 5 563
    Points : 8 398
    Points
    8 398
    Billets dans le blog
    3

    Par défaut

    Cette approche est souvent le leitmotiv dans des situations où la haute disponibilité, la sûreté ou la sécurité sont nécessaires.
    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 "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...).

    Citation Envoyé par NSKis Voir le message
    C'est quoi sa "programmation défensive"? Moi j'appèle cela "gestion des exceptions" ou "traitement des erreurs"...
    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 :

    Code cpp : Sélectionner tout - Visualiser dans une fenêtre à part
    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".

  12. #12
    Membre expert Avatar de jopopmk
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2011
    Messages
    1 711
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2011
    Messages : 1 711
    Points : 3 181
    Points
    3 181

    Par défaut

    On ne doit pas faire confiance aux développeurs mais utiliser leurs frameworks et fonctionnalités (ne pas réinventer la roue) ?
    Plus je connais de langages, plus j'aime le C.

  13. #13
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 060
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 060
    Points : 1 675
    Points
    1 675

    Par défaut

    @Aurelien => il pue la m* ton code (à vue d'oeil => trigger one)

    L'exemple des 100 km/h et 10 km/h ça me fait penser au bug de la Nasa avec sa navette qui s'est crashée!
    Si la réponse vous a aidé, pensez à cliquer sur +1

  14. #14
    Membre expérimenté
    Homme Profil pro
    Inscrit en
    janvier 2008
    Messages
    612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : janvier 2008
    Messages : 612
    Points : 1 327
    Points
    1 327

    Par défaut

    Citation Envoyé par Jarodd Voir le message
    Si on me demande d'ajouter une fonctionnalité de contact par e-mail, pourquoi devrais-je utiliser un framework, quand à la main cela prendre une centaine de lignes à ajouter à mon projet ? Ou si on me demande la fonctionnalité en urgence ?
    Peut-être parce qu'au lieu d'écrire 100 lignes, tu en écriras plus que 10 ?
    Peut-être parce que la centaine de ligne que tu n'auras pas à écrire a été testé/revue par plusieurs centaines de développeur, alors que ton code sera testé et revue que par ton équipe ?
    Peut-être parce que tu n'auras pas le temps d'écrire ces 100 lignes, parce qu'il faut que l'envoie de mail fonctionne pour hier ?

  15. #15
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 060
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 060
    Points : 1 675
    Points
    1 675

    Par défaut

    Citation Envoyé par jopopmk Voir le message
    On ne doit pas faire confiance aux développeurs mais utiliser leurs frameworks et fonctionnalités (ne pas réinventer la roue) ?
    "Ne pas faire confiance à la roue et à la route!"
    Si la réponse vous a aidé, pensez à cliquer sur +1

  16. #16
    Expert éminent

    Profil pro
    Inscrit en
    juin 2003
    Messages
    5 563
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : juin 2003
    Messages : 5 563
    Points : 8 398
    Points
    8 398
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par sevyc64 Voir le message
    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.
    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?

  17. #17
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 060
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 060
    Points : 1 675
    Points
    1 675

    Par défaut

    Faire l'abstraction de la bd c'est bien mais quand t'as des zozos qui ont accès direct à la db ou que la db n'est pas la tienne, il y a un risque!
    (et encore plus quand les zozos d'admin sont moins compétants que les DEV !!)
    Si la réponse vous a aidé, pensez à cliquer sur +1

  18. #18
    Expert éminent

    Profil pro
    Inscrit en
    juin 2003
    Messages
    5 563
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : juin 2003
    Messages : 5 563
    Points : 8 398
    Points
    8 398
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par hotcryx Voir le message
    (à vue d'oeil => trigger one)
    j'y pas compri

  19. #19
    Membre éprouvé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    563
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 563
    Points : 964
    Points
    964

    Par défaut

    Citation Envoyé par sevyc64 Voir le message
    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% ?
    Je dirais plutôt :
    Combien sont les projets qui utilisent un framework pour ne pas réinventer la roue, mais dont les utilisateurs n'en connaissent même pas 1% ?

    Parce qu'il faut être réaliste, c'est bien beau de ne pas réinventer la roue en utilisant un framework mais la plupart des développeurs n'ont même pas fait un simple screening des outils qu'ils utilisent, alors encore moins une réelle analyse...

    Utiliser 1% d'un framework, c'est tout de même passer du temps à cette analyse, afin de ne pas mettre en péril son projet et, sur un gros framework, en plus de tous les inconvénients déjà cités, ne serait-ce pas plus rapide de réinventer la roue, tout compte fait?
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

  20. #20
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    8 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 8 875
    Points : 23 508
    Points
    23 508

    Par défaut

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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?
    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é.
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

Discussions similaires

  1. Réponses: 0
    Dernier message: 10/08/2011, 11h19
  2. [Système] quelques mot-clés pour apprendre
    Par aspo dans le forum Fonctions
    Réponses: 2
    Dernier message: 07/02/2007, 15h14

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo