DxO : je jette l'éponge !

[Pat75]

Bonjour,

Je m'inscris totalement en faux contre cette légende urbaine dont je ne connais pas l'origine. J'enseigne et j'utilise le framework .Net depuis des années et c'est un des environnements de développement les moins bogués et les plus propres que j'ai eu à utiliser au cours de ma carrière.

Par contre, et c'est probablement par là que beaucoup d'équipes de développement pèchent, il faut comprendre que l'utilisation du framework .Net implique un certain nombre de pré-requis:

- Bonne connaissance des principes de la programmation objet
- Bonne connaissance de XML
- Utilisation d'une méthodologie adaptée
- Utilsation de méthodes de test modernes (développement piloté par les tests, design patterns, tests anti-régression,...).

Si je ne me prononce pas sur les 2 premiers points, je pense que DxO a démontré à de nombreuses occasions depuis la sortie de la V5 qu'ils ne sont pas du tout au point sur les 2 derniers. Ça se voit comme le nez au milieu de la figure.

J'ai par ailleurs déjà commenté sur le fait que DOP n'est pas un programme .Net "pur" mais qu'il utilise la technologie Interop. Pour les non-initiés, cela veut dire qu'il "mélange" la technologie .Net avec la technologie de développement "classique" Win32. Cette manière de faire n'est recommandée que si l'on n'a pas à disposition dans leur version .Net des composants que l'on utilisait en Win32. En gros, cela signifie pour DOP que les composants utilisés dans la version 4.x qui n'ont pas trouvé leur équivalent en .Net ou qui n'ont pas pu être portés sous .Net par manque de temps, de compétences ou de ressources continuent d'être utilisés tels quels via Interop. Cette technologie rend les applications .Net beaucoup plus vulnérables. Pesonnellement et c'est ce que je conseille à mes clients, j'essaierais à tout prix de l'éviter en production.

Tout cela combiné à un non respect systématique des standards en matière d'interface utilisateur et on obtient le résultat que l'on sait.

--
Patrick

+1 des amis développeurs m'ont dit exactement la même chose.
Framework.net est un excellent outil, et comme tout outil, il doit être parfaitement adapté aux buts et moyens que l'on veut se donner avec des gens compétents.

[brainois]

Framework.net est un excellent outil, et comme tout outil, il doit être parfaitement adapté aux buts et moyens que l'on veut se donner avec des gens compétents.

HUMOUR:

Je ne discuterai pas de Framework.net, connais pas..................

Mais, si c'est un excellent outil, pourquoi devoir parfaitement l'adapter aux buts et..........

Ne faudrait - il pas dire: C'est un excellent outil, mais il faut adapter ses moyens et ........:bash:

[Pat75]

Je vois que tu es toujours vigilant
Sur tes conseils, j'ai fais la mise-à-jour, acheté le livre sur DXO, installé, mais pas encore utilisé intensément (trop de choses simultanées en route).
A suivre...

[MainSoft]

Ne faudrait - il pas dire: C'est un excellent outil, mais il faut adapter ses moyens et ........

Pour le dire plus clairement:

Le framework .Net est une plate-forme de développement, propre, moderne, ambitieuse, riche, portable et très complète. Son taux de bugs, non nul, est incroyablement plus bas que la moyenne quand on considère la quantité astronomique de code que le framework contient. Cette plate-forme oblige le développeur à entrer dans une méthodologie de programmation orientée objet et ne faisant aucune concesssion aux approximations. J'estime le temps d'appropriation de cette plate-forme par un ingénieur de développement a environ 5 ou 6 mois s'il part de zéro (c-à-d qu'il ne connaît pas la programmation objet, les méthodologies objet - UML-, XML, les design patterns et le TDD - Test Driven Development).

Et c'est là que le bât blesse. La culture de la programmation objet n'est pas aussi développée que cela, surtout en France et en particulier dans le monde universitaire et académique en général. Par ailleurs, dans les sociétés qui développent, il y a une forte proportion de programmeurs autodidactes qui se sont formés avec Visual Basic et autres outils de type "RAID" (comme Delphi) avec lesquels ils ont pris de très mauvaises habitudes.

Personne ne peut monter du jour au lendemain dans une Formule 1 ou barrer un catamaran de 20 mètres sans préparation. Le framework .Net, c'est pareil. Il faut se former, passer du temps et là, il y a aura ensuite un gros bénéfice en retour: qualité, temps de développement raccourci, stabilité et compacité du code. Je le sais, je l'ai fait et je peux donner des chiffres réels.

Si on fait l'impasse sur la première phase (ce qui arrive trop souvent au vu de mon expérience chez certains clients), le résultat peut être absolument catastrophique. Il est facile ensuite de jeter la pierre sur l'outil en proclamant qu'il est bogué. En fait, un logiciel développé avec le framework .Net en utilisant les bonnes méthodologies d'analyse et de test devrait arriver sur le marché avec un taux de bugs extrêmement faible.

