Discussion :

[grunk]

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.

[hotcryx]

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.

Et de là à se poser la question "Comment arrivent les trojans dans les applics open source?" (comme Tor...)

A un moment, pas au début, c'est injecté par un dev malicieux ou quelqu'un modifiant son code...

[Lcf.vs]

Et de là à se poser la question "Comment arrivent les trojans dans les applics open source?" (comme Tor...)

A un moment, pas au début, c'est injecté par un dev malicieux ou quelqu'un modifiant son code...

Bah, ou tout simplement par un développeur pas très regardant sur ce qu'il utilise... j'en ai déjà parlé quelques fois, sur ce forum... je me souviendrai toujours de ce trojan qui était dans Intel XDK, dans un simple module node.js qu'un développeur avait embarqué... ou de cette agence web qui, sur sa homepage, avait embarqué un plugin jQuery qui appelait le serveur du développeur du plugin, affichant une alerte signalant que la licence n'avait pas été payée. (ce script aurait pu transmettre n'importe quoi, n'importe où)

[hotcryx]

Oui tu as raison ou une faille injectée par une dépendance.

[hotcryx]

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

[MikeRowSoft]

Pour l'instant je modélise plus que j'implémente...

[marsupial]

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 6 pour le compte de Trivago, a proposé quelques points clés pour adopter une approche de programmation défensive.

premier point a 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.

deuxième point b 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.

troisième point c 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

quatrième point d 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.

cinquième point e Écrire un code CONSISTANT :

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

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

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

Ni à la machine. Un cast d'une adresse url renvoit un résultat complètement frappadingue sans retourner d'erreur. Et là nous arrivons au point d ne jamais faire confiance au développeur précédent ni même à votre PDG ou donneur d'ordre qui pour raison x ou y peut demander d'inclure des backdoors.

Pour traiter les données, merci d'utiliser au minimum les expressions régulières et de les réécrire en code ouvert réutilisable et optimisé afin de pouvoir traiter tous les cas de figure.


deuxième point b : utiliser une abstraction de base de données

La multitude de bases réutilisant des briques pourries, mal codées ou en closed code, aucune confiance.


troisième point c : ne réinventez pas la roue

Alors je hurle de rire, de colère et je pleure dans le même temps. Le premier que je prends à utiliser un framework dans ma partie, je le désphincte sans les mains et je le laisse se vider de ses tripes.

quatrième point d : ne jamais faire confiance au développeur

Et encore moins au donneur d'ordre ou à la DG : un jour ou l'autre vous tomberez sur un coup pourri.
Le développeur peut être responsable d'une erreur par négligence ou incompréhension d'où la nécessité d'avoir à disposition un code ouvert et surtout d'être plusieurs à le relire.


cinquième point e : écrire un code consistant

Là, je répondrai par une question : que sécurise-t-on en premier dans cette structure de ligne ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#define struct(...)pointeur

[MikeRowSoft]

troisième point c : ne réinventez pas la roue

Alors je hurle de rire, de colère et je pleure dans le même temps. Le premier que je prends à utiliser un framework dans ma partie, je le désphincte sans les mains et je le laisse se vider de ses tripes.

De forte chance que selon ton commentaire que cela soit en trop...

http://www.oracle.com/technetwork/sy...w-1562924.html
https://developer.microsoft.com/en-us/windows/iot

[maske]

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é ?

[Lcf.vs]

Bah, c'est simple, c'est un code qui semble n'avoir été écrit que par une seule personne... (style d'écriture, logique de programmation commune, ...)

EDIT: 'fin, ça, pour moi, c'est la consistance d'un code...

Après, en effet, dans l'article original, il parle de SOLID qui, à mon avis, fait plutôt référence à https://fr.wikipedia.org/wiki/SOLID_(informatique)

[maske]

Bah, c'est simple, c'est un code qui semble n'avoir été écrit que par une seule personne... (style d'écriture, logique de programmation commune, ...)

