Pour ou contre les frameworks ?

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 avantages des frameworks

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.

Les problèmes des frameworks

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…

Alors, framework ou pas framework ?

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 :

• Premièrement en cas de bug du framework vous pourrez le remonter au développeur, et ensuite vous pourrez aussi appliquer des patches si besoin même si c’est plutôt déconseillé car ensuite il faut en gérer la maintenance…
• Mais ensuite il n’y a rien de plus dommageable que d’importer tout un framework pour utiliser une méthode ou une classe de quelques lignes qui est indépendante du reste du framework, et ça on le voit trop souvent. Ce genre de cas fait que des centaines de Mo de code inutile sont intégrées à l’application, ce qui l’alourdit tout en posant de gros problèmes de sécurité car un code non utilisé peut pour autant être réactivé par un attaquant…

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 bref…

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 ?

Je teste mon niveau en développement maintenant !