Discussion :

[benwit]

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 ...

[rakakabe]

Pour ma part, j'aime bien le passage :

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

Vade Retro RAD et companie.

[Braillane]

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!

[benwit]

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 ...

[zeavan]

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.

[souviron34]

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

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

Plus précisément :

• 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...

• 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..

• 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.

• 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)

[GrandFather]

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).

[souviron34]

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

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 ?

[GrandFather]

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.

[hegros]

[*]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

[benwit]

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 ...

[framework]

Pour moi un Framework efficace doit être simple à comprendre et complet en offrant :

- un cadre de développement
- de nombreux outils d'aide au développement
- un bon ORM

Je peux ainsi citer quelques bons Frameworks tendant à respecter ces critères : Code Igniter & Kohana, Cake PHP, Yii

Au contraire, d'autres sont de véritables usines à gaz et sont pourtant les plus connus : Symfony, Zend Framework

Pour moi le constat est assez simple. Les sociétés comme Zend ou Sensio Labs (Symfony) on tout intérêt à nous vendre des formations et des certifications, et pour cela à ne pas rendre les choses trop simples... En effet, il faut bien qu'elles gagnent un peu d'argent !

Les projets Kohana, Cake ou Yii sont communautaires et privilégient la performance et l'efficacité. Code Igniter est un framework d'une société privé mais qui réalise ses développements avec. C'est un gage d'efficacité.

[benwit]

on a tout intérêt à nous vendre des formations et des certifications, et pour cela à ne pas rendre les choses trop simples... En effet, il faut bien qu'elles gagnent un peu d'argent !

+1

[eclesia]

Personnellement je ne vois pas d'objections a l'usage de certaines "boites noires".

Je peux en nommer quelque unes comme :
Java Advanced Imaging, Java2D, georeferecing, JSR-275 (Unit).
Se sont des API qu'il est impossible a comprendre sur une moyenne durée et qui necessite des connaissances tres poussé particulieres pour certaines (physique, imagerie avancé, mathematique). Il est aussi impossible a l'echelle d'un developpeur voir d'une equipe de developper une solution de remplacement.

En ce qui concerne les autres (celles qui n'entre pas dans le domaine scientifique), je pense qu'il faut avoir aquis de l'experience pour etre capable de juger de la viabilité d'une api. Il faut rester lucide et savoir les différencier :

- Celles faites par des bons developpeurs. (On peut dire qu'elles finissent dans le JDK en majorité.)
- Celles par des mauvais developpeurs mais qui ont su se vendre.
- Celles a vocations concurrentiel (comme SWT)
- Et les "proof of concept" (comme JaxB,usage des annotations pour le mapping xml)

Il ne faut pas se leurrer, se sont des developpeurs derriere les apis pas des dieux, et il y a surement des developpeurs plus mauvais que vous-meme qui ont deja du contribuer d'une facon ou d'une autre a votre api préférée.

On peut se rendre compte de ce que vaut un projet en voyant comment il est structuré.
- S'il y a une société derriere, c'est une sécurité et un minimum de qualité
- S'il y a une communauté, ca veut dire que ca marche plutot bien mais pas necessairement de qualité
- Si ca s'appuis sur des normes c'est généralement un bon signe mais attention ca peut etre un simple argument commercial
- Si le projet est bien structuré, des modules maven en cathedrale ou des dependences dans tous les sens
- L'usage de certains patterns, comme les frabriques ou l'utilisation d'interface, des services META-INF .
- Et bien sur le code lui meme, s'il y a des classes a portée réduite, l'usage des "final", des static ou des throw Excpetion a la barbare

Bref il faut etre critique et ne pas s'arreter aux tutoriaux et aux "on m'a dit du bien de ... donc ...".

[clavier12AZQSWX]

Un RAD est un outil magique si on le met entre les mains d'une personne consciente et expérimenté qui a "déjà fait ses classes".

Un rad dans les mains d'un féniant ou d'une personne désorganisée produit un résultat catastrophique !

[Frostizz]

Un RAD est un outil magique si on le met entre les mains d'une personne consciente et expérimenté qui a "déjà fait ses classes".

Un rad dans les mains d'un féniant ou d'une personne désorganisée produit un résultat catastrophique !

Très bient dit !!!!

[clavier12AZQSWX]

merci :-)

ptite précision, quand je dis "faire ses classes", je parle au sens militaire, c-a-d au sens 'qui a éjà enduré un gros projet , codage manuel avec erreur organisation", pas Class au sens programmation...

[_skip]

En tant que développeur, à chaque fois que j'ai un nouveau projet ou un nouveau module à concevoir, la première chose que je fais c'est de dégager une liste des difficultés potentielles. Tout de suite après je regarde quels frameworks ou technos existantes je peux utiliser.

Après une assez brève sélection basée sur la pertinence de l'approche du framework et sur sa communauté (car je trouve ça important que les ressources soient suffisantes), j'essaie de passer du temps (si possible pas trop) pour faire un petit quelque chose avec. Ceci dans le but de me rendre compte de la façon dont ils résolvent les problèmes que je pressens. Finalement, si ma satisfaction et ma confiance sont suffisants, j'en adopte un.

Pour moi, un framework ou une API de haut niveau n'est pas forcément synonyme de perte de maîtrise dans la mesure ou la documentation est suffisante pour comprendre ce qu'il se passe sous le capot. Après c'est comme tout, on peut se planter mais il faut minimiser les risques en recréant si possible d'entrée de jeu les situations critiques afin de se conforter dans son choix.


Pour ce qui est du RAD qui fait tout pour vous... J'ai eu une très mauvaise expérience chez mon ancien employeur avec une suite d'outils appelée W!nD3v.

[benwit]

J'ai eu une très mauvaise expérience chez mon ancien employeur avec une suite d'outils appelée W!nD3v.

Tu peux nous en dire plus ?
On ne trouve pas de critique argumentée dans leur belle plaquette commerciale

[_skip]

Serait-ce par hasard parce qu'ils utilisent des moyens totalement abusifs pour faire taire leurs critiques?