Non ça c'est la cohérence, soit "consistency" ou "consistent code" (quoi que faudrait en préciser les critères sinon j'achète pas).

Après, en effet, dans l'article original, il parle de SOLID qui, à mon avis, fait plutôt référence à https://fr.wikipedia.org/wiki/SOLID_(informatique)

C'est mon problème : du coup tous les gens qui parlent de "code consistant" dans ce sujet parlent de quoi ?

[marsupial]

[QUOTE=MikeRowSoft;8855609]De forte chance que selon ton commentaire que cela soit en trop...[QUOTE]

Sans doute. Je me permets de détailler.

a) tous les projets ont une deadline en temps dans 115% des cas intenable avec la contrainte de résultat.

b) mon projet se positionne dans une situation désespérée ( suite à un énorme piratage )


Mes options étaient extrêmement simples et binaires : tout faire seul et mal avec toute la pression sur les épaules. Vite fait mal fait.
J'ai choisi la qualité en rémunérant plus que grassement des personnes à qui j'ai inculqué la deadline résultat et pas la contrainte temps.
Je l'ai fait à ma manière en ne touchant pas un kopeck pendant deux ans ( enfin presque : Volontaire Service Long dans le Génie à 42 ans alors que je suis Réformé Physique 7 mais avec un QI OOR, Out Of Order) où j'ai enseigné l'art de coder sécurisé tout en produisant quelque chose d'adaptable à tout environnement, jamais fait et en réinventant la sécurité. Tout au moins le sens attribué à ce mot. La sécurité GAFAM, pardonne(z) moi, mais c'est de la merde.
Si tu crois qu'une telle qualité s'obtient en contant fleurette à la secrétaire, tu(vous) te(vous) goures(z).

Aujourd'hui, je pense ne plus rien avoir à prouver dans ma partie : 250+ brevets, 2 Système d'Exploitation dont un fork, une norme, et la fierté du job accompli par TOUTE l'équipe alors qu'il y a deux ans l'objectif était loin d'être acquis.
Ca ne s'est pas fait sans mal et Mickaël et Stéphane, par leurs news, pas mal de commentaires de membres du site et en règle générale tout DVP nous ont aidé.

Je crois qu'aujourd'hui, beaucoup aimerait être à notre place. Aucun ressentiment mais qui voulait être à la notre en janvier 2015 ? Personne. J'ai été le seul à répondre présent. Nous n'avons reçu que mépris et zéro encouragement de la part de personnes que je ne citerai pas. Lorsque ce ne sont pas des batons dans les roues pour être racheté pour des clopinettes. On s'est même fait gauler le projet par un actionnaire pour nous concurrencer.

[/HS MyLife]

Résultat : vous le lirez dans le papier journal de demain, Le Figaro "Sans la liberté de blâmer, il n'y a point d'éloge flatteur" - Beaumarchais.

[MikeRowSoft]

Sans doute. Je me permets de détailler. [...]

Résultat : vous le lirez dans le papier journal de demain, Le Figaro "Sans la liberté de blâmer, il n'y a point d'éloge flatteur" - Beaumarchais.

Bon courage, ne t'arrête pas, je n'ai fait qu'une supposition pour mieux connaître le caractère derrière le message. Cela dit, des choses impossibles sont possibles et le manque de possibilité n'est pas une impossibilité (refus engendre refus).

[martopioche]

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.

Ah, cette bonne blague…*"testés et approuvés par des milliers de développeurs"… Les frameworks sont adoptés par effet de mode avant tout. Surtout que par principe, c'est en opposition avec le point…

Ne faites pas confiance aux développeurs :

Sic…

Non, quand t'es sur le marché et SEUL à développer, tu dois développer à la vitesse de la lumière.
Sachant que la concurrence (boites de dev) sont plus nombreux et par conséquent produisent plus vite même si tu as 1 an d'avance sur eux, ils finiront par te rattraper et te dépasser.
[...]
Ce n'est pas réinventer la roue, c'est innover, rénover

