Quelques points clés sur la programmation défensive
Destinée à assurer la fonction continue d'un logiciel dans des circonstances imprévues

Le , par Stéphane le calme, Chroniqueur Actualités
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);
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Jarodd Jarodd - Membre expérimenté https://www.developpez.com
le 27/12/2016 à 9:20
Diego Mariani, évangeliste PHP 6
Ca doit être sympa comme boulot, et pas trop fatigant !
Avatar de NSKis NSKis - Membre émérite https://www.developpez.com
le 27/12/2016 à 9:43
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"...
Avatar de fenkys fenkys - Membre éprouvé https://www.developpez.com
le 27/12/2016 à 9:49
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.
Avatar de Jarodd Jarodd - Membre expérimenté https://www.developpez.com
le 27/12/2016 à 9:58
« 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 !
Avatar de NSKis NSKis - Membre émérite https://www.developpez.com
le 27/12/2016 à 10:01
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"!!!
Avatar de NSKis NSKis - Membre émérite https://www.developpez.com
le 27/12/2016 à 10:02
Ne faites pas confiance aux développeurs :
Et encore moins aux évangélistes!!!
Avatar de grunk grunk - Modérateur https://www.developpez.com
le 27/12/2016 à 10:23
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.
Avatar de sevyc64 sevyc64 - Modérateur https://www.developpez.com
le 27/12/2016 à 10:27
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.
Avatar de hotcryx hotcryx - Membre chevronné https://www.developpez.com
le 27/12/2016 à 11:04
"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.
Avatar de Aurelien.Regat-Barrel Aurelien.Regat-Barrel - Expert éminent https://www.developpez.com
le 27/12/2016 à 11:07
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
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".
Offres d'emploi IT
Chef de projet technique H/F
Safran - Ile de France - Melun (77000)
Ingénieur conception électrique / électronique H/F
Safran - Ile de France - Villaroche
Ingénieur développement logiciel embarqué temps réel (model based) H/F
Safran - Ile de France - VILLAROCHE

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil