Certains développeurs ne jurent que par les frameworks, tandis que d’autres au contraire ont tendance à les fuir comme la peste et tout recoder eux-mêmes à chaque fois. Les frameworks ont en effet des avantages indéniables mais ils peuvent fortement alourdir les applications de manière totalement inutile. Aussi on va voir s’il faut systématiquement les utiliser… ou pas. Dans la suite on parle bien des frameworks sur étagère et pas des « frameworks maison » qui souvent font peur à voir car développés à l’arrache…
Les gros frameworks tels que Spring ont clairement de nombreux avantages. Ils fournissent notamment tout un ensemble de services clefs en main, comme la gestion des transactions en base de données. Par ailleurs ils ont l’avantage d’avoir du code largement testé par la communauté, et de disposer d’un bon support… encore faut-il que l’équipe soit à même d’intégrer les correctifs périodiques du framework dans les développements internes. Au passage, les correctifs les plus importants à intégrer sont ceux concernant la sécurité, certaines applications ayant pu être piratées par le passé en raison de failles de sécurité dans les librairies qu’elles utilisaient. C’est une des raisons pour lesquelles il est absolument capital d’avoir une bonne couverture de tests automatisés avant de les utiliser, de façon à avoir un bon niveau de confiance lorsqu’on doit le mettre à jour.
Tout ça pour dire que si vous utilisez un framework, développez dans les règles de l’art pour éviter ensuite les mauvaises surprises qui peuvent intervenir. Ce n’est pas parce qu’un code est largement testé par la communauté qu’il est immunisé contre les régressions. Certains vont même jusqu’à écrire des suites de tests automatisés sur les fonctionnalités du framework afin de détecter les éventuelles régressions ! Ce n’est pas toujours possible mais dans le cas d’une librairie fournie par un éditeur externe ça peut être parfaitement souhaitable. À titre personnel j’ai déjà vu des tests unitaires planter car l’éditeur externe n’avait pas géré le cas null dans la méthode equals() d’un objet de sa librairie.
Le plus gros problème des frameworks et autres librairies est qu’ils peuvent fortement alourdir l’application et la ralentir. Il m’est ainsi arrivé de télécharger des applets Java de 100 Mo car l’éditeur utilisait tout un ensemble de librairies Apache, pour lesquelles il aurait pu être souhaitable de savoir ce qui était vraiment indispensable avant de tout packager. Une autre illustration est le système d’exploitation W—–s qui n’a cessé de s’alourdir de manière délirante et pas nécessairement justifiée. Windows 95 pesait ainsi une centaine de méga-octets une fois installé, alors qu’un Windows moderne pèse déjà 20 Go sans aucune application dessus, soit plus qu’une distribution Linux avec de nombreuses applications ! Alors certes il y a de nombreux ajouts dans les Windows modernes, mais de là à justifier un tel embonpoint… Bref utiliser de nombreux frameworks et librairies juste pour une ou deux fonctionnalités peut fortement dégrader l’expérience utilisateur. C’est ainsi que vous pouvez transformer la Ferrari qu’est le PC de votre utilisateur en véritable 2 CV, d’ailleurs Windows y arrive très bien. Installez un Linux sur la même machine qu’un Windows pour vous en convaincre…
Mais le principal problème des frameworks est qu’ils induisent souvent une perte de connaissance des développeurs qui les utilisent. Ainsi de nombreux développeurs qui utilisent Spring ne se poseront pas la question de savoir comment en interne le framework gère les transactions et les connexions à la base. Ils se contenteront d’utiliser des recettes toutes faites sans comprendre ce qu’il y a derrière. On en arrive ainsi à une baisse de niveau des développeurs qui devient fortement préjudiciable, en particulier lorsque survient un bug. Car cette baisse de maîtrise se répercute ensuite sur d’autres éléments qui n’ont rien à voir avec le framework, tels que la gestion du multi-thread. Et pour info un serveur JEE par exemple est fortement multithreadé, aussi il faut faire attention avant de mettre n’importe quoi dans une session HTTP sous peine de plantage dans certains cas…
Clairement les frameworks font gagner du temps et bénéficier d’un code de qualité, du moins quand c’est un framework largement utilisé dans la communauté. Cela dit ils ne dispensent en aucun cas de connaître ce qu’il y a derrière voire de savoir le réimplémenter en bonne partie. L’idée est double :
Bref comme pour tout le reste les frameworks sont comme le bon vin, on peut les utiliser quand ils se justifient mais certainement pas en abuser.
En plus de leurs avantages intrinsèques, les frameworks ont un autre avantage indirect dans le sens qu’ils permettent d’identifier les bons développeurs. Ces derniers les utiliseront à bon escient, quitte à recoder certaines fonctionnalités quand importer des centaines de Mo de librairies pour une malheureuse feature simple à implémenter ne se justifie pas. Les autres auront au contraire tendance à faire un usage démesuré de tous ces frameworks et librairies sans se poser de question, ou alors recoderont la terre entière dans un « framework interne », ce qui est rarement une bonne idée…
Besoin de tester ton niveau en développement informatique ?
Cet article vous a plu ? Vous aimerez sûrement aussi :
Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.
Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
Changer d’entreprise, c’est excitant. Nouveau challenge, nouveaux collègues, nouveau café. Mais, bien souvent, on oublie…
Ça n’étonnera personne si nous affirmons que le monde du développement logiciel est en constante…
En Allemagne, le travail en tandem à temps partiel, aussi appelé « jobsharing » est…
On se retrouve comme d'habitude pour le début du classement qcm saison automne ! Mais…
La saison printemps des tests techniques WeLoveDevs s'est terminée le 31 mai, et c'est Axel…
View Comments
Approche intermédiaire : pas de framework mais quelques librairies bien placées (routeur, orm, gestionnaire de session... bref au besoin et au cas par cas), et bien integre sont souvent bien plus préférable sur le long terme.