Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 ?

Le , par benwit

42PARTAGES

0  0 
Le syndrome de l'outil magique ou de la boite noire.

Si on met de côté :
  • l'apprentissage où il est enrichissant de faire les choses par soi-même
  • l'innovation où il peut être intéressant d'explorer de nouvelles voies

Dans une optique de productivité, ne pas réinventer la roue et réutiliser des briques existantes est un bon conseil puisque la finalité est de gagner du temps et/ou de délivrer de meilleurs produits.

N'avez vous jamais entendu :
C'est simple, utilisez cet outil, il suffit de cliquez !
ou bien :
Utilisez ce framework, il vous mâche le travail ...
C'est souvent vrai jusqu'au moment :
  • où vous vous mettez à l'utiliser et vous vous rendez compte que ce n'est pas aussi bien que cela semblait l'être initialement.
  • où vous vous rendez compte suite à une erreur ou suite à un besoin très particulier qu'il vous faudrait comprendre le fonctionnement interne pour avancer ...


Les outils devraient être intuitifs mais s'ils ne le sont pas, vous devez passer du temps pour apprendre à les utiliser ... temps qu'ils étaient censés vous faire économiser.

Les frameworks devraient être simple à utiliser, à étendre mais s'ils ne le sont pas, vous passez du temps à comprendre les rouages internes ... temps qu'ils étaient censés vous faire économiser.

Et je ne parle pas des outils et/ou framework qui font croire au premier venu qu'il peut tout faire simplement, il y a quand même des concepts élémentaires à intégrer avant ... (temps de formation/expérience)

J'aimerai débattre de ce sujet avec vous et voici quelques pistes de réflexion :

  • Utilisez vous des outils sophistiqués, des frameworks ? Lesquels ? et est-ce que le temps investi en vallait la peine ?
  • Avez vous des exemples positifs / négatifs ?
  • Vu l'évolution des outils et des frameworks, quand vous en maîtriser un, ne sera t'il pas déjà 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 )



Pour ma part, je ne sais pas si au final, je gagne du temps. Je crois juste que je n'en perds pas.

A vous ...

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de rakakabe
Membre habitué https://www.developpez.com
Le 06/06/2009 à 20:13
Pour ma part, j'aime bien le passage :

Citation Envoyé par benwit Voir le message
... des outils et/ou framework qui font croire au premier venu qu'il peut tout faire simplement, ...
Vade Retro RAD et companie.
0  0 
Avatar de Braillane
Membre habitué https://www.developpez.com
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  0 
Avatar de benwit
Rédacteur https://www.developpez.com
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  0 
Avatar de zeavan
Membre éclairé https://www.developpez.com
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  0 
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
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 :

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

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

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

Citation Envoyé par benwit Voir le message
  • 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 :

  1. 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) .
  2. 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  0 
Avatar de GrandFather
Expert éminent https://www.developpez.com
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  0 
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 07/06/2009 à 15:29
Citation Envoyé par benwit Voir le message

Ce que je peux dire, c'est que je n'aime pas ce lien objet/relationnel qu'il faut maintenir et avec les annotations,
Citation Envoyé par GrandFather Voir le message
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  0 
Avatar de GrandFather
Expert éminent https://www.developpez.com
Le 07/06/2009 à 15:57
Citation Envoyé par souviron34 Voir le message
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  0 
Avatar de hegros
Membre Expert https://www.developpez.com
Le 07/06/2009 à 16:49
Citation Envoyé par benwit Voir le message

[*]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  0 
Avatar de benwit
Rédacteur https://www.developpez.com
Le 07/06/2009 à 18:09
Citation Envoyé par hegros Voir le message
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  0