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, Rédacteur
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 ...


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Franck SORIANO Franck SORIANO - Membre expert https://www.developpez.com
le 19/06/2009 à 13:47
Citation Envoyé par Michael REMY  Voir le message
framework : ensemble de fonctions/objets englobant une couche d'abstraction d'accès au données et une certaine (minimum quand-même) génération de présentation (via template).

EDI = outil graphique destiné à moins utiliser le clavier et valoriser la souris ainsi qu'une bibliothèque de fonctions/objet/syntaxe/snippets

AGL = EDI + notion de modèle relationnel/UML des données

RAD = framework + agl + edi + production d'aspect graphique automatisé (en tout cas plus 'userfriendly' que le fait un framework)

Je ne suis pas vraiment d'accord avec tes définitions.

Je dirais plutôt :

Framework = Cadre de travail. Un framework est un ensemble de composants/librairies qui va servir à structurer l'application et les développements. Toute application fait nécessairement appel à un framework, sous une forme ou une autre. Après, il existe des frameworks très génériques (par exemple le framework .Net) et des frameworks spécialisés (ORM, gestion des traces/Logs, gestionnaires de fenêtres...). Ils fournissent un ensemble d'outils pour réaliser un service donné.

EDI = Environnement de développement intégré. On peut y mettre pratiquement tout ce qu'on veut. Du moment qu'on peut tapper du code et le compiler/exécuter... et qu'on est pas obligé de tout faire en ligne de commandes.

AGL = Atelier de Génie logiciel : C'est un ensemble d'outils qui doivent couvrir les besoins en termes de génie logiciel. Ca inclus donc bien évidemment un IDE, mais aussi des outils de conception, gestion de configuration, gestion de projet, gestion des exigences, tests...
La notion d'Atelier suppose qu'il y est un minimum d'intégration et d'interfaces entre eux.

RAD : Il faut d'abord se mettre d'accord sur quoi on parle. RAD a la base, c'est "Rapid Application Development" et il s'agit d'une méthodologie, essentiellement basée sur le principe de maquettage/prototypage. L'idée étant de développer des maquettes et prototypes qu'on peut présenter au client tout au long des développements pour que ce dernier puisse réagir au plus tôt et n'attende pas la livraison finale pour se rendre compte que l'appli ne correspond pas à ses besoins.
Ensuite, de la méthode on a rapidement fait l'abus de langage : RAD = Outils RAD.
Ce qui donne un AGL qui le plus souvent se limite à un IDE orienté : Je fais tout graphiquement en cliquant à droite à gauche.

Personnellement, je trouve qu'il suffit de regarder une appli VB ou Delphi pour se rendre compte des limites du RAD :
- On développe tout en prenant des composants tout fait, qu'on configure à coup de propriétés en espérant parvenir au résultat voulu.
- Sauf que les composants en question vont certes être capable de faire ce qu'on veut, mais ils en feront également un peu plus, pour le cas où on se trouverait dans un cas qu'ils peuvent gérer d'une certaine façon, mais qu'on ne leur demande pas.
- Tôt ou tard, le composant en fait un peu trop, et on tombe sur des avalanches de bug dû à des effets de bords introduits par ces composants.
- Au lieu de gagner du temps pour pouvoir se concentrer sur les tâches essentielles de l'appli, on passe son temps à faire des verrus pour supprimer des comportements et effets de bords non désirés.

Le pire dans tout ça, c'est que le plus souvent, on ne sait même pas que le composant va faire telle ou telle chose en plus. On ne s'en rend pas compte au moment des tests, et sa explose une fois en prod.

Autre problème qu'on rencontre très rapidement (remarque c'est la même chose avec les frameworks trop évolués) : Les composants sont conçus pour pouvoir faire un maximum de choses et être réutilisés dans un maximum de situations différentes.
Du coup, ce sont de vrai usines à gaz qui effondrent les perfs inutilement. Au final, tu es obligé de réécrire complètement les composants qui étaient censés te faire gagner du temps pour pouvoir avoir un résultat satisfaisant.

Donc en conclusion, je dirais plutôt que le RAD permet à des débutants qui maitrisent mal leur développement d'arriver malgré tout à un résultat moyen.