Si tu a un an d'avance sur des boites de devs, donc un an avant que leur produit soit à la hauteur du tiens, et que dans ce laps de temps tu n'a pas dégagé un financement (revenu ou levée de fond) qui te permette de grossir ton équipe et qu'à cette échéance, tu perd tes utilisateurs au profit de ces concurrent, c'est à dire que tu n'a pas su les fidéliser, considère que c'est ton offre qui est pourrie, pas ton choix technique.

[Felykanku]

Je pense que tout développeur ne peut pas echaper à la progratiommation défensive dès lors que la gestion des erreurs s'avérer très importante dans le développement de logiciels...

[air-dex]

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

C'est la base de la programmation défensive.

Utilisez une abstraction de base de données

C'est un cas particulier des points 1 et 3 appliqué aux BDD. L'interaction avec la BDD est trop critique pour être laissée entre les mains d'un bout de code maison, plus ou moins normé ISO 1664, à base de sprintf("la requête SQL", <arguments à passer à la requête>); (et encore je suis gentil).

Ne réinventez pas la roue

Ce n'est pas spécifique à la programmation défensive.

Ne faites pas confiance aux développeurs

À partir d'un moment tu es obligé de faire un minimum confiance à ce qu'écrivent tes collègues. Cela s'appelle le travail en équipe. Cela n'empêche pas la vérification de ce que le collègue a écrit, lors de la recette ou bien à d'autres moments. Personne n'a la science infuse et n'est à l'abri de l'écriture de conneries dans le code. Mais tu ne peux pas tout faire tout seul non plus, surtout si c'est un gros projet.

Écrire des tests

Cela n'est pas spécifique à la programmation défensive, mais il convient de garder une trace de certains cas particuliers qu'on a pu rencontrer. Je pense à des bogues où une valeur mal gérée a pu foutre le bordel. Du coup c'est bien de rajouter un test avec cette valeur qui un jour a foutu le bordel, afin que cela ne se reproduise pas.

Au delà du code j'ai envie de rajouter "utiliser des technologies avec un typage fort" et "vérifier le type des valeurs". Il n'y a pas que les valeurs qui peuvent poser problème. Il y a les types aussi. 4 n'est pas forcément "4" ou encore '4', et encore moins true. Il faut donc s'assurer que la valeur ait le bon type afin que le traitement réalisé soit le bon. Il ne faut pas hésiter à transtyper si nécessaire. Il ne faut pas laisser de place au hasard.

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
function quatrePlusTrois(quatre, trois) {
    return quatre + trois;
}
 
function quatrePlusTroisInt(quatre, trois) {
    return parseInt(quatre) + parseInt(trois);
}
 
function quatrePlusTroisStr(quatre, trois) {
    return quatre.toString() + trois.toString();
}
 
console.log(quatrePlusTrois(4, 3));           // 7
console.log(quatrePlusTrois(4, "3"));         // "43"
console.log(quatrePlusTrois('4', '3'));       // "43"
 
console.log(quatrePlusTroisInt(4, 3));        // 7
console.log(quatrePlusTroisInt(4, "3"));      // 7
console.log(quatrePlusTroisInt('4', '3'));    // 7
 
console.log(quatrePlusTroisStr(4, 3));        // "43"
console.log(quatrePlusTroisStr(4, "3"));      // "43"
console.log(quatrePlusTroisStr('4', '3'));    // "43"

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.

La programmation défensive c'est la gestion de valeurs exotiques pour les variables d'entrées. Le vrai implique le vrai et le faux n'est impliqué que par le faux. Si une fonction laisse passer du faux alors cela peut enrayer le reste du programme, même si la fonction est juste et fait le travail qu'on lui demande à la perfection. La programmation défensive a donc avant tout pour but d'éviter qu'il y ait le moindre grain de sable dans la machine.

[foetus]

La programmation défensive c'est la gestion de valeurs exotiques pour les variables d'entrées.

Pas forcément