Et je n'ai jamais rencontré un seul développeur ou chef de projet qui prétende valablement le contraire. Même le monde du libre et les linuxiens, ennemis jurés de tout ce qui sort de chez Microsoft, reconnaissent la qualité de ce framework. À tel point qu'il est implanté sous Linux. Si DxO Optics Pro n'utilisait pas la technologie Interop comme précisé plus haut, il serait portable sous Linux avec peu de modifications.

--
Patrick

[brainois]

Merci Pat,
je pense que j'avais donc raison, il faut s'adapter à l'outil.
Comme d'ailleurs dans de nombreuses discupline comme tu le soulignes par ailleurs

[rouzik]

Désolé pour le déterrage de topic mais là il y a de quoi réagir!

J'estime le temps d'appropriation de cette plate-forme par un ingénieur de développement a environ 5 ou 6 mois s'il part de zéro (c-à-d qu'il ne connaît pas la programmation objet, les méthodologies objet - UML-, XML, les design patterns et le TDD - Test Driven Development).

Un ingénieur en developpement logiciel qui n'a jamais fait dans ses études de POO ou d'UML a du avoir son diplôme dans une pochette surprise. Depuis 10-15 ans c'est au programme de n'importe quel diplôme de dev niveau BAC+5. La POO est même au programme (JAVA/C++) des DUT depuis une dizaine d'années, Java a changé le paysage et les besoins. Par contre les DP et TDD, on n'y est pas encore.

Et c'est là que le bât blesse. La culture de la programmation objet n'est pas aussi développée que cela, surtout en France et en particulier dans le monde universitaire et académique en général.

Justement c'est tout le contraire. Non seulement depuis 2000-2002 l'objet est partout dans le monde du developpement professionnel, mais niveau universitaire la POO est enseignée depuis bien longtemps (JAVA, Eifel, C++ etc...), avant même que son utilisation ne soit généralisée dans le monde professionnel! Pour une fois l'enseignement univiversitaire avait une longueur d'avance en la matière. Aujourd'hui l'objet est partout, tous les langages y sont passés quand ils ne le sont pas nativement : Python, Java, C++, PHP, Ruby, C++, C# etc... La France est même surement un des pays les plus avancés questions objets.

Par ailleurs, dans les sociétés qui développent, il y a une forte proportion de programmeurs autodidactes qui se sont formés avec Visual Basic et autres outils de type "RAID" (comme Delphi) avec lesquels ils ont pris de très mauvaises habitudes.

N'oublie pas que Delphi c'est du Pascal Objet. Implémentation batarde oui, pas poussées jusqu'au bout de la logique, mais qui donne des habitudes objets. Quand à la forte proportion dont tu parles, je la trouve vraiment minoritaire. Que ça soit parmi mes collègues développeurs, chez des prestatires de sociétés de services qui bossent avec nous ou dans des boîtes de développement qui nous fournissent des solutions logicielles, pratiquement tout le monde est passé à l'objet.

Le framework .Net, c'est pareil. Il faut se former, passer du temps et là, il y a aura ensuite un gros bénéfice en retour: qualité, temps de développement raccourci, stabilité et compacité du code. Je le sais, je l'ai fait et je peux donner des chiffres réels.

Tout à fait d'accord avec toi, excepté pour la compacité du code. Un framework justement a cet inconvénient principal, celui d'augmenter la masse de code à force de séparation du code et d'héritage en cascade.

Même le monde du libre et les linuxiens, ennemis jurés de tout ce qui sort de chez Microsoft, reconnaissent la qualité de ce framework. À tel point qu'il est implanté sous Linux. Si DxO Optics Pro n'utilisait pas la technologie Interop comme précisé plus haut, il serait portable sous Linux avec peu de modifications.

Dotnet est surement la meilleure chose produite par Microsoft depuis très longtemps. Ils n'ont pas inventé un truc révolutionnaire, mais ils ont vraiment étudié leurs concurrents, surtout Java de Sun, pour sortir une plate forme de dev avec tous les avantages mais sans les inconvénients. C'est très intelligent de leur part. C'est une plateforme réussie, solide, fiabilisée et vraiment maléable aux besoins. Par contre tout comme Java, cela demande un apprentissage volontaire de qq mois.

Visiblement les développeurs de DxO ont loupé le coche car la version 5 apparait vraiment comme bancale comme si elle avait été basculé sans étude préalable suffisante sur une nouvelle techno et sans effectuer tous les tests unitares nécessaires. Sinon ensuite il faut colmater les brèches avec toutes les régressions possibles. Dans ce genre de cas, bien souvent il vaut mieux reprendre toute la conception et le développement à zéro.

Dommage pour DxO, c'est un bon produit mais vraiment trop instable et trop gourmand dans sa version 5. C'est d'autant plus dommage que c'est pratiquement le seul logiciel grand public pour windows développé par une bôite française. J'espère qu'ils repartiront à zéro pour la version 6 car leur survie en dépend.

Désolé pour le coup de gueule, mais ça m'énerve quand on casse systématiquement l'enseignement informatique français alors qu'il n'est pas si mauvais que cela et que c'est plutôt le monde professionnel qui est souvent en retard niveau techno.