Discussion :

[kisitomomotene]

Salut à tous

Je suis confronté à un problème. Pour développer mon application, je dois utiliser des design patern, et des mécanisme qui se trouvent déjà implémentés dans le framework Jboss ESB. Je me demande s'il me faut utiliser ce framework ou bien en développer un moi même, car si j'utilise ce framework, le temps d'apprentissage et de maitrise du framework risque de dépasser le temps que je pourrais mettre pour développer à zéro un framework, qui aura certes nettement beaucoup moins de fonctionnalités et de caractéristiques que Jboss ESB, mais aura uniquement des fonctionnalités adaptées aux besoins de mon application. En développant à zéro un framework légé et bien adapté aux besoins, j'aurais plus de maîtrise sur mon code source, mais je serais en train de réinventer la roue, et en plus ce framework serra difficilement réutilisable.

[kain_tn]

Si le temps que tu mets à maîtriser un framework existant est supérieur à celui que tu peux mettre à développer ton propre framework, dis-toi qu'une fois développé, ton framework devra être testé, maintenu et que les bugs éventuels devront être trouvés puis corrigés... par toi!
De plus, développer ton propre framework en partant de zéro n'est pas forcément évident, surtout si tu dois faire face à des problematiques de charges, etc...

Maintenant, cela dépend aussi de la taille de ton application. Pour une application de petite taille, tu peut te permettre de développer ton propre framework (à mon avis).
Pour une application plus conséquente, à moins de travailler à plusieurs et/ou d'avoir de l'expérience il est plus sûr (mais pas forcément plus évident) de développer sur un framework déjà existant...

Après, ça reste mon avis personnel hein?

[Sergejack]

Tu seras peut-être amené à réutiliser le framework existant s'il te semble courrament utile.
Le problème principale avec un framework existant est que tu n'as pas réellement la possibilité d'y apporter une correction en cas de soucis, tu deviens dépendant de ses développeurs.

Alors les deux questions à se poser sont : "Est-ce un framework utile sur le long terme ?" et "Est-ce que j'ai affaire à un produit suffisement sûr ?".

Si à l'une de ses deux questions la réponse est non (surtout la seconde), fais ta propre roue

[Mac LAK]

Vaste question, ça...

Si par exemple tu veux utiliser un framework pour "standardiser" les tailles des données entre 2 ou 3 plate-formes et utiliser une poignée de fonctions "portables", c'est peut-être un peu bourrin d'ajouter 20 Mo de sources à ta gestion de configuration pour ça... Alors que 5 ko de code bourré de #ifdef feraient tout aussi bien l'affaire !

Si par contre le framework en question est la base complète de ton système, peut-être vaut-il mieux d'une part bien le choisir (cf. ce sujet par exemple), et d'autre part réfléchir à son impact sur le code final.

Le framework va-t'il être présent à tous les niveaux du projet ? Ou limité à quelques briques fondamentales, sur lesquelles s'appuiera le reste du projet ? Est-il utilisé uniquement dans du code généré ? Quel pourcentage du framework comptes-tu utiliser, approximativement ?

Autres points importants : quelle est la durée de vie de ton projet ? Sa probabilité de réutilisabilité ou d'évolution ? Le framework peut-il servir dans d'autres projets au sein de ta société ?

Sans réponses à ces questions, il sera difficile de te dire s'il vaut mieux réinventer la roue ou passer du temps à apprendre le framework en question...

[lepinekong]

Ca dépend du contexte : si c'est pour toi personnellement ou si c'est pour ton entreprise.

Normalement pour que ton entreprise n'ait pas des ennuis le jour où tu pars, eh bien elle ne te laisserait même pas utiliser autre chose qu'un framework existant