Journal
Ce journal contient 4 entrées.
RSS Feed
Tag cloud
Blog Stéphane Bortzmeyer: Le principe de robustesse, une bonne ou une mauvaise idée ?
Le principe de Postel est très connu dans le monde des protocoles réseaux : "Soyez rigoureux dans ce que produisez, soyez compréhensif avec ce qui vient des autres".
L'objectif de ce principe consiste à maximiser le respect des standards, tout en introduisant une certaine robustesse envers les erreurs mineures et prévisibles qui pourraient exister dans les différentes implémentations.
Malheureusement, ce principe est mal compris, ou plutôt poussé à son extrême : des mécanismes complexes sont mis en œuvre pour résister à des erreurs hypothétiques, ce qui amène les développeurs à se montrer moins rigoureux et à faire émerger ces erreurs. Et une fois que ces erreurs deviennent une habitude, toute nouvelle implémentation se doit de gérer ces erreurs là.
En ce qui me concerne, j'applique le principe de Postel uniquement pour les erreurs évidentes (espaces en trop, par exemple) ou pour les erreurs faciles à détecter/corriger (valeurs oubliées). Hors de question de mettre en place des heuristiques complexes telles que celles implémentées par les navigateurs pour afficher du contenu à tout prix.
Avec le temps, je me rends compte aussi que le principe de Postel tend à être incompatible avec le principe "fail fast", qui consiste à dire qu'une erreur devrait survenir le plus tôt possible (et donc que, justement, un programme ne devrait pas chercher à corriger ou à ignorer les erreurs, mais plutôt échouer rapidement et de manière visible. En effet, l'existence d'une erreur est justement le signe que quelque chose ne va pas, et qu'il y a probablement des soucis en amont. Faire remonter ces erreurs permet de mettre en évidence ces soucis et de les corriger une bonne fois pour toute.
mar. 27 oct. 2015 19:51:03 CET -
-
link
- http://www.bortzmeyer.org/principe-robustesse.html
génie-logiciel postel programmation
L'objectif de ce principe consiste à maximiser le respect des standards, tout en introduisant une certaine robustesse envers les erreurs mineures et prévisibles qui pourraient exister dans les différentes implémentations.
Malheureusement, ce principe est mal compris, ou plutôt poussé à son extrême : des mécanismes complexes sont mis en œuvre pour résister à des erreurs hypothétiques, ce qui amène les développeurs à se montrer moins rigoureux et à faire émerger ces erreurs. Et une fois que ces erreurs deviennent une habitude, toute nouvelle implémentation se doit de gérer ces erreurs là.
En ce qui me concerne, j'applique le principe de Postel uniquement pour les erreurs évidentes (espaces en trop, par exemple) ou pour les erreurs faciles à détecter/corriger (valeurs oubliées). Hors de question de mettre en place des heuristiques complexes telles que celles implémentées par les navigateurs pour afficher du contenu à tout prix.
Avec le temps, je me rends compte aussi que le principe de Postel tend à être incompatible avec le principe "fail fast", qui consiste à dire qu'une erreur devrait survenir le plus tôt possible (et donc que, justement, un programme ne devrait pas chercher à corriger ou à ignorer les erreurs, mais plutôt échouer rapidement et de manière visible. En effet, l'existence d'une erreur est justement le signe que quelque chose ne va pas, et qu'il y a probablement des soucis en amont. Faire remonter ces erreurs permet de mettre en évidence ces soucis et de les corriger une bonne fois pour toute.
mar. 27 oct. 2015 19:51:03 CET -
-
link
- http://www.bortzmeyer.org/principe-robustesse.html
génie-logiciel postel programmation
Iterative Vs Incremental
"IterativeDevelopment means:
I write loads of stuff that's a complete mess
I go through it throwing out the irrelevant drivel, expanding on the important bits, and sorting out the structure
I go through it again now I can start to see the shape of it, sorting it some more
I go through it yet again, etc, until it's GoodEnough
IncrementalDevelopment means:
I write part one
I write part two
I write part three, etc, until the book is finished
[...]
So in practice, at least in XP practice, your development is both incremental and iterative.
-- StephenHutchinson
The danger is when people confuse the two. I saw a 200 person project iterating on their requirements (allowing arbitrary amount of change) when they should have been incrementing through their requirements, and incrementing & iterating (as you describe) through their design. They were, of course, not making any progress. Also saw a 100 person project claiming they were iterating through their entire novel, when in fact they were doing neither - they were stuck in the mud. They needed to get at least some part working first so they could tell they were moving - once again, needed incrementing as a base.
-- AlistairCockburn"
Image de la miniature : http://www.applitude.se/images/inc_vs_ite.png
lun. 19 oct. 2015 07:17:42 CEST -
-
link
- http://c2.com/cgi/wiki?IterativeVsIncremental
programmation génie-logiciel
I write loads of stuff that's a complete mess
I go through it throwing out the irrelevant drivel, expanding on the important bits, and sorting out the structure
I go through it again now I can start to see the shape of it, sorting it some more
I go through it yet again, etc, until it's GoodEnough
IncrementalDevelopment means:
I write part one
I write part two
I write part three, etc, until the book is finished
[...]
So in practice, at least in XP practice, your development is both incremental and iterative.
-- StephenHutchinson
The danger is when people confuse the two. I saw a 200 person project iterating on their requirements (allowing arbitrary amount of change) when they should have been incrementing through their requirements, and incrementing & iterating (as you describe) through their design. They were, of course, not making any progress. Also saw a 100 person project claiming they were iterating through their entire novel, when in fact they were doing neither - they were stuck in the mud. They needed to get at least some part working first so they could tell they were moving - once again, needed incrementing as a base.
-- AlistairCockburn"
Image de la miniature : http://www.applitude.se/images/inc_vs_ite.png
lun. 19 oct. 2015 07:17:42 CEST -
-
link
- http://c2.com/cgi/wiki?IterativeVsIncremental
programmation génie-logiciel
UMLet – Créez facilement vos diagrammes UML sous GNU/Linux – La vache libre
Je me souviens que, quand j'étais étudiant (ah le vieux !), c'était un cauchemar pour trouver un éditeur UML complet.
J'ai du en essayer des dizaines à l'époque, des grosses usines à gaz hors de prix (Rational Rose, Visual Paradigm, Borland Together, Jude, UML pour Visio, ...) jusqu'aux petit projets open source (Umbrello, Dia, ...) sans en trouver un seul qui (i) respecte le standard UML dans son intégralité (tous les types de diagrammes) et (ii) permette de personnaliser les formes.
Le seul vraiment potable, c'était StarUML, un petit éditeur mais très complet. Hélas, il n'était plus maintenu depuis 2005.
http://fr.wikipedia.org/wiki/StarUML
Cet UMLet a l'air très sympa cela dit, et très personnalisable.
ven. 19 sept. 2014 09:27:04 CEST -
-
link
- http://la-vache-libre.org/umlet-creez-facilement-vos-diagrames-uml-sous-gnulinux/
uml modélisation génie-logiciel
J'ai du en essayer des dizaines à l'époque, des grosses usines à gaz hors de prix (Rational Rose, Visual Paradigm, Borland Together, Jude, UML pour Visio, ...) jusqu'aux petit projets open source (Umbrello, Dia, ...) sans en trouver un seul qui (i) respecte le standard UML dans son intégralité (tous les types de diagrammes) et (ii) permette de personnaliser les formes.
Le seul vraiment potable, c'était StarUML, un petit éditeur mais très complet. Hélas, il n'était plus maintenu depuis 2005.
http://fr.wikipedia.org/wiki/StarUML
Cet UMLet a l'air très sympa cela dit, et très personnalisable.
ven. 19 sept. 2014 09:27:04 CEST -
-
link
- http://la-vache-libre.org/umlet-creez-facilement-vos-diagrames-uml-sous-gnulinux/
uml modélisation génie-logiciel
Software Engineering Body of Knowledge (SWEBOK)
L'IEEE a publié un document recensant l'ensemble des connaissances que les jeunes ingénieurs devraient avoir acquis à la fin de leur cursus.
Même s'il s'agit en effet du "software engineering à papa" et que je reste amateur de développement agile, ces pratiques doivent être connues.
Et hélas, pour un très grand nombre d'écoles d'ingénieur, on en est vraiment très loin.
mar. 05 févr. 2013 12:05:54 CET -
-
link
- http://www.swebok.org/
génie-logiciel
Même s'il s'agit en effet du "software engineering à papa" et que je reste amateur de développement agile, ces pratiques doivent être connues.
Et hélas, pour un très grand nombre d'écoles d'ingénieur, on en est vraiment très loin.
mar. 05 févr. 2013 12:05:54 CET -
-
link
- http://www.swebok.org/
génie-logiciel
Ce journal est basé sur Ginger, un gestionnaire de lien minimaliste développé dans le cadre d'un stage de perfectionnement. Pour plus d'informations, consulter le wiki consacré à mes projets personnels.