juin
2007
Un article de christopheJ
La question que je me pose est plus exactement : Pourquoi tant de sociétés utilisent des frameworks « maison »?
Dans ce billet, je ne traiterai pas des outils comme les scripts de Ruby on Rails ou encore AppFuse qui permettent de générer le squelette de l’application facilement et dont l’utilité, pour moi, ne fait aucun doute (tant qu’ils sont à jour et fonctionnent…). Dans ce billet, je veux parler des frameworks que l’on croise souvent dans une vie de prestataire et qui sont des surcouches ou wrappers de Struts, Hibernate, Spring, EJB ou autre frameworks classiques du marché, souvent disponibles en open source et gratuitement de surcroît. On trouve aussi l’autre version du framework maison qui n’est pas le wrapper, mais une sorte de clone boitant, juste la réinvention de la roue mais avec des bosses dessus….
Ne rigolez pas, vous avez certainement déjà vu un de ces frameworks. Certains ont même vu des wrappers de wrapper avec un framework de logging autour de Commons Logging (pour ceux qui ne connaissent pas, c’est un wrapper pour les frameworks de logging).
Que cela se soit fait au début de l’open source ne me choque pas. Auriez-vous fait reposer votre application directement sur quelque chose fait par des barbus sur leur temps libre? Vous aviez alors deux solutions. La première est de faire votre propre framework. La seconde est de faire un wrapper pour découpler votre application de ce code et vous donner la possibilité de changer ou refaire cette sous-couche en cas de problème.
Mais quelle est l’utilité maintenant que ces outils sont largement éprouvés?
Quand il s’agit d’une SSII, cela peut éventuellement se justifier. Le client qui achète une application développée sur le framework maison de la SSII se retrouve lié à cette SSII pour la maintenance et l’évolution de cette application. Je réprouve ce genre de pratique commerciale car elle permet de retenir le client, non pas par la qualité de la prestation ou la confiance, mais par la « contrainte ». Un peu comme une application qui enferme vos données dans un format propriétaire (non je ne donnerai pas de nom….) et vous obligent donc à continuer à l’utiliser…
Je pense qu’il est de l’intérêt du client de s’assurer qu’il aura accès aux sources de l’application et que cette application repose sur des standards du marché afin de garder toute sa liberté.
Dans le cadre d’une entreprise développant à son propre compte, j’ai plus de mal à comprendre l’intérêt. Généralement, l’argument est que le framework masque une partie de la complexité des développements Java, permettant au développeur de se concentrer sur la partie métier du code et non sur la machinerie.
Toutefois le développement et la maintenance de ces frameworks représentent un coût direct pour cette entreprise. De plus je vois un certain nombre de problèmes liés à ces frameworks :
- le risque d’avoir des bugs dans le framework
- dans le cas d’un wrapper, le masquage de l’API sous jacente peut faire que l’on se prive d’un certain nombre de fonctionnalités de cet outil
- pour le clone, on retrouve aussi le problème des fonctionnalités absentes
- pour un wrapper, il est nécessaire de faire évoluer ce framework pour profiter des évolutions de l’outil sous-jacent (il y a donc un coût supplémentaire et un retard à l’application)
- pour un clone, il faut le faire évoluer pour simuler les nouvelles fonctions intéressantes (là aussi, coût et retard sont présents, avec en plus des variations de comportement)
- la nécessité de former à ce framework les éventuels prestataires intervenant dans la société (un coût supplémentaire alors que les prestataires connaissent généralement l’outil standard qui a été encapsulé ou cloné par le framework)
- Enfin le dernier et non négligeable : se priver de la base de connaissance et d’entraide phénoménale que constitue le web et plus particulièrement les forums.
Donc d’après vous, quelle est l’utilité de ces frameworks maison ? Si vous voyez des arguments, n’hésitez pas à laisser un commentaire.
Je voudrais juste ajouter un appel aux sociétés : au lieu de payer vos développeurs pour réinventer la roue ou lui mettre des pneus plein de bosses, laissez les contribuer dans ces projets open-sources et reverser vos améliorations à la communauté. Ils gagneront en compétences sur ces frameworks et si toutes les sociétés le font, ces outils formidables seront encore meilleurs, ce n’est pas de l’argent perdu.
A ajouter à la liste des inconvenients :
– Le fait d’utiliser des frameworks bien pensés déteint sur votre application.
– présenter aujourd’hui un CV ou quasiment aucun framework est utilisé mais ou tout est ré inventé, est loin d’être un avantage.
– c’est certainement moins coûteux de se former pendant quelques jours, plutôt que de passer des mois à créer (et surtout maintenir des frameworks maisons). On se concentre sur ce que l’on connaît le mieux : le code métier.
– Le risque c’est les «coups de bourre » ou on fait évoluer le framework dans l’urgence sombrant dans le « quick and dirty » ou anti pattern « lava flow ». Au bout d’un certain temps le framework devient impossible à maintenir.
Je ne suis pas convaincu qu’il soit plus long de choisir et se former à un framework que de créer son propre framework. La deuxième solution demande des compétences déjà avancées.
Je ne connais pas trop l’offre du marché du coté DotNet, mais si tu prends par exemple Spring (qui est porté en DotNet), effectivement il faut du temps pour apprendre l’utilisation (les fonctionnalités sont nombreuses) et 90% te seront inutiles. Mais ce framework est tellement modulaire qu’il suffit d’apprendre le coeur puis la partie qui t’intéresse. Le temps d’apprentissage n’est alors pas si long comparé à l’apport de ce framework. Il te laisse en plus la possibilité de te brancher sur la plupart des autres solutions du marché.
C’est vrai qu’il doit exister presque une dizaine de frameworks de présentation en Java. L’évaluation de tous prendrait beaucoup de temps, mais il existe de nombreux comparatifs sur le web pour ces frameworks permettant de gagner du temps. De plus certains sont trop immatures et récents pour se permettre de les employer dans une vraie application.
La communauté DotNet étant plus jeune, elle dispose sans doute de moins de recul sur tout ces frameworks, même si elle gagne du temps grâce au portage des meilleurs outils de la communauté Java (NUnit, NHibernate, Spring….)
Moi j’utilise qu’un framework maison.
Pourquoi : les solutions actuelles sont de vrai usines à gaz qui certes répondent à mes besoins mais me demanderont un temps incroyable pour : me former au framework à utiliser, configurer/mettre en place, debugguer.
Et je parle même pas du temps d’étude en amont pour savoir quel framework utiliser.
Après ça dépend des cas, je pense que plus le projet est gros et complexe en architecture plus on doit se rapprocher des solutions NHibernate & co. Mais dans mon cas c’est un ensemble de petits et moyens applicatifs divers (client/server, web, winforms) qui tournent autour d’un framework maison qui au final expose une couche métier correspondant parfaitement aux divers besoins.
Je préfère passer du temps à analyser mes besoins qu’à étudier un framework qui me propose beaucoup de choses mais dont 90% me sont inutiles.