En revanche, l'ingénieur expérimenté atteind vite les limites du RAD, et pour pouvoir les dépasser, il faut y renoncer ! (ce qui ne veut pas dire qu'il faille pour autant renoncer aux outils, Delphi permet aussi de faire du très bon code ).
Avatar de clavier12AZQSWX clavier12AZQSWX - Membre confirmé https://www.developpez.com
le 20/06/2009 à 0:09
Le pire dans tout ça, c'est que le plus souvent, on ne sait même pas que le composant va faire telle ou telle chose en plus. On ne s'en rend pas compte au moment des tests, et sa explose une fois en prod.

je pense que là , tu te trompes de coupable.

Si l'utilisateur utilise un composant d'une façon différente pour lequel on l'a formé à l'utiliser, ce n'est pas la faute du composant.

Par exemple (je caricature), prenons une liste déroulante permettant de sélectionner une personne. Si par le plus grand des hasard, l'utilisateur s'aperçoit qu'il peut sélectionner plusieurs personne en même temps, alors que son métier et sa formation lui a inculqué d'en sélectionné qu'une, alors la personne est responsable de l'erreur, et non pas l'outil/composant.

Pour la définition de Framework, je reste sur ma position. Pour moi ce n'est qu'un ensemble de fonction/classes englobant des processus rébarbatif, connus et standardisé.
Avatar de Mac LAK Mac LAK - Inactif https://www.developpez.com
le 23/06/2009 à 17:58
Pour ma part, j'ai tendance à nettement séparer mes outils en fonction de ce que je veux faire...

Par exemple, j'ai beau être un fanatique de Delphi, je tire au canon direct sur le premier qui veut tenter de me faire un module "système" avec.

Inversement, entre faire une IHM complexe avec Visual C++ et la faire avec Delphi, y'a pas photo non plus : quand le développeur sous Visual en sera encore à mapper ses messages pour enfin avoir 3 colonnes dans son contrôle, celui sous Delphi aura fini l'IHM qui n'attendra plus que le code réel, et en multilingue en prime...

Par contre, j'estime qu'un bon RAD doit impérativement être extensible : je n'apprécierais pas autant Delphi s'il n'était pas possible de créer ses propres composants, y compris en mode conception !! La VCL est, en plus, une librairie extrêmement bien faite, avec suffisamment de niveaux d'abstraction pour pouvoir faire à peu près n'importe quoi.

Les tests doivent également être possibles facilement, et là, la vitesse de compilation a une importance non négligeable. Les RAD qui mettent 3 heures à compiler (merci CL, ou encore pire, GCC... ) ne sont PAS des RAD, point !! Le "R" de "RAD", c'est "Rapid", et passer 20 minutes à compiler quand d'autres RAD le font en 6 secondes, y'a pas photo à mon sens.

Côté frameworks, je suis par contre nettement plus réticent, surtout s'ils sont installés au niveau de l'OS et non pas "embarqués" dans le code exécutable final (ex : VCL Borland, pas nécessaire de la déployer sur l'OS même si c'est possible).
D'une part, les incompatibilités entre les différentes versions sont nombreuses, la rétrocompatibilité pas toujours excellente, et si jamais la technologie prends une claque c'est la cata : tout à refaire pour garantir la maintenabilité...

Pour moi, une "bonne" application se base donc sur une IHM développée en RAD, et des librairies (DLL/SO) écrites en langages spécialisés effectuant le traitement réel, éventuellement au travers d'un wrapper si nécessaire. Chaque module spécialisé (IHM incluse) doit pouvoir être refondu, inclus en changeant de technologie, sans remettre en cause les autres modules.

De plus, si l'on peut générer automatiquement du code (ex : couches de communication ou de test), c'est pas plus mal.
Avatar de souviron34 souviron34 - Expert éminent sénior https://www.developpez.com
le 23/06/2009 à 20:09
Je suis d'accord avec tout ce que tu dis, Mac, sauf ceci...

Citation Envoyé par Mac LAK  Voir le message
Pour moi, une "bonne" application se base donc sur une IHM développée en RAD, et des librairies (DLL/SO)


Là tu prends déjà un parti pris, qui n'est même pas évident que tu aies le droit (ou le loisir) de prendre :

Faire des DLL/SO suppose de les fournir séparément et que d'autres (éventuellement), puisse les utiliser..

On peut vouloir (ou être contraint) à ne fournir qu'un exécutable.

De même pour l'IHM : que le développement soit fait en RAD, soit (et même en plus que RAD, en prototype), entièrement d'accord.

Cependant, rien n'est moins sûr pour l'appli finale...

Par contre, quand tu dis :

Citation Envoyé par Mac LAK  Voir le message
Pour moi, une "bonne" application se base donc sur une IHM, et des librairies écrites en langages spécialisés effectuant le traitement réel, éventuellement au travers d'un wrapper si nécessaire. Chaque module spécialisé (IHM incluse) doit pouvoir être refondu, inclus en changeant de technologie, sans remettre en cause les autres modules.



c'est ce que je m'éreinte à faire comprendre , que ce soit dans ce genre de débats ou dans la partie Conception..

Et visiblement ce n'est pas la manière de penser la plus partagée...
Avatar de Mac LAK Mac LAK - Inactif https://www.developpez.com
le 24/06/2009 à 10:12
Citation Envoyé par souviron34  Voir le message
Là tu prends déjà un parti pris, qui n'est même pas évident que tu aies le droit (ou le loisir) de prendre :

Effectivement, on n'a pas toujours le choix... Sauf quand c'est moi qui décide, où je l'impose !
Après, si ça vire au truc monolithique inmaintenable, c'est la faute de celui qui a pris la décision de ne pas écouter les avis de ceux qui connaissent mieux que lui. On joue hélas souvent les Cassandre, en milieu pro...

Citation Envoyé par souviron34  Voir le message
Faire des DLL/SO suppose de les fournir séparément et que d'autres (éventuellement), puisse les utiliser..

Même sans forcément rendre les DLL réutilisables !! C'est surtout, pour moi, le fait d'avoir un module testable à part entière, et qui n'a donc pas besoin d'être re-validé lors d'une évolution s'il n'est pas binairement modifié. On passe juste les tests de non-régression, et zou, quelques jours de validation gagnés.

Citation Envoyé par souviron34  Voir le message
De même pour l'IHM : que le développement soit fait en RAD, soit (et même en plus que RAD, en prototype), entièrement d'accord.

Cependant, rien n'est moins sûr pour l'appli finale...

Disons qu'avec un BON RAD, l'appli finale n'est que l'évolution du prototype... Ceci étant dit, j'arrive à le faire avec Delphi / C++ Builder, mais les autres RAD que j'ai pu tripoter (peut-être pas forcément avec autant de connaissances dessus que les RAD Borland, je le reconnais) n'offraient pas cette possibilité, du moins pas au niveau qu'offre Borland.
C'est quand même les seuls RAD que j'ai vu qui permettent de passer une application en multilingue a posteriori sans coûter plus cher (en temps) que si on l'avait prévu dès le départ...

Citation Envoyé par souviron34  Voir le message
c'est ce que je m'éreinte à faire comprendre , que ce soit dans ce genre de débats ou dans la partie Conception..

Et visiblement ce n'est pas la manière de penser la plus partagée...

Tu n'es pas le seul : je me tue à faire comprendre que la documentation doit toujours être en accord avec le code (merci Doxygen et équivalents) et en français / anglais irréprochable, que le code doit être analysé statiquement (Lint et autres outils du même genre), et que chaque module doit être testable séparément et de façon automatique (en gros, "run module.test" et on a le résultat directement intégrable dans le cahier de recettes). Si j'allais jusqu'au bout de ma démarche, le code serait en plus passé au "beautifier" avant d'être mis en gestion de configuration, et on passerait également un outil de vérification des règles de codage...

Tout comme je me tue à dire que lorsque l'on découvre un bug, il faut ajouter un test à la batterie automatique permettant de le déclencher avec l'ancienne version, de montrer qu'il n'est plus là avec la nouvelle, et intégrer d'office ce test à la série de tests de non-régression.

Mais bon : les décideurs financiers semblent ne pas comprendre que filer 10% de temps de développement en plus et livrer un truc carré à un client (éventuellement avec des dérogations, mais au moins, elles sont CONNUES) coûte moins cher que de passer les corrections en garantie, ce qui a en plus souvent tendance à agacer le client...
Et je ne parle même pas du fait que reprendre un code deux mois après est plus "lent" que de faire de BONS tests alors que l'on est en plein dans le cambouis !
Avatar de chaplin chaplin - Membre expérimenté https://www.developpez.com
le 24/06/2009 à 10:36
Citation Envoyé par Michael REMY  Voir le message
je pense que là , tu te trompes de coupable.

Si l'utilisateur utilise un composant d'une façon différente pour lequel on l'a formé à l'utiliser, ce n'est pas la faute du composant.

Par exemple (je caricature), prenons une liste déroulante permettant de sélectionner une personne. Si par le plus grand des hasard, l'utilisateur s'aperçoit qu'il peut sélectionner plusieurs personne en même temps, alors que son métier et sa formation lui a inculqué d'en sélectionné qu'une, alors la personne est responsable de l'erreur, et non pas l'outil/composant.

Pour la définition de Framework, je reste sur ma position. Pour moi ce n'est qu'un ensemble de fonction/classes englobant des processus rébarbatif, connus et standardisé.

Les réflexions de Franck Soriano sont le fruit d'une longue experience sur le RAD et je partage ses conclusions.

Lorsqu'il dit que les composants font plus qu'on ne le demande, un bon exemple, c'est le 5ème défit Delphi pour faire un Sudoku Solver. Il n'y a aucun composant VCL qui me convient vraiment pour réaliser la grille, si ce n'est le TDrawGrid, mais il faudrait le "trafiquer" un peu, et utiliser un descendant de ce dernier en le bridant sur certaines fonctionnalités, ce n'est pas respecter le LSP de ce que j'ai appris grâce aux membres expérimentées du C++. En revanche, il est tout à fait possible de créer son propre composant VCL en la dérivant d'un composant de base TCustomControl ou autre chose.

Un autre point délicat, c'est la floppée d'événements déclenchées par les contrôles orientés données, et si on code les événements sur les différents contrôles, il faut faire gaffe à l'ordre dans lequel ils se déclenchent pour ne pas arriver à des comportements bizarres.

Un Framework, si on prend la traduction litérrale de l'anglais en français, c'est cadre de travail, et je trouve cette définition tout à fait adaptée. Mais il faut faire attention aux oeillères et se dire qu'on pourrait faire autrement que ce que le framework propose et donc être "créatif", tout en exploitant les briques de base du Framework. Sur ce point, Souviron devrait certainement exceller pour réaliser des composants graphiques, car en C, il n'y a aucun framework défni, c'est le développeur qui décide.
Avatar de SQLpro SQLpro - Rédacteur https://www.developpez.com
le 27/06/2009 à 10:04
Citation Envoyé par benwit  Voir le message
Pour résumer, pour moi, le principale avantage d'un ORM, c'est l'indépendance par rapport à la base de données

Encore une fois ceci est totalement faux ! Lisez les tests que j'ai effectué sur des requêtes simplissimes sur différents SGBDR !

A +
Avatar de clavier12AZQSWX clavier12AZQSWX - Membre confirmé https://www.developpez.com
le 27/06/2009 à 10:46
Envoyé par benwit Voir le message
Pour résumer, pour moi, le principale avantage d'un ORM, c'est l'indépendance par rapport à la base de données

Citation Envoyé par SQLpro  Voir le message
Encore une fois ceci est totalement faux ! Lisez les tests que j'ai effectué sur des requêtes simplissimes sur différents SGBDR !

A +

Faux suivant le sens de l'indépedance, de quelle indépendance on parle ?

Dans le cas de OpenObject, on est indépendant sur le fait qu'on a pas à créer les tables, les champs, les relations car c'est le framework qui le fait. Par contre, on est contraint que ce soit PostgreSQL , donc là on est plus indépendant de la base de données.
Avatar de chaplin chaplin - Membre expérimenté https://www.developpez.com
le 27/06/2009 à 12:53
Citation Envoyé par SQLpro  Voir le message
Encore une fois ceci est totalement faux ! Lisez les tests que j'ai effectué sur des requêtes simplissimes sur différents SGBDR !

A +

@SQLPro: n'y aurait-il pas une erreur au niveau du fil de discussion, a mon avis ce post est arrivé au mauvais endroit.
Avatar de benwit benwit - Rédacteur https://www.developpez.com
le 27/06/2009 à 21:30
Citation Envoyé par chaplin  Voir le message
@SQLPro: n'y aurait-il pas une erreur au niveau du fil de discussion, a mon avis ce post est arrivé au mauvais endroit.

En fait, c'est ce que j'ai cru également mais plus haut dans ce fil, j'ai réutilisé des arguments que j'ai posté dans le fil de discussion auquel tu dois faire allusion.

Il est manifeste que SQL Pro a un avis tranché sur la question et n'hésite pas à le faire savoir. Ce qui me désole, c'est le manque d'argumentation et sa méconnaissance des ORMs.

Citation Envoyé par SQLPro
Lisez les tests que j'ai effectué sur des requêtes simplissimes sur différents SGBDR !

OK, le standard SQL n'est peut être pas aussi standard qu'il le dit mais si SQLPro avait utilisé hibernate, il aurait vu que les requêtes sont fabriquées par le framework en fonction du dialecte et qu'elles ne sont pas les mêmes d'une base à une autre. Ce qui est d'autant nécessaire quand on utilise des fonctionnalités non standard (identifiant auto généré, pagination des résultats, ...)

Citation Envoyé par Michael REMY
de quelle indépendance on parle ?

Par indépendance, je parle :
  1. pour une grande majorité d'application de gestion (pas pour toutes les applications du monde non plus)
  2. de changer de SGBD sans avoir à faire de nouveaux développements (juste quelques modifications dans les fichiers de configuration).


Si on comprend et accepte ce que je veux dire par indépendance, je maintiens que l'indépendance au SGBD est un avantage de l'ORM Hibernate.
Si vous êtes d'accord, venez témoigner, sinon, argumentez.

Est-ce qu'avoir des requêtes dynamiques spécifiques à un SGBD n'est pas pour lui une indépendance ? Est-ce que l'indépendance est toujours requise, Est-ce que l'impact sur les performances n'est pas crucial sont d'autres débats.

Pour conclure, j'ai lu les références documentaires que SQLPro cite, son article, etc ... J'admets qu'il a de bons arguments et je demande qu'à être convaincu , surtout que depuis, j'ai mis un peu d'eau dans mon vin et l'indépendance comme j'ai pu le constater nécessite parfois (des applications un peu compliquées) quelques adaptations (+ que le simple changement de dialecte) sans parler du temps passé à appréhender l'outil.

Néanmoins, comme toutes les personnes passionnées par un domaine (ce que j'admire et comprends ), enflammées par l'injustice, les mensonges, les mauvais procès qu'on peut faire à une techno par manque de connaissance, il tombe lui aussi dans ce travers quand il s'agit de sortir de son domaine de compétence (ce qui est malheureux ).
Avatar de FCDB FCDB - Membre régulier https://www.developpez.com
le 20/08/2009 à 20:22
Ca a déjà était dit mais je le répète, un framework ce n'est pas seulement un ensemble de fonctions. J'ai bossé rapidement sur des projets que je ne connaissais pas et le fait de retrouver le même framework (Symfony) m'a permis de faire des modifs tout de suite sans soucis et sans doc technique.

De plus, ce n'est pas une boîte noire, si il y a une erreure que l'on ne comprend pas, il suffit de regarder dans les sources d'où elle vient. Enfin en général ce n'est pas nécessaire.

Au sujet des ORM, je ne comprend pas pourquoi certains ne veulent pas les utiliser. En plus de l'indépendance avec le sgbd, ça fait gagner du temps, beaucoup de temps. Là encore, ce n'est pas une boite noire, il ne faut pas être neuneu et dire, oh bas c plus lent qu'avec une requete sql écrite à la main. Vous pouvez regardez les requetes générées et si c'est nécessaire faire des modifications. Par exemple, dans certains cas, on a pas besoin d'hydrater les objets, c'est faisable avec tout bon ORM.

Pour résumer mon point de vue, les outils qui permettent de ne pas réinventer la roue sont plus que bon à prendre tant que ce ne sont pas des boites noires (éviter donc Micro*%£¨*).

Sur l'expérience que j'ai eu cette année, je peux dire que le temps d'apprentissage a largement était compensé par les gains de dév. Et il y aura encore des gains quand d'autres développeurs devront bosser sur mon travail.
Offres d'emploi IT
Chef projet big data - pse flotte H/F
Safran - Ile de France - Évry (91090)
Consultant sap finance/controlling H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Architecte technique des systèmes d'information H/F
Safran - Ile de France - Évry (91090)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique ALM