Débat : Le syndrôme de l'outil magique ou de la boîte noire, négligeons nous leurs coûts d'apprentissage et d'adaptation ?

rakakabe

Membre habitué

Le 06/06/2009 à 20:13

Pour ma part, j'aime bien le passage :

Envoyé par benwit

... des outils et/ou framework qui font croire au premier venu qu'il peut tout faire simplement, ...

Vade Retro RAD et companie.

0

0

Braillane

Membre actif

Le 06/06/2009 à 21:08

Pour ma part je n'utilise que très peu les frameworks, uniquement ceux qui ont été approuvé et dont l'effet productif est "prouvé".

Par contre, je me suis fait comme religion de ne jamais (ô grand dieu non jamais ^^) utilisé d'ORM. Je n'en vois vraiment pas l'avantage, le gain de temps est à mon sens minime et l'effet "boite noire" comme tu disais est à mon avis trop important et apporte même à mon avis de la confusion dans la séparation des couches. En plus, j'ai l'impression que forcément en utilisant un framework je perdrais forcément en performance et tout sa, juste parce que j'avai la flemme de faire mon CRUD...

J'aimerais bien une réaction sur mon opinion, car du fait de ma réticence, j'ai du coup assez peu d'expérience avec les ORM, et je me demande sincérement qui y voit un réel avantage!

0

benwit

Rédacteur

Le 06/06/2009 à 22:29

Braillane, c'est intéressant ce que tu dis ...

Récemment, en réaction à un post de SQL Pro, j'ai présenté un peu mon point de vue des ORM.

Pour résumer, pour moi, le principale avantage d'un ORM, c'est l'indépendance par rapport à la base de données (même si je comprends que tout le monde n'a pas besoin d'une telle indépendance)

J'aime bien les bases de données relationnelles, elles sont de bons produits.
Un petit framework comme Ibatis permet d'externaliser les requêtes et on garde la main sur les requêtes SQL. Si on utilise uniquement du SQL standard, on reste indépendant de la base de données.

Utiliser un ORM comme hibernate (via JPA car je préfère les standards) permet de garder l'indépendance en faisant des requêtes optimisées pour chaque SGBD. On gagne donc sur un plan par rapport à du SQL standard mais l'utilisation de l'ORM a un coût. Je ne suis ni assez expert en bdd ou en ORM pour avoir un avis tranché au sujet des performances.

Ce que je peux dire, c'est que je n'aime pas ce lien objet/relationnel qu'il faut maintenir et avec les annotations, déléguer à hibernate la création et la mise à jour de la base en live durant la phase de développement est un vrai plaisir car je n'ai pas de scripts sql et de mapping à maintenir en plus (Je comprends cependant qu'un schéma de base de données généré automatiquement puisse déplaire à un DBA car les outils de génération de code ne me satisfont pas mieux). En production, on doit pouvoir surement optimiser la base et/ou l'orm ...

En revanche, ce que j'aime moins avec hibernate (comme avec jsf), c'est l'aspect boite noire. Sorti des cas d'écoles qui fonctionnent bien (dans les livres, docs et cie), dès qu'on se frotte à un cas réel un peu compliqué (lien n/n bidirectionnel entre deux classes qui dérivent d'autres classes ...), dès qu'on a un truc qui marche pas, si on ne veut pas faire du déboguage expérimental (essais/erreurs), on doit comprendre ce que fait le framework et si c'est toujours intéressant car on apprend des trucs, on voit les limites, on imagine de meilleurs façon de faire, etc... on a au final passé du temps pour cela et c'était donc moins productif que prévu ....

Comme le dit un collègue, le framework doit me faire gagner du temps, je n'ai pas à savoir comment ça marche ... C'est un point de vue qui se défend.

Je suis architecte dans l'âme et j'aime bien construire mes solutions, me frotter à des difficultés pour les résoudre. J'ai la main pour corriger ce qui ne vas pas. C'est un autre point de vue. Malheureusement cela à un coût ...

Le point de vue intermédiaire entre l'approche "j'utilise les frameworks comme des boites noires" (je gagne du temps mais je ne m'enrichis peu et je croise les doigts ne ne pas avoir d'erreurs) et l'approche "je fais tout moi-même" (je m'enrichis et perd du temps) est l'approche "j'utilise les frameworks en les comprenant" (le temps gagné est réinvesti dans l'enrichissement personnel).
C'est ce que je veux dire par : si je ne gagne pas de temps, je n'en perd pas ...

0

zeavan

Membre éclairé

Le 07/06/2009 à 3:02

Interressant, mais encore une fois tout depend des delais et egalement des types de projets.

L'envie de tout faire soi-meme est a mon gout un caprice de developpeur qui peut justement lui faire passer a cote de belle chose par example eviter un ORM et passer moins de temps sur le module qui exploite les donnees, representation en 3D des informations.