Un exemple concret: la conversion UTF-8 vers UTF-16 et vice et versa.

Pour des raisons X, j'ai codé les 2 algos à la main (à la bourrin mais ce n'est pas trop long et assez lisible)
Mais je ne suis pas à l'abri que mes algos soient bogués: donc il faut te prévenir au moindre problème.

Le plus simple: c'est la conversion retourne "chaîne vide" (donc rien ne s'affiche). Mais des fois, tu mets du temps à t'en apercevoir/ à percuter.
Le mieux: un système d'alerte ou de logs, qui t'indique où se trouve précisément le problème

[grunt2000]

À mes yeux, la programmation défensive se fonde sur la méfiance quant à l'environnement sur lequel on s'exécute (les données lues sont-elles valides, le service distant que nous appelons est-il fiable, etc.) et repose surtout sur :

- Des objets métiers contenant en leur sein des contrôles "d'invariants" : à n'importe quel moment, un objet métier que j'ai doit se considérer valide du point de vue du contenu de ses variables membres.

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
/**
 * Un code de commune.
 */
public class CodeCommune extends Id
{
   /** Ensemble des codes communes valides connus. Il a été préalablement alimenté en cache statique. */
   private static Set<CodeCommune> COMMUNES = new HashSet<>(); 
 
   /**
    * Vérification de la validité de l'objet métier.
    */
   public void anomalies(Anomalies anomalies)
   {
      // Le code de la commune doit être alimenté.
      if (isBlank(getId()))
         anomalies.declare(ERREUR, "anomalie.code_commune_vide");
      else
      {
         // Le code de la commune doit être associé à un code département.
         if (getCodeDepartement() == null || isBlank(getCodeDepartement().getId()))
            anomalies.declare(ERREUR, "anomalie.code_commune_sans_departement", this);
         else
         {
            // Le département doit être valide.
            anomalies.examine(getCodeDepartement());
 
            // Vérifier que la commune est valide.
            if (COMMUNES.contains(this) == false)
               anomalies.declare(ERREUR, "anomalie.code_commune_non_francais", this);
         }
      }
   }
 
   // ...Autres méthodes de l'objet non présentées ici...
}

L'idée étant d'arriver à une situation où "L'on peut transporter dans son programme un objet aussi faux que l'on veut, mais l'on ne peut pas l'utiliser." :

Je viens de lire un objet de la base, ce n'est pas moi qui l'ai écrit, et il est complètement baroque. Je peux faire autant d'appels de setters que je veux pour le corriger.

Mais (selon la rigueur que l'on s'impose) :

Moyenne : aucun service ou DAO ne peut utiliser l'objet tant qu'il n'aura pas une liste d'anomalies d'auto-contrôle vide,
Forte : aucun de ses getters ne renverra de valeur tant qu'il ne sera pas valide, et ces méthodes lèveront une exception à la place.

- Emploi d'assertions : pré-conditions, post-conditions.
- Emploi d'un jeu d'exceptions élaborées pour décrire tous les problèmes rencontrés avec gestion de leur propagation, enrichissement et rethrow, catch aux endroits appropriés si légitimité à le faire.

- Typage fort. Aucun String, int, double, ne se balade tout nu dans des paramètres de fonctions, si possible, quand il serait possible d'utiliser un objet métier à la place.
par exemple, la fonction présentée est bonne : payTo(Account $to, $amount)
alors que celle-ci payTo($banque, $agence, $guichet, $numeroCompte, $amount) serait plus risquée : banque + agence + guichet + numéro de compte = Account, certes, mais il n'y a plus de vérification aisée que ces quatre premiers paramètres sont bien cohérents entre-eux.

+ d'autres pratiques, nombreuses, comme : des DAO vérifiant avant écriture / update que les objets qu'ils vont persister sont valides avant de le faire.

[Luckyluke34]

J'ai l'impression qu'on confond allègrement programmation défensive et qualité dans ce billet de blog (et aussi dans la définition Wikipédia qui mélange tout et n'importe quoi). La qualité peut être un but mais la programmation défensive n'en est pas un. C'est juste une technique qui est hyper mal définie ici.

• OK pour la programmation par contrat (pré et post conditions)
• OK pour ne pas faire confiance aux entrées utilisateur

Mais en quoi faire du SOLID, des code review, des tests ou simplement "réduire le nombre de bugs" c'est de la programmation défensive ?

Si l'on pose la question différemment : qu'est-ce qui dans le fait de coder n'est pas de la programmation défensive, du coup ?

Coup de chapeau aussi à la généralisation la plus stupide de tous les temps :

developers shouldn’t trust others developers’ code

Qui vient en contradiction totale avec "don't reinvent the wheel", puisque si on ne fait pas confiance au code de ses propres collègues, on va encore moins réutiliser des librairies tierces, hein...

[sevyc64]

J'ai l'impression qu'on confond allègrement programmation défensive et qualité dans ce billet de blog (et aussi dans la définition Wikipédia qui mélange tout et n'importe quoi). La qualité peut être un but mais la programmation défensive n'en est pas un. C'est juste une technique qui est hyper mal définie ici.
[...]
Mais en quoi faire du SOLID, des code review, des tests ou simplement "réduire le nombre de bugs" c'est de la programmation défensive ?

Oui et non. Si qualité et programmation défensive sont 2 notions différentes et apparemment sans lien, toutes les notions de qualité citées contribuent à avoir un code de meilleures qualité, un code bien maitrisé et compris par les développeurs, bien plus aisément maintenable,etc ... Cela suppose aussi que les choses ont été faites correctement en amont du code, que donc le besoin a été compris, que le périmètre d'action du code a bien été compris et cerné, etc...
Tout ça n'est pas, en soi, de la programmation défensive à proprement parlé, mais cela contribue à rendre, en soi, le code plus robuste, à réduire les potentielles surfaces d'attaques, un code beaucoup mieux maitrisé par l'équipe de développement, dans ses qualités, dans ses défauts, dans ses limites.
Ça constitue donc quand même le premier échelon de la programmation défensive.

Coup de chapeau aussi à la généralisation la plus stupide de tous les temps :

Cette généralisation là n'est pas stupide, bien au contraire. Non, il ne faut pas confiance aux codes des collègues.
Mais pas dans le sens ou les collègues font que de la me***, mais plutôt dans le sens que ce n'est pas parce que c'est le collègue qui a écrit ce code, que ce code est exempt de bugs, de possible mauvaise compréhension du besoin, de mauvaise implémentation, etc ...
Et le prolongement est évidemment qu'il ne faut surtout pas non plus faire confiance à son propre code personnel, encore moins je dirais même. On est les plus mal placés pour juger et analyser le code qu'on écrit soi-même. Il ne faut pas hésiter à se remettre en question, il ne faut pas hésiter à penser que ce que l'on a écrit est probablement loin d'être la meilleur qualité qui aurait pu être produite.
C'est dans ce même état d'esprit que, pour une meilleure pertinence, les équipes qui font les tests (ou codent les tests automatiques suivant les organisations), ne doivent absolument pas être composées de membre participant à l'écriture du code. Les équipes qui testent ne doivent pas être celles qui réfléchissent à la résolution des problèmes.

Qui vient en contradiction totale avec "don't reinvent the wheel", puisque si on ne fait pas confiance au code de ses propres collègues, on va encore moins réutiliser des librairies tierces, hein...

En contradiction totale, oui. Et de l'avis assez majoritaire dans les réactions de ce sujets que cet argument là est, lui par contre, bien stupide, surtout dans un contexte de mise en avant de la programmation défensive.

Comme j'ai pu le dire auparavant, faire confiance à un framework dont on ne connait rien (quel qu’en soit la raison, souvent parce que l'on ne prend même pas le temps de savoir ce qu'est ce framework à la mode), c'est un peu programmer volontairement de potentielles failles dans la carapace que l'on veut justement renforcer.