Du choix d’un framework
5 juin 2007
Au cours d’une costaude conversation avec un collègue, il fut question d’un cadre d’application développé par Nurun. Or, je n’ai jamais encore utilisé ces outils, je n’y ai jamais seulement jeté un œil (ça viendra je suppose, c’est mon boulot après tout!). L’ennui c’est que je reviens de JavaOne, et que j’ai la tête pleine de toutes ces technologies attrayantes. En plus, je me gave quotidiennement de blogs et de fils RSS traitant des mêmes sujets. C’est alors que je me suis rendu compte, après une courte et non-inintéressante réflexion, que choisir une technologie pour bâtir une application web, est devenu l’apanage d’une appréciation quasi-subjective.
Devant la prolifération des cadres d’application, et là je m’en tiens uniquement à l’écosystème Java, il n’y a plus beaucoup de problèmes non-résolu qui tiennent. Une part de ce qui sort sur le marché n’est que de l’innovation, ou pire, de simples variations sur un même thème. Prenons par exemple Hibernate et iBatis: certains puristes vont me châtier de dire que ces 2 créatures se ressemblent, mais d’une certaine perspective ils comblent le même besoin. Même constat en ce qui concerne Struts et Spring MVC, outre les concepts de plomberie interne, qu’apporte-t-il tant l’un que l’autre ne peut combler?
Un architecte de système peut aujourd’hui, prendre une page blanche, et assembler à sa guise, une courtepointe technologique qui va couvrir la plupart de ses besoins. Il va le faire de la même façon que l’on se construit une table d’hôte dans un resto. Il existe même des outils pour aider ce pauvre architecte, angoissant devant tant de choix.
Les besoins (en technologie), d’un certain point de vue, vont typiquement se présenter de cette façon:
- Interface riche (Ajax?) et interactive, ou pas
- Présentation MVC et séparations des responsabilités
- Couche d’affaire transactionnelle
- intégration et communication avec d’autres systèmes (services)
- Persistance d’un modèle objet dans une base de données
J’aurais pu dresser une liste exhaustive des possibilités, existant sur le marché commercial et dans le logiciel libre, répondant à chacun de ces besoins. En fait, les choix se font maintenant en fonction de l’expertise de l’équipe en place, de la politique interne, du respect des applications déjà développées, ou même (et ça arrive plus souvent qu’on le pense) des excentricités des technologues régnant en maîtres sur leurs équipes TI.
Donc, pour en revenir à mon hypothèse de base, la valeur d’un projet WebWork/Spring/iBatis est-elle moindre qu’un autre utilisant JSF/EJB3/JPA? Rien n’est moins sûr. Je crois que nous sommes présentement à une époque dorée, d’abondance d’innovation. On se permet même d’ambitionner sur la complexité, et de plaider pour une simplicité renouvelée. On en est même rendu à implémenter des frameworks de framework, qui (j’imagine) ont comme esprit d’enfouir la volatilité des cadres d’aujourd’hui, et de couler plusieurs outils à usage unique dans une pratique cohérente et intégrée.
Je persiste donc: les choix technologiques d’aujourd’hui pour développer une application web ne sont plus des chemins uniques, mais plutôt des appréciations subjectives s’arrimant à tellement de facteurs, que l’ADN de ces projets sera de plus en plus spécifique, voir unique. C’est dans ce contexte que les boites de service-conseils comme Nurun peuvent arriver avec de la valeur ajoutée: développer une approche agile et modulaire à travers une coquille technologique, la faire sienne, et surtout, s’en tenir à cette ligne de conduite le plus longtemps possible. Se faisant, ils minimiseront la constante et éreintante édification de l’expertise des ressources, et maximiseront leur capacité de livraison et leur niveau de qualité.
La solution réside-t-elle dans un « macro cadre d’application » enrobant les frameworks le composant? Ou dans une pile technologique judicieusement choisie et récurrente d’un projet à l’autre?
Je m’interroge.
JS.
5 juin 2007 à 15:15
Ben sais-tu quoi? Moi aussi je m’interroge car je ne m’y connais pas vraiment pour être honnête.
:)
Fais-toi conseiller mon jeune
5 juin 2007 à 20:04
Quelle belle réflexion
La discussion aura au moins déclenché cela 
Par contre, ton choix de la fin oublie une variable… Même en choisissant une stack de frameworks du marché et en la gardant, il te faudra de toute manière développer un ensemble de classes pour arrimer cette stack ensemble et aussi pour l’adapter à tes propres besoin… Et hop, tu te retrouves de toute manière avec un méta-framework qui fait l’arrimage…
T’es beau JS dans ton gilet SOFI…
7 juin 2007 à 0:50
Il était une fois moi qui se posais les mêmes questions que toi. Un ami m’a fait parvenir un vidéo (le fameux “10 minute blog” de Ruby on Rails). J’ai décidé d’essayer ça puis depuis ce temps là je fais du code au lieu d’essayer de décoder des acronymes.
Je ne dis pas ça pour t’influencer où même pour suggérer que Rails est la solution appropriée pour le type de projet que tu fais chez Nurun, mais je voulais simplement partager ça.
Si ça t’intéresse, j’ai “Agile Web Development with Rails, 1e édition” qui traîne sur une tablette (j’ai la 2e édition).
P.S.: Un de mes amis travaillait dans un racoin chez CGI et il trouvait que Struts c’était trop d’overhead et ça le faisait *&#?$. Il voulait un MVC assez simple et en avait marre de faire des tonnes de XML avant que quoi que ce soit fonctionne. Il a fait son propre framework et il l’a appelé Foxtrot. Si tu ne trouves pas ça comique, dis Foxtrot à voix haute.
12 juin 2007 à 16:54
L’essentiel, c’est d’être aimé.
Mais au-delà de l’essentiel, je crois qu’au bout du compte, il faut que ce soit le plus simple possible. Parce qu’elle est payante, après quelque temps, la simplicité. Et puis, qui a pour adage “pourquoi faire simple si on peut faire compliqué?” à part les magouilleurs à la CGI?
J’aime Foxtrot (merci JP!) et l’harmonie, diantre! Alors Spring est apprécié dans mon coin. Hibernate l’est moins, bordel. JSF est étonnant, ainsi que les frameworks qui en découlent… (ICEFaces?)
Continue à te questionner, car tous savent bien que l’étonnement devant le banal est la première étape à la philosophie et donc à l’évolution…
12 juin 2007 à 17:11
Putain que je t’aime Kex. Te lire fait parti de mes chatoiements sensoriels les plus envoûtants.
Ceci dit, j’ai bien ri la désopilante blague Foxtrot moi aussi, mais je l’ai comprise tardivement: À 18h05 environ.
Mais pour répondre à JP, et parce que j’adore explorer et apprendre, je vais installer Ruby, Rails-on-Ruby, Ruby-on-Rails, Grails, Groovy-on-Ruby, JRuby et tout ce qui termine par «ails» et «by». Ensuite, j’ai bien l’intention d’opiniâtrer sur le sujet.
D’ici là je continue d’aimer tout ce qui ce termine par «faces»: my, ice, et le percutant, hitmeinthe.
JS.
14 juin 2007 à 12:14
JS:
D’ici là, si ton train de banlieue le permet, tu pourrais me payer une couple de pintes de blanche avec un quartier de lime (au soleil, sur une terrasse) et en échange, je te refilerai ma vieille copie première édition de “Agile Programming with Rails”, et que je te donnerai un métaphorique coup de pied dans le cul metal afin que tu démarre dans la bonne direction et que tu opiniâtres de façon subjectivement favorable sur le sujet.
14 juin 2007 à 12:21
Va pour la pinte, le soleil et les camisoles translucides sur les terrasses. Mais je propose 15% de conversations techniques, le reste de la tarte pourra être consacré à des souvenirs, de bonnes blagues, des « ratings » sur le troupeau féminin environnant, et toute cette sorte de choses.
JS.
14 juin 2007 à 21:06
Va pour 15%