Cadre logiciel

Les concepteurs de frameworks logiciels visent à faciliter les développements de logiciels en permettant aux concepteurs et aux programmeurs de consacrer leur temps à répondre aux exigences du logiciel plutôt que de s’occuper des détails de bas niveau plus standard pour fournir un système fonctionnel, réduisant ainsi le temps de développement global. Par exemple, une équipe utilisant un framework web pour développer un site web bancaire peut se concentrer sur l’écriture du code particulier à la banque plutôt que sur la mécanique du traitement des requêtes et de la gestion des états.

Les frameworks ajoutent souvent à la taille des programmes, un phénomène appelé « gonflement du code ». En raison des besoins des applications axées sur la demande des clients, des frameworks à la fois concurrents et complémentaires se retrouvent parfois dans un produit. De plus, en raison de la complexité de leurs API, la réduction escomptée du temps de développement global peut ne pas être atteinte, car il faut passer du temps supplémentaire à apprendre à utiliser le framework ; cette critique est clairement valable lorsqu’un framework spécial ou nouveau est rencontré pour la première fois par le personnel de développement. Si un tel cadre n’est pas utilisé dans des tâches professionnelles ultérieures, le temps investi dans l’apprentissage du cadre peut coûter plus cher qu’un code écrit à des fins particulières et familier au personnel du projet ; de nombreux programmeurs conservent des copies de boilerplate utiles pour les besoins courants.

Cependant, une fois qu’un cadre est appris, les projets futurs peuvent être plus rapides et plus faciles à réaliser ; le concept d’un cadre est de faire un ensemble de solutions à taille unique, et avec la familiarité, la production de code devrait logiquement augmenter. Aucune affirmation de ce type n’est faite quant à la taille du code finalement fourni avec le produit de sortie, ni quant à son efficacité et sa concision relatives. L’utilisation de n’importe quelle solution de bibliothèque attire nécessairement des extras et des actifs étrangers inutilisés, à moins que le logiciel ne soit un compilateur-lien d’objet réalisant un module exécutable serré (petit, entièrement contrôlé et spécifié).

La question continue, mais une décennie et plus d’expérience de l’industrie a montré que les cadres les plus efficaces s’avèrent être ceux qui évoluent à partir de la refactorisation du code commun de l’entreprise, au lieu d’utiliser un cadre générique « taille unique » développé par des tiers à des fins générales. Un exemple de cela serait la façon dont l’interface utilisateur dans un paquet d’applications tel qu’une suite bureautique se développe pour avoir une apparence, une sensation et des attributs et méthodes de partage de données communs, alors que les applications groupées autrefois disparates, s’unifient en une suite qui est plus serrée et plus petite ; la suite plus récente/évoluée peut être un produit qui partage des bibliothèques utilitaires et des interfaces utilisateur intégrales.

Cette tendance dans la controverse soulève une question importante sur les frameworks. La création d’un framework élégant, par rapport à un framework qui résout simplement un problème, reste plutôt un artisanat qu’une science. « L’élégance logicielle implique la clarté, la concision et peu de gaspillage (fonctionnalité supplémentaire ou superflue, dont une grande partie est définie par l’utilisateur). Pour les cadres qui génèrent du code, par exemple, l' »élégance » implique la création d’un code propre et compréhensible pour un programmeur raisonnablement compétent (et qui est donc facilement modifiable), par opposition à un cadre qui ne fait que générer un code correct. Le problème de l’élégance explique pourquoi relativement peu de cadres logiciels ont résisté à l’épreuve du temps : les meilleurs cadres ont été capables d’évoluer gracieusement au fur et à mesure que la technologie sous-jacente sur laquelle ils étaient construits progressait. Même là, après avoir évolué, de nombreux paquets de ce type conserveront des capacités héritées gonflant le logiciel final, car des méthodes autrement remplacées ont été conservées en parallèle avec les méthodes plus récentes.