J'ai egalement ete capricieux et avec le temps j'ai du prendre des risques sur certain projets et je me suis essaye a ces boites noires des fois avec success et des fois (et bien j'ai passe des nuits a tout recommencer).

Avec le temps on apprend a connaitre les limites de ces frameworks ou plutot les cas concrets dans lesquels on peut se servir de ces memes sans aucuns risques.

Je dirai que le seul inconveniant c'est le temps d'adaption qu'il faut pour s'adapter a certain nouveau produit qui apparaissent sur le marche.
Lorsque l'on developpe ses propres framework et bien il evolue avec le temps et le temps d'aprentissage est lineaire.
Alors qu'avec les autres produits qui peuvent tres vite devenir obsoletes ou pas et bien cela demande des pics d'apprentissages qui ne sont pas toujours forcement en synchronization avec le temps que l'on dispose.

0

souviron34

Expert éminent sénior

Le 07/06/2009 à 14:36

en gros, je suis 100% d'accord avec benwit...

Je l'ai déjà noté dans plusieurs débats...

Plus précisément :

Envoyé par benwit

Utilisez vous des outils sophistiqués, des frameworks ? Lesquels ? et est-ce que le temps investi en vallait la peine ?

Le plus rarement possible.

Je pense que cela amène à des implications non souhaitées et non souhaitables sur l'achitecture (et les modules) créés, qui ne sont valables que pour ce framework, et qui ne sont donc pas parties d'un découpage "fonctionnel" reprenable facilement (donc difficilement évolutif).

Alors à part cvs, Rational, ou équivalents pour la gestion des versions...

Envoyé par benwit

Avez vous des exemples positifs / négatifs ?

Négatifs uniquement, des 2 derniers projets sur lesquels j'ai travaillé...

Même argument que ci-dessus..

Envoyé par benwit

Vu l'évolution des outils et des frameworks, quand vous en maîtriser un, ne sera t'il pas déjà obsolète ?

Pas forcément, mais pas sûr non plus.. Trop d'incertitudes, pour un gain minimal, voire négatif.

Envoyé par benwit

Quelle est votre attitude ?
- rester sur vos acquis (utilise votre techno préférée pour tout faire : anti pattern du marteau en or) ?
- touche à tout (risque de dispersion ?)
- position intermédiaire ( suiveur... laisser les autres faire les bons ou mauvais choix )

en gros, le 1 avec un peu de 3.

Tant que je fais ce qui est demandé, je me contente du 1, car je maîtrise l'architecture.

Si jamais il y a réellement besoin (ou si j'y suis obligé), je prend. Mais dans 99% des cas c'est parce que j'y suis obligé.

Maintenant, ce n'est pas tout à fait le même cas avec des bibliothèques :

Si les fonctionalités sont simples, je me passe de biblothèques "boîtes noires" externes (par exemple "traitements de chaînes" ou "traitements de listes chaînées" ou "traitements de TAD" en C) .
Si les fonctionalités sont restreintes par rapport à l'envergure du projet, mais complexes, bien entendu je prend (par exemple biblothèque pour traitements d'images GIF, pour production de films MPEG, etc etc)

0

GrandFather

Expert éminent

Le 07/06/2009 à 15:18

Etant responsable d'une petite équipe de développement (4 personnes), je vois immédiatement ce que peut apporter un framework, conjointement aux gains de productivité : une harmonisation des normes de codage et d'architecture, un dénominateur commun pour une équipe composée de développeurs ayant des savoirs et des niveaux de compétences différents. En l'occurrence, il s'agit de Zend Framework, pour du développement Web.

Il existe toutefois un pan de l'application où je répugne à utiliser des outils sophistiqués, c'est celui de la couche relationnelle : j'exige de mon équipe une bonne connaissance de SQL (vues, procédures stockées, etc), et l'ORM employé se cantonne à un mapping simple objet/table ; je trouve personnellement la complexité de certains outils tel que Hibernate (et je parle même pas des EJB...) rédhibitoire.

Les efforts à consentir en terme d'apprentissage ne sont pas à négliger, mais les gains de productivité sont réels par rapport à avant (sans framework).

0

souviron34

Expert éminent sénior

Le 07/06/2009 à 15:29

Envoyé par benwit

Ce que je peux dire, c'est que je n'aime pas ce lien objet/relationnel qu'il faut maintenir et avec les annotations,

Envoyé par GrandFather

Il existe toutefois un pan de l'application où je répugne à utiliser des outils sophistiqués, c'est celui de la couche relationnelle : j'exige de mon équipe une bonne connaissance de SQL (vues, procédures stockées, etc), et l'ORM employé se cantonne à un mapping simple objet/table ; je trouve personnellement la complexité de certains outils tel que Hibernate (et je parle même pas des EJB...) rédhibitoire.

pour rebondir sur vos 2 messages, et bien que je n'utilise pas ce dont vous parlez, j'ai observé (à mon grand désarroi

), en particulier sur le forum conception, et dans le projet sur lequel je suis aujourdhui, que justement les liens avec les BDs, relationnelles ou non, qui d'après les "méthodes" diverses portent des noms divers, que ce soit "métier" ou autres, sont à mon avis beaucoup beaucoup beaucoup trop forts....

De mon point de vue, pratiquement tout le soft, y compris le métier, ne devrait même pas savoir si on est lié à telle ou telle base, via tel ou tel langage de requête ou telle ou telle structure (Oracle, Access, ou autre, bds réparties ou centralisées).

Il semble que, dès la phase de conception, la couche intermédiaire ne soit pas séparée réellement..

Or j'ai l'impression (et on rentre plus dans le débat d'ici) que le fait d'avoir des frameworks et des "outils" boite-noire (les OLE et autres) facilitent ce glissement de conception, qui à mon avis est un bien mauvais penchant, puisqu'il lie le concept de récupération de données à l'outil utilisé...

Non ?

0

GrandFather

Expert éminent

Le 07/06/2009 à 15:57

Envoyé par souviron34

Or j'ai l'impression (et on rentre plus dans le débat d'ici) que le fait d'avoir des frameworks et des "outils" boite-noire (les OLE et autres) facilitent ce glissement de conception, qui à mon avis est un bien mauvais penchant, puisqu'il lie le concept de récupération de données à l'outil utilisé...

Ce serait plutôt le contraire. Le principe d'un framework moderne comme hibernate est de rendre abstraite la couche données, et de lui déléguer tous les détails sordides de la persistance des données. Le souci, ce qu'a relevé benwit, c'est que lorsque quelque chose cloche, on est assez vite désemparé... C'est pour cela que je préfère m'en tenir à un niveau d'abstraction moindre, et utiliser des ORM « légers ». D'accord ça lie l'application à une technologie (en l'occurence relationnelle), mais c'est un choix aussi fait en fonction du contexte (le SI de l'entreprise) : la probabilité qu'on me demande de modifier la couche persistance du jour au lendemain, sans modification de code de l'application, est quasiment nulle.

0

hegros

Membre Expert

Le 07/06/2009 à 16:49

Envoyé par benwit

[*]Utilisez vous des outils sophistiqués, des frameworks ? Lesquels ? et est-ce que le temps investi en vallait la peine ?

C'est quoi un outil ou un framework sophistiqués parce qu'en tant que concepteur-développeur on programme et opter pour un langage de programmation c'est opter déjà pour le framework 'standard' du langage et des frameworks compatibles.

Sinon il y a le framework de test dunit et nunit pour les tests et oui le temps est largement compensé au fait qu'il aide à la réalisation et à la maintenance des programmes de même qu'un outil pour la construction et le déploiement semi-automatique des versions.

[*]Vu l'évolution des outils et des frameworks, quand vous en maîtriser un, ne sera t'il pas déjà obsolète ?

Plus avant qu'aujourd'hui probablement plus vrai pour les framework web, cependant il y a des frameworks comme .NET, JAVA, C ou C++ qui ont une stratégie sur long terme et une rude expérience.

De plus pour .NET cela voudrait-il que MS deviendrait obsolète ?

[*]Quelle est votre attitude ?

rester sur vos acquis (utilise votre techno préférée pour tout faire : anti pattern du marteau en or) ?
touche à tout (risque de dispersion ?)
position intermédiaire ( suiveur... laisser les autres faire les bons ou mauvais choix )

Attendre qu'un framework soit suffisamment éprouvé et suffisamment documenté pour s'assurer de la facilité d'apprentissage et d'intégration dans des projets.

Réaliser des projets pilotes pour mettre à l'épreuve telle ou telle technologie/framework

Apprendre des projets open-source et des entreprises qui utilisent telle ou telle framework paraissant dans framework star magazine

0

benwit

Rédacteur

Le 07/06/2009 à 18:09

Envoyé par hegros

C'est quoi un outil ou un framework sophistiqués

Framework était utilisé sans adjectif même si comme l'a souligné souviron, on pourrait distinguer ceux qui implémentent des fonctionnalités simples de ceux qui implémentent des fonctionnalités complexes (quoique le niveau de difficultés est relatif).

L'adjectif sophistiqué était pour outil car les outils qui ne font qu'un truc mais le font bien sont de réels plus. Par outils sophistiqués, je pensais plutôt à des ETL comme Talend ?
J'ai l'impression que c'est super puissant mais qu'il faut du temps pour maitriser l'outil ...

0

Identifiez-vous

Créer un compte

Débat : Le syndrôme de l'outil magique ou de la boîte noire

Négligeons nous leurs coûts d'apprentissage et d'adaptation ?

Identifiant
Mot de passe

Mot de passe oublié ?

Identifiez-vous

Créer un compte

Débat : Le syndrôme de l'outil magique ou de la boîte noire Négligeons nous leurs coûts d'apprentissage et d'adaptation ?

Débat : Le syndrôme de l'outil magique ou de la boîte noire

Négligeons nous leurs coûts d'apprentissage et d'adaptation ?