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

**Stéphane le calme** · 27/12/2016, 07h50

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

**Jarodd** · 27/12/2016, 10h20

Diego Mariani, évangeliste PHP 6

Ca doit être sympa comme boulot, et pas trop fatigant !

**NSKis** · 27/12/2016, 10h43

Envoyé par Jarodd

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

**Aurelien.Regat-Barrel** · 27/12/2016, 12h07

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

Envoyé par NSKis

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

**hotcryx** · 27/12/2016, 12h12

@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!

**Aurelien.Regat-Barrel** · 27/12/2016, 12h19

Envoyé par hotcryx

(à vue d'oeil => trigger one)

j'y pas compri

**Jarodd** · 27/12/2016, 10h58

« 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 !

**FaridM** · 27/12/2016, 12h14

Envoyé par Jarodd

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 ?

**Jarodd** · 27/12/2016, 12h30

Envoyé par FaridM

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 ?

Pourquoi considéres-tu que mon équipe a un niveau plus bas que l'équipe qui a pondu le framework ? Qu'elle n'a pas testé/revu mon code ?

Ok je n'écrirais que 10 lignes, mais les 100 lignes existeront ailleurs dans le code (du framework). Cela ajoute un niveau de compréhension pour un nouveau développeur qui débarque sur un projet, et ne connaît pas nécessairerait le framework => source d'erreur, de duplication, de complexité, de bug. Si la fonctionnalité est pour hier, est-ce le moment d'apprendre un nouveau framework ? Si mon projet est stable sans framework, pourquoi devrais-je en ajouter un pour une fonctionnalité, plutôt qu'écrire moi-même la fonctionnalité ? Ok je vais gagner 1h, mais combien je vais en perdre en passage de connaissance, en mise à jour, en support ? C'est sûr que si on ne compare que le temps de dév de la fonctionnalité, le "sur mesure" perd par rapport au framework. Mais c'est développer avec des oeillères de considérer que c'est le seul temps à prendre en compte.

Je ne dis pas qu'il ne faut pas utiliser de framework, ni qu'il faut absolument les utiliser. Mais l'argument "si tu n'en utilises pas tu es un mauvais" est complètement idiot. Ce monsieur ne doit pas avoir toucher un projet depuis longtemps pour asséner de telles vérités.

**Lcf.vs** · 27/12/2016, 12h46

Niveau inconvénients à utiliser un framework, j'en vois d'autres:

Un framework peut très bien convenir pour un projet... mais pas du tout pour un autre... on se retrouve donc, dans une équipe, à devoir en maîtriser plusieurs... il suffit de voir certaines offres d'emploi ayant des connaissances requises à rallonge.
Lorsqu'un framework ne répond pas à un besoin spécifique mais qu'on ne peut/veut en changer, on fait un peu de homemade qui sera parfois adapté à certains composants du framework en question... rendant cette création inutilisable avec d'autres frameworks, il y a donc une perte de temps, à la création et en maintenance.
Enfin, l'usage de frameworks a tendance à priver le développeur de l'habitude de faire des choses génériques, afin de pouvoir les réutiliser dans d'autres projets... sur la carrière d'un bon développeur, n'a-t-il pourtant pas constitué une base bien plus conséquente que le framework qu'il utilise, tout en étant plus modulable?

**el_slapper** · 27/12/2016, 12h46

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.

**FaridM** · 28/12/2016, 12h27

Envoyé par Jarodd

Pourquoi considéres-tu que mon équipe a un niveau plus bas que l'équipe qui a pondu le framework ? Qu'elle n'a pas testé/revu mon code ?

Ok je n'écrirais que 10 lignes, mais les 100 lignes existeront ailleurs dans le code (du framework). Cela ajoute un niveau de compréhension pour un nouveau développeur qui débarque sur un projet, et ne connaît pas nécessairerait le framework => source d'erreur, de duplication, de complexité, de bug. Si la fonctionnalité est pour hier, est-ce le moment d'apprendre un nouveau framework ? Si mon projet est stable sans framework, pourquoi devrais-je en ajouter un pour une fonctionnalité, plutôt qu'écrire moi-même la fonctionnalité ? Ok je vais gagner 1h, mais combien je vais en perdre en passage de connaissance, en mise à jour, en support ? C'est sûr que si on ne compare que le temps de dév de la fonctionnalité, le "sur mesure" perd par rapport au framework. Mais c'est développer avec des oeillères de considérer que c'est le seul temps à prendre en compte.

Je ne dis pas qu'il ne faut pas utiliser de framework, ni qu'il faut absolument les utiliser. Mais l'argument "si tu n'en utilises pas tu es un mauvais" est complètement idiot. Ce monsieur ne doit pas avoir toucher un projet depuis longtemps pour asséner de telles vérités.

Dans quelle phrase j'ai écrit que ton équipe à un niveau plus bas que l'équipe qui à pondu le framework?
Dans quelle phrase j'ai écrit que ton équipe ne test et ne relit pas son code?
Tu as lu les phrases jusqu'au bout?

Tu dis qu'il faut un temps d'apprentissage pour le framework, ce qui est vrai, mais tu as de grande chance de :
- Symfony sur un CV de développeur PHP
- Spring Framework sur un CV de développeur Java
- .NET sur un CV de développeur C#
- Ruby on Rails sur un CV de développeur Ruby
...

Et donc l'entrée dans le projet pourra potentiellement se faire plus facilement que sur un projet écrit avec du code maison (Même un code très bien écrit est très bien relu).

Sinon je suis d'accord avec ta dernière phrase.

MikeRowSoft · 27/12/2016, 14h27

Envoyé par Jarodd

Argument idiot.

Pas forcément, un projet peut faire parti d'un projet plus vaste. Mais aucune contrainte de droit en interne à l'entreprise. La notion de sous projet n'est pas usité.

Un front-end par exemple, il y a une indépendance vis-à-vis du command-line, les dll c'est presque pareil. Le code source... ?

Après chercher une aiguille dans le foin... C'est bien l'index qui est peu clair...

**fenkys** · 27/12/2016, 10h49

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.

**NSKis** · 27/12/2016, 11h01

Envoyé par fenkys

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

**NSKis** · 27/12/2016, 11h02

Ne faites pas confiance aux développeurs :

Et encore moins aux évangélistes!!!

**sevyc64** · 27/12/2016, 11h27

Envoyé par NSKis

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.

Envoyé par Stéphane le calme

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

**jopopmk** · 27/12/2016, 12h10

On ne doit pas faire confiance aux développeurs mais utiliser leurs frameworks et fonctionnalités (ne pas réinventer la roue) ?

**Aurelien.Regat-Barrel** · 27/12/2016, 12h16

Envoyé par sevyc64

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?

**Lcf.vs** · 27/12/2016, 12h23

Envoyé par sevyc64

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?