juillet
2007
Un article de joseph_p
Comme diraient nos amis anglophones : « Early optimisation is the root of all evil ».
Autrement dit, à vouloir optimiser trop tôt, on se met soi même des bâtons dans les roues pour la suite…
C’est vrai à plusieurs niveaux :
– à bas niveau, en volant « optimiser son code », on ne connaît souvent pas assez son environnement (compilateur, modalités d’exécutions, passage des expressions aux différents processeurs) pour faire ça de façon pertinente,
– à plus haut niveau, en voulant faire une rolls là où on n’a que les moyens d’une… euh… petite voiture !
Pourquoi dis je ça ?
Parce que j’ai récemment commencé un petit projet perso. Rien de bien ambitieux (enfin, si, un peu, mais bon…). Toujours est il que je voulais « bien faire », aussi suis je parti pour… une couche d’accès aux données (Hibernate), de l’injection pour ma couche métier (Spring) et un framework puissant pour la partie présentation (Wicket).
Conclusion ? Pour utiliser une donnée en base dans une page web j’ai plein de choses à faire. Beaucoup trop en fait. A un tel point que j’avance lentement. Oh oui, clairement, le découpage en couches est nickel. Si un jour je veux faire du refactoring ou utiliser une autre bdd je pourrai. Mais à quel prix ?
D’un autre côté, un ami s’est lancé dans un projet similaire récemment. Lui ne s’est pas posé de question sur l’architecture. Il s’est fait sa couche perso d’accès aux données (wrappeurs sql basiques), sa couche métier est à la « vas y que je te pousse » et pour la présentation, ben il a pris les fonctionnalités de base de ce bon vieux php. Conclusion ? Il avance vite, très vite.
Les différentes situations sont bien sûr plus compliquées, mais je me demande vraiment si mon optimisation précoce de mon architecture n’a pas été un réel tort. Vu la faible ampleur de mon projet, utiliser des choses simples aurait sans doute été bienvenu. Ou, du moins, pondérer bien plus le rapport avantages/coût temporel de chacun des frameworks utilisés.
D’ailleurs, c’est un peu ce que je fais actuellement. De mon architecture, j’aime beaucoup Wicket. Hibernate aussi devrait me permettre d’aller plus vite in fine. Spring par contre me dérange bien plus. Je regarde un peu du côté de Guice actuellement, mais je me demande vraiment si le plus simple n’est pas tout simplement de zapper la couche d’IoC. Le gain de temps à la programmation sera clair et vraiment apprécié. Et la perte sans doute pas si grande : il n’y a que très peu de chance qu’un jour je refactorise mon code. Et combien même, Eclipse permet désormais très bien d’extraire des interfaces à partir d’une classe, alors tant que mon archi reste bien découpée, pourquoi m’embêter ?
Qu’en dites vous ?
++
ZedroS/Joseph
Peux tu préciser où tu gagnes du temps avec Spring stp? Ca m’intéresse vivement
Pour les regards sur Guice, il me semble avoir lu que ce dernier a un temps de redémarrage plus court que Spring. De plus, son aspect « tout java » est vraiment plaisant. Est ce aussi le cas de Spring lorsqu’on utilie des annotations ?
je pense que tu utilises pas forcement Spring comme il faut. de maniere générale, ca me fait gagner beaucoup de temps, par contre je ne cede pas a la mode de mettre des interface partout pour l’injection (en clair j’injecte l’implementation et ne fait des interfaces que si ca s’impose du coté modélisation, ou si je suis SUR que un jour j’en aurai besoin). Je bosse plus vite avec spring que sans. maintenant, je n’injecte pas tout, je ne me retrouve pas avec autant d’interfaces que d’objets en fin de projet etc…
enfin, si tu veux utiliser guice, regarde avant les preversion de spring qui arrivent, ou tu pourras faire de l’injection via annotations.