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
Ne pas faire confiance aux données entrées par les utilisateurs
Utiliser une abstraction de base de données
Ne pas réinventer pas la roue :
Ne pas faire confiance aux développeurs
Écrire un code SOLID
Écrire des tests
Autres (à préciser en commentaire)
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
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é ?
[|]
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)
Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre codede carte bancaire
Mon GitHub
Une alternative à jQuery, Angular, Vue.js, React, ... ? Testez anticore, en quelques secondes à peine !
(Contributions bienvenues)
Suffisamment minimal pour être fonctionnel et réutilisable facilement et pas nécessairement KISS.
edit : https://fr.wikipedia.org/wiki/SOLID_(informatique)
edit2 : La nuance entre consistency et SOLID se trouve que la consistency consiste à faire du SOLID en permanence, par exemple.
Repeat after me
Le monsieur lutte pour la défense des libertés individuelles et collectives
Repeat after me...
C'est une définition officielle ou du jargon ?
Quel rapport avec SOLID ?
[|]
Le rapport est que dans le message original il est écritAvec SOLId en majuscule représentant l'acronyme SOLID.Write SOLID code
That’s the tough part for a (defensive) programmer, writing code that doesn’t suck. And this is a thing many people know and talk about, but nobody really cares or put the right amount of attention and effort into it in order to achieve SOLID code
Or cela a été traduit commedonc avec l'adjectif solid, qui se traduit en solide, consistant.Write solid code
That’s the tough part for a (defensive) programmer, writing code that doesn’t suck. And this is a thing many people know and talk about, but nobody really cares or put the right amount of attention and effort into it in order to achieve solid code
Il y a effectivement une erreur de traduction, ici.
Le sens n'est pas de faire un code solide, consistant (ce qui ne veut effectivement pas dire grand chose en soi) mais de faire un code répondant aux directives SOLID, ce qui est déjà beaucoup plus concret
--- Sevyc64 ---
Parce que le partage est notre force, la connaissance sera notre victoire
Ça ne veut rien dire. "Consistency" => cohérence (sauf si on parle de bouffe !). Un code est "cohérent" par rapport à des contraintes qu'il faut poser. La première définition que tu donnes n'a pas de rapport avec SOLID, ou alors j'ai pas compris.
C'est exactement le point soulevé. J'ai bien compris la différence quand j'ai regardé la source. Mais le terme "consistant" a eu l'air d'être compris (et utilisé) sans rapport avec alors je me demande si c'est du jargon ou bien juste que la règle est de parler à partir d'un terme dont on imagine une signification sans en vérifier l'origine. J'ai vraiment rien compris à certains posts.Envoyé par sevyc64
En tous cas merci pour la précision.
[|]
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…
Sic…Ne faites pas confiance aux développeurs :
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.
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.
Ca pose quand même la question de ce qu'on attend du développeur. Si on veut un simple exécutant qui code ce qu'on lui demande de coder sans se poser de questions, tu as évidemment raison : savoir se servir de l'outil est la seule chose qui compte.
En revanche, si on veut un esprit capable de voir une problématique dans sa globalité, de faire de la nuance, de replacer son travail dans un contexte plus général, bref, d'être partie prenante et pas simplement exécutant, là, c'est plus gênant. On parle quand même du fondement de base de leur outil de travail. Si je veux quelqu'un capable de me dire quand je fais fausse route, j'ai besoin d'une personne avec des bases théoriques pour remettre ses critiques dans un contexte compréhensible.
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.
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...
Fely Kanku Developpeur .Net et analyste programmeur
C'est la base de la programmation défensive.
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).
Ce n'est pas spécifique à la programmation défensive.
À 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.
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 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.
"Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain
Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).
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
[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.
Repeat after me
Le monsieur lutte pour la défense des libertés individuelles et collectives
Repeat after me...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager