J'ai tendance à travailler surtout avec des applications Web et même si j'essaie d'être général, ma réponse pourrait ne pas s'appliquer à votre domaine de programmation.
Je vais aussi utiliser "framework" synonymical avec "library".
Avant de mettre en place un cadre, il faut considérer quelques points, voici quelques exemples généraux.
#1. Le cadre permettra-t-il d'économiser du temps et des efforts?
La réponse à cette question est presque toujours oui . Les cadres ont tendance à être construits pour résoudre des problèmes spécifiques , et les résolvent très bien. Par exemple, des frameworks tels qu'EntityFramework peuvent vous éviter totalement d'écrire du code SQL. Ce qui peut être fantastique si votre équipe de programmation ne parle pas couramment SQL.
Les cadres sont conçus pour: a) ajouter une interface conviviale pour les composants complexes par ailleurs ou b) ajouter une abstraction à des composants déjà bien connus (ou établis).
Ces derniers (ou même les premiers dans certains cas) peuvent réellement entraver le développement. Ceci s’applique particulièrement lorsque vous ou votre équipe de programmation allez implémenter un nouveau cadre dans lequel ils n’ont jamais travaillé auparavant.
Cela pourrait potentiellement ralentir votre processus de développement, ce qui pourrait être coûteux.
# 2 L'ampleur de votre application
On dit que "tout ce qui vaut la peine d'être fait vaut la peine d'en faire trop" , mais ce n'est généralement pas le cas. Il n’ya probablement aucune bonne raison de mettre en place un cadre super-dimensionné si le but de votre application est d’imprimer "Potato" .
Lorsque vous développez une application (Web, de bureau, mobile ou tout autre type d’application imaginable), si vous estimez que la taille de votre infrastructure "échappe" à son implémentation (peut-être future), alors cela pourrait être un gros problème. avertissement que votre framework risque de gonfler votre application. Une bonne anecdote serait que si vous avez inclus jQuery, il vous suffit d'ajouter une classe "chargée" à votre balise body lorsque le document est prêt. Faire cela avec seulement du JavaScript natif peut être un peu plus difficile , mais cela ne gêne pas votre application.
D'un autre côté, si un framework fait beaucoup de sale boulot à l'intérieur (c'est-à-dire des frameworks de base de données), il peut être viable de le mettre en œuvre, même si vous n'utilisez que partiellement ce framework. Une bonne anecdote serait de ne pas essayer de créer votre propre pilote ADO.NET ou MongoDB, simplement parce que vous n’avez pas besoin d’utiliser toute la bibliothèque.
Parfois, les frameworks sont open-source (et avec des licences «faites ce que vous voulez»). Cela ouvre une nouvelle possibilité dans laquelle une équipe de programmation ne pourrait opter que pour des parties d'un cadre.
Cela nous ramène finalement aux questions 1 et 3.
# 3 Impact.
Parfois, l'implémentation d'un framework peut avoir un impact direct sur l'utilisateur final. Cela est particulièrement vrai pour les applications Web, car la présence de grands environnements côté client peut avoir une incidence négative sur l'expérience de l'utilisateur final. Les utilisateurs dont les ordinateurs sont plus lents risquent de rencontrer des problèmes de rendu, de performances avec JavaScript ou similaires, causés par des ordinateurs sous-pair. Les utilisateurs avec des connexions lentes risquent de connaître des temps de chargement lents (au moins initiaux).
Même dans d'autres types d'applications, les dépendances de l'application peuvent avoir un impact négatif sur les utilisateurs finaux. Les frameworks, au moins, occupent toujours un peu d'espace disque. Si vous développez une application mobile (ou même une application de bureau), vous devrez peut-être en tenir compte.
Les infrastructures côté serveur (encore plus spécifiques au Web) n'affecteront probablement pas vos utilisateurs finaux, mais cela affectera votre infrastructure . Certains frameworks ont eux-mêmes des dépendances qui peuvent vous obliger à redémarrer votre serveur Web, que ce soit uniquement le service ou le serveur.
Certains cadres peuvent également être très gourmands en ressources.
Cela renvoie bien entendu aux points 1 et 2.
Il ne s'agit que d'un grand "cercle de considérations", et il n'existe aucune méthode scientifique réelle pour décider si vous devez ou non mettre en œuvre un cadre.
Corbin March l'a très bien résumé:
Les groupes avec lesquels j'ai travaillé font tous la même chose: deviner les coûts et les avantages, choisir la voie la plus productive et espérer qu'ils ont raison. Ce n'est pas très scientifique - une part d'intuition, une expérience de trois parties, une part de sensibilité au marketing, une part de ruse et une part d'opinion sur cinq.
Il est également important de ne pas être élitiste . Les cadres sont des outils destinés à être utilisés. Je connais des gens des deux extrêmes; D'un côté, vous avez le gars qui rend la vie très difficile pour vous, de l'autre côté, vous avez le gars qui construit des applications lentes et gonflées.
Tous les cadres ont des cas d'utilisation, il s'agit simplement de les mettre en œuvre pour les bonnes fins.