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 2 sur 4 PremièrePremière 1234 DernièreDernière
  1. #21
    Membre expérimenté
    Avatar de Jarodd
    Profil pro
    Inscrit en
    août 2005
    Messages
    780
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2005
    Messages : 780
    Points : 1 461
    Points
    1 461

    Par défaut

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

  2. #22
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    996
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

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

    Informations forums :
    Inscription : mars 2012
    Messages : 996
    Points : 1 517
    Points
    1 517

    Par défaut

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    j'y pas compri
    juste en regardant sans essayer de trop comprendre, on voit l'instanciation, l'affectation et le +1 => mmmmm ça sent pas bon

    Déjà en voyant l'instanciation dans la boucle => ça attire déjà l'attention
    Si la réponse vous a aidé, pensez à cliquer sur +1

  3. #23
    Expert confirmé
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2012
    Messages
    1 635
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2012
    Messages : 1 635
    Points : 4 123
    Points
    4 123

    Par défaut

    Ne pas faire confiance aux données entrées par les utilisateurs
    On ne peut pas faire confiance à un utilisateur, c'est la base de la sécurité.

    Utiliser une abstraction de base de données
    Si on utilise d'autres langages que l'assembleur c'est justement parce que l'abstraction a un intérêt; pourquoi est-ce qu'on gérerait les DB différemment ?

    Ne pas réinventer pas la roue
    Si une lib répond à nos besoin, c'est une bonne idée d'y jeter un oeil; mais faut pas tomber dans l'excès non plus: rajouter une dépendance à une lib énorme (genre boost) pour n'en utiliser qu'une infime partie c'est pas forcément une bonne idée.

    Ne pas faire confiance aux développeurs
    Là, c'est de la paranoïa, il faut bien faire confiance à quelqu'un / quelque chose. Le besoin / contexte nous dit qui (ou quoi) croire.
    Exemple un anti-virus ne peut pas faire confiance à l'OS; un site Web fera confiance au serveur Web (Apache ou autre) et à l'OS.
    Notre code (le notre personnellement; ou celui des autres devs de l'équipe) est par contre de confiance; dans tous les cas.

    Écrire un code CONSISTANT
    Très bon conseil, et j'irai même jusqu’à dire que si quelque chose est mal fait dans l'application et qu'on doit faire quelque chose de similaire : alors il faut continuer sur le même principe (refaire ça mal) pour que le code soit consistant.
    (L'idéal étant bien sur de refactoriser ça, mais ça prend du temps).

    Écrire des tests
    Tant qu'on ne tombe pas dans l'excès, ça ne fait pas de mal. Et ça permet d'éviter tous ces tests inutiles au runtime qui ruinent les perfs.

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

    edit:
    Citation Envoyé par hotcryx Voir le message
    juste en regardant sans essayer de trop comprendre, on voit l'instanciation, l'affectation et le +1 => mmmmm ça sent pas bon

    Déjà en voyant l'instanciation dans la boucle => ça attire déjà l'attention
    Réécrit de manière plus simple, ça donne
    Code c++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    int tab[42];
    int i=0;
    while(i<42) {
       int nbElt = tab[i];
       assert(nbElt > 0);
       i += nbElt;
    }
    Pas de problème particulier, à part que si on veut des nombres positifs, on peut utiliser des unsigned int dans le tableau, et virer l'assert.
    Je sais bien que c'est un exemple; mais ça montre un soucis souvent associé à la prog défensive : rajouter des tests pour corriger une erreur précédente.

  4. #24
    Membre éprouvé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    538
    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 : 538
    Points : 901
    Points
    901

    Par défaut

    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?
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

  5. #25
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    4 424
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 424
    Points : 17 900
    Points
    17 900

    Par défaut

    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  6. #26
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    996
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

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

    Informations forums :
    Inscription : mars 2012
    Messages : 996
    Points : 1 517
    Points
    1 517

    Par défaut

    Citation Envoyé par grunk Voir le message
    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...
    Si la réponse vous a aidé, pensez à cliquer sur +1

  7. #27
    Membre éprouvé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    538
    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 : 538
    Points : 901
    Points
    901

    Par défaut

    Citation Envoyé par Iradrille Voir le message
    Là, c'est de la paranoïa, il faut bien faire confiance à quelqu'un / quelque chose. Le besoin / contexte nous dit qui (ou quoi) croire.
    Exemple un anti-virus ne peut pas faire confiance à l'OS; un site Web fera confiance au serveur Web (Apache ou autre) et à l'OS.
    Notre code (le notre personnellement; ou celui des autres devs de l'équipe) est par contre de confiance; dans tous les cas.
    Hum, de la parano?

    Reprenons un peu tout ce dont tu as besoin afin d'arriver sur cette page:

    • Un PC/tablette/smartphone/...
    • Un FAI
    • Desrouteurs
    • Des serveurs DNS
    • Les serveurs de DVP
    • ...



    Sur tout ça, combien cela représente-t-il d'OS, de logiciels, de frameworks, d'appareils, etc.? Et, donc, combien de de personne cela a-t-il impliqué, de près ou de loin? Statistiquement, les chances que toutes ces personnes soient honnêtes et rigoureuses, tu les estimes à combien?
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

  8. #28
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    996
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

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

    Informations forums :
    Inscription : mars 2012
    Messages : 996
    Points : 1 517
    Points
    1 517

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    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.
    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.
    Par conséquent t'es obligé de trouver des "raccourcis" => FW, libs...
    Tu peux inventer ton propre FW mais ça va te prendre beaucoup de temps et tu dois nourrir ta famille
    Le mieux est d'utiliser ce qu'il y a de mieux et d'y ajouter tes touches finales => c'est cela qui fera la différence (un design différent et agréable, des fonctionnalités peu utilisées par la concurrence mais nécessaires...)
    Ce n'est pas réinventer la roue, c'est innover, rénover
    Si la réponse vous a aidé, pensez à cliquer sur +1

  9. #29
    Expert confirmé
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2012
    Messages
    1 635
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2012
    Messages : 1 635
    Points : 4 123
    Points
    4 123

    Par défaut

    Citation Envoyé par Lcf.vs Voir le message
    Sur tout ça, combien cela représente-t-il d'OS, de logiciels, de frameworks, d'appareils, etc.? Et, donc, combien de de personne cela a-t-il impliqué, de près ou de loin? Statistiquement, les chances que toutes ces personnes soient honnêtes et rigoureuses, tu les estimes à combien?
    Très faibles.

    Mais si il y a une faille, tu ne la détectera pas au niveau de ton code, ça sera bien plus bas.

  10. #30
    Expert éminent

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

    Informations forums :
    Inscription : juin 2003
    Messages : 5 549
    Points : 8 367
    Points
    8 367
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par hotcryx Voir le message
    juste en regardant sans essayer de trop comprendre, on voit l'instanciation, l'affectation et le +1 => mmmmm ça sent pas bon

    Déjà en voyant l'instanciation dans la boucle => ça attire déjà l'attention
    Je suis d'accord, ce code sent mauvais... et c'est justement pour ça que j'y glisse mon assertion

    Je voulais illustrer le fait que quand je me retrouve à maintenir / écrire ce genre de code (on fait pas toujours ce qu'on veut avec du legacy), c'est là que je me mets en mode "ceinture et bretelles".

  11. #31
    Membre expérimenté
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    996
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

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

    Informations forums :
    Inscription : mars 2012
    Messages : 996
    Points : 1 517
    Points
    1 517

    Par défaut

    Citation Envoyé par Lcf.vs Voir le message
    Hum, de la parano?
    Je connaissais un gars (par l'intermédiaire d'un proche) qui développait un outil d'obfuscation Android (le meilleur du marché).
    Cette personne me disait que constamment il devait modifier et améliorer son outil car il y avait un hackeur qui essayait de casser son code, pour casser le code de ceux ayant achetés des licences.

    => Il faut plus se méfier de ceux qui veulent vraiment nuire, il en suffit d'un seul!
    => oui il faut être parano
    Si la réponse vous a aidé, pensez à cliquer sur +1

  12. #32
    Membre éprouvé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    538
    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 : 538
    Points : 901
    Points
    901

    Par défaut

    Citation Envoyé par hotcryx Voir le message
    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ù)
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

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

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

    Informations forums :
    Inscription : mars 2012
    Messages : 996
    Points : 1 517
    Points
    1 517

    Par défaut

    Oui tu as raison ou une faille injectée par une dépendance.
    Si la réponse vous a aidé, pensez à cliquer sur +1

  14. #34
    Expert éminent

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

    Informations forums :
    Inscription : juin 2003
    Messages : 5 549
    Points : 8 367
    Points
    8 367
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par hotcryx Voir le message
    Ce n'est pas réinventer la roue, c'est innover, rénover
    En fait y'a réinventer la roue et... réinventer la roue

    On vit certainement à une époque où il n'y a jamais eu autant de monde payé à réinventer la roue : une roue d'A380 ou de tracteur c'est pas pareil... Est-ce la même roue dans les deux cas ("simple" adaptation) ? Ou s'agit-il d'une réinvention? A mois qu'adapter la roue implique parfois de la réinventer

    C'est pour ça que c'est un peu bancal cette analogie de la roue.

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

    Informations forums :
    Inscription : janvier 2010
    Messages : 647
    Points : 2 305
    Points
    2 305

    Par défaut

    Réussir à conseiller de "faire confiance à un framework plutôt qu'à son propre code", c'est juste du n'importe quoi!!!

    En quoi Monsieur l'évangéliste peut dire qu'il faut faire confiance aux capacités de mecs que l'on ne connait pas??? Il n'est pas écrit dans les astres que tout développeur participant à la création d'un framework est automatiquement touché par la grâce divine du dieu "informatique" qui lui permet de pondre du code sans défaut!

    D'ailleurs, il suffit de suivre un peu les news qui nous annoncent tous les 2 jours la détection d'une faille zero-day dans l'un ou l'autre produit (que cela soit software ou hardware) pour se convaincre qu'il n'y a aucun produit exempt de problème!!!

  16. #36
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    4 424
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 424
    Points : 17 900
    Points
    17 900

    Par défaut

    Citation Envoyé par hotcryx Voir le message
    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.
    Par conséquent t'es obligé de trouver des "raccourcis" => FW, libs...
    Tu peux inventer ton propre FW mais ça va te prendre beaucoup de temps et tu dois nourrir ta famille
    Le mieux est d'utiliser ce qu'il y a de mieux et d'y ajouter tes touches finales => c'est cela qui fera la différence (un design différent et agréable, des fonctionnalités peu utilisées par la concurrence mais nécessaires...)
    Ce n'est pas réinventer la roue, c'est innover, rénover
    D'ou ce que je dis : utiliser des produits sur étagère pour tout ce qui n'est pas critique, si c'est pertinent(et dans ce cas précis, c'est pertinent). Franchement, si je ne fais pas mieux que le marché sur les points de base, je n'ai aucune chance. Et je n'ai aucune raison de penser que le marché actuel fait moins bien que des produits sur étagère. si je gagne de l'argent, c'est que j'offre une plus-value. A moi de la créer.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

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

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

    Informations forums :
    Inscription : mars 2012
    Messages : 996
    Points : 1 517
    Points
    1 517

    Par défaut

    Citation Envoyé par Iradrille Voir le message
    Réécrit de manière plus simple, ça donne
    Code c++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    int tab[42];
    int i=0;
    while(i<42) {
       int nbElt = tab[i];
       assert(nbElt > 0);
       i += nbElt;
    }
    c'est encore trop obscure, on peut définir nbElt en dehors de la boucle ou simplement ne pas l'utiliser car il n'apporte rien.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    int tab[42];
    int i=0;
    while(i<42) {
       i += tab[i];
    }


    Rem: dans l'exemple tab n'a que des 0 comme valeurs ^^
    Si la réponse vous a aidé, pensez à cliquer sur +1

  18. #38
    Provisoirement toléré Avatar de MikeRowSoft
    Homme Profil pro
    Sans profession
    Inscrit en
    avril 2013
    Messages
    994
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Sans profession

    Informations forums :
    Inscription : avril 2013
    Messages : 994
    Points : 0
    Points
    0

    Par défaut

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

  19. #39
    Provisoirement toléré Avatar de MikeRowSoft
    Homme Profil pro
    Sans profession
    Inscrit en
    avril 2013
    Messages
    994
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Sans profession

    Informations forums :
    Inscription : avril 2013
    Messages : 994
    Points : 0
    Points
    0

    Par défaut

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

  20. #40
    Membre éprouvé Avatar de marsupial
    Homme Profil pro
    DevOp, Tech leader
    Inscrit en
    mars 2014
    Messages
    492
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : DevOp, Tech leader

    Informations forums :
    Inscription : mars 2014
    Messages : 492
    Points : 1 021
    Points
    1 021

    Par défaut

    Citation Envoyé par Stéphane le calme Voir le message
    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
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

Discussions similaires

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

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