Quand NE PAS utiliser un framework
Aujourd'hui, on peut trouver un cadre pour à peu près n'importe quelle langue, pour convenir à n'importe quel projet. La plupart des frameworks modernes sont assez robustes (en général), avec des heures de test, du code évalué par les pairs et une grande extensibilité.
Cependant, je pense qu'il y a un inconvénient à N'IMPORTE QUEL cadre dans la mesure où les programmeurs, en tant que communauté, peuvent devenir tellement dépendants de leurs cadres choisis qu'ils ne comprennent plus le fonctionnement sous-jacent, ou dans le cas de nouveaux programmeurs, n'apprennent jamais le fonctionnement sous-jacent pour commencer avec. Il est facile de se spécialiser à un point tel que vous n'êtes plus un "programmeur PHP" (par exemple), mais un "programmeur Drupal", à l'exclusion de toute autre chose.
Qui s'en soucie, non? Nous avons le cadre! Nous n'avons pas besoin de savoir "le faire à la main"! Droite?
Le résultat de cette perte de compétences de base (parfois dans la mesure où les programmeurs qui ne pas utilisent des cadres sont considérés comme "obsolètes") est qu'il devient courant d'utiliser un cadre où il n'est pas nécessaire ou approprié. Le fonctionnalités le framework facilite la liquidation confondu avec ce dont le langage de base est capable. Les développeurs commencent à utiliser des cadres pour accomplir même les tâches les plus élémentaires, de sorte que ce qui était autrefois considéré comme un processus rudimentaire implique désormais de grandes bibliothèques avec leurs propres bizarreries, bogues et dépendances. Ce qui était autrefois accompli en 20 lignes est maintenant accompli en incluant un cadre de 20 000 lignes ET en écrivant 20 lignes pour utiliser le cadre.
A l'inverse, on ne veut pas réinventer la roue. Si j'écris du code pour accomplir une petite tâche courante et de base, j'ai peut-être l'impression de perdre mon temps quand je sais que le framework XYZ offre toutes les fonctionnalités que je recherche, et bien plus encore. La partie "beaucoup plus" m'inquiète toujours, mais il ne semble pas que beaucoup le considèrent encore.
Il doit y avoir une bonne métrique pour déterminer quand il est approprié d'utiliser un framework. Que considérez-vous comme le seuil, comment vous décidez quand utiliser un framework, ou, dans le cas contraire.
"Il doit y avoir une bonne métrique pour déterminer quand il est approprié d'utiliser un framework."
Pas vraiment. S'il y avait de bonnes mesures pour déterminer l'utilisation appropriée de toute technologie, vous ne verriez pas le langage, l'éditeur et la méthodologie des guerres sacrées.
Les groupes avec lesquels j'ai travaillé font tous la même chose - faites une estimation des coûts et des avantages, choisissez la voie la plus productive et espérez qu'ils ont raison. Ce n'est pas terriblement scientifique - une partie d'intuition, trois parties d'expérience, une partie de sensibilité au marketing, une partie de ruse et cinq parties d'opinion.
Les cadres ne sont que des outils. Je ne pense pas que ce soit la faute d'un cadre s'il est surutilisé, plutôt celui de la personne qui l'utilise de manière excessive. Le vieil adage "si vous avez un marteau, tout ressemble à un clou" montre que cette façon de penser existait bien avant même les ordinateurs.
Devenir trop spécialisé peut en effet devenir un problème à long terme - tant pour un développeur que pour des espèces biologiques. Pour la survie à long terme, il faut équilibrer soigneusement l'effort de développer ses compétences dans plusieurs domaines.
Pour répondre à votre question spécifique, je ne pense pas qu'il existe une métrique pour cela. Je préfère utiliser un framework lorsqu'il simplifie la résolution de problèmes. Si l'utilisation d'un framework m'aide à résoudre un problème avec 2 lignes de code au lieu de 20, je vais évidemment l'utiliser. Mais même si ses 20 lignes contre 20, je pourrais décider d'utiliser un framework s'il me donne de meilleures abstractions, plus proches du domaine problématique, ce qui rend le code plus facile à comprendre et à maintenir.
Je pense que les cadres peuvent être surutilisés dans certains contextes, oui. Un cadre n'est qu'un outil, oui. Un framework vous permet de faire fonctionner quelque chose très rapidement, et en tant que tel est un excellent outil de prototypage.
Quelque part le long de la ligne, lorsque votre application atteint un certain niveau de complexité, les restrictions inhérentes à un cadre commencent à étouffer la croissance future, il me semble. L'astuce consiste à reconnaître quand vous avez rencontré un tel point de basculement, puis à décider ce que vous allez faire à ce sujet.
J'ai tendance à travailler le plus avec les applications Web et même si j'essaie d'être général, ma réponse peut ne pas s'appliquer à votre domaine de programmation.
Je vais également utiliser "framework" synonyme de "bibliothèque".
Avant d'implémenter un framework, il faut considérer quelques éléments, voici quelques exemples généraux.
#1. Le cadre fera-t-il gagner 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 que EntityFramework peuvent vous éviter entièrement d'écrire du code SQL. Ce qui peut être fantastique si votre équipe de programmation ne maîtrise pas SQL.
Les cadres sont construits pour, a) ajouter une interface conviviale au programmeur à des composants autrement complexes ou b) ajouter une abstraction à des composants déjà bien connus (ou établis).
Ce dernier (ou même le premier dans certains cas) peut réellement gêner le développement. Cela s'applique en particulier lorsque vous ou votre équipe de programmation allez implémenter un nouveau framework, 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'échelle de votre application
On dit que "tout ce qui vaut le coup vaut le coup" , mais ce n'est généralement pas le cas. Il n'y a probablement aucune bonne raison d'implémenter un framework de très grande taille si le but de votre application est d'imprimer "potato" .
Lorsque vous développez une application (que ce soit sur le Web, sur un ordinateur de bureau, sur un appareil mobile ou tout autre type d’application envisageable) - si vous pensez que la taille de votre framework "éclipse" votre (peut-être future) implémentation de celle-ci, alors cela pourrait être un gros problème. signe d'avertissement que votre infrastructure peut simplement gonfler votre application. Une bonne anecdote serait si vous incluez jQuery, juste pour ajouter une classe "chargée" à votre corps-tag lorsque le document est prêt. Faire cela avec juste du JavaScript natif pourrait être un petit peu plus difficile , mais cela ne fait pas gonfler votre application.
Par contre si un framework fait beaucoup de sale boulot sur l'intérieur (c'est-à-dire les cadres de base de données), alors il pourrait être viable de l'implémenter, même si vous n'utilisez que "partiellement" le cadre. Une bonne anecdote serait de ne pas essayer de construire votre propre pilote ADO.NET ou MongoDB, simplement parce que vous n'avez pas besoin d'utiliser la bibliothèque entière .
Parfois, les frameworks sont open-source (et avec des licences "faites ce que vous voulez"). Cela ouvre une nouvelle possibilité où une équipe de programmation pourrait opter uniquement pour des parties d'un cadre.
Cela rejoint finalement les questions # 1 et # 3.
# 3 Impact.
Parfois, la mise en œuvre d'un framework peut avoir un impact direct sur l'utilisateur final. Cela est particulièrement vrai pour les applications Web, car avoir de grandes infrastructures côté client peut affecter négativement l'expérience de l'utilisateur final. Les utilisateurs de machines plus lentes peuvent rencontrer un rendu lent, des problèmes de performances avec javascript ou des problèmes similaires causés par des machines de qualité inférieure. L'utilisateur avec des connexions lentes peut connaître des temps de chargement lents (au moins initiaux).
Même dans d'autres types d'applications, les utilisateurs finaux peuvent être affectés négativement par vos dépendances d'application. Les frameworks occupent au moins toujours un peu d'espace disque, et si vous développez une application mobile (ou même une application de bureau), cela pourrait être nécessaire pour être pris en considération.
Les frameworks côté serveur (encore plus spécifiques au Web) n'affecteront probablement pas vos utilisateurs finaux, mais cela affectera votre infrastructure . Certains frameworks ont des dépendances elles-mêmes qui peuvent vous obliger à redémarrer votre serveur Web, soit uniquement le service, soit le serveur entièrement.
Certains frameworks peuvent également être très gourmands en ressources.
Cela rejoint bien sûr les points # 1 et # 2.
Ce n'est qu'un grand "cercle de considérations", et il n'y a pas de véritable méthode scientifique pour décider si vous devez mettre en œuvre un cadre ou non.
Corbin March l'a très bien résumé:
Les groupes avec lesquels j'ai travaillé font tous la même chose - faites une estimation des coûts et des avantages, choisissez la voie la plus productive et espérez qu'ils ont raison. Ce n'est pas terriblement scientifique - une partie d'intuition, trois parties d'expérience, une partie de sensibilité au marketing, une partie de ruse et cinq parties d'opinion.
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 se rend la vie très difficile, de l'autre, vous avez le gars qui construit des applications lentes et gonflées.
Tous les frameworks ont des cas d'utilisation, c'est juste une question de les implémenter aux bonnes fins.
Les autres développeurs connaissent-ils le framework?
Si tous les développeurs connaissent le framework X, alors toutes les autres raisons d'utiliser le framework sont viables, allez-y! Pour moi, cela n'a aucun sens d'imposer l'apprentissage d'un cadre spécifique alors que la majorité du temps de développement sera consacré à l'apprentissage des subtilités du cadre.
En ce qui concerne votre déclaration sur les nouveaux programmeurs ne connaissant pas les bases, vous êtes beaucoup plus compatissant que moi! Oui, c'est dommage, mais vais-je passer mon temps à m'inquiéter de l'ineptie de quelqu'un d'autre? Nup. (Basé sur l'hypothèse que ces nouveaux membres de la communauté ne travaillent pas immédiatement avec vous.)
J'utiliserais un framework si (et UNIQUEMENT si) les conditions suivantes se vérifient:
Le cadre semble susceptible d'être soutenu pendant un certain temps. Je les ai déjà vus en fin de vie, et c'est vraiment ennuyeux. Surtout lorsque vous avez 9 mois dans votre projet et que le changement n'est plus vraiment une option. Et si le cadre n'est DÉJÀ PLUS pris en charge, réfléchissez à trois fois avant d'écrire quelque chose de nouveau en utilisant ce cadre. Peu importe à quel point vous le savez déjà.
Le projet correspond en fait au cadre. Comme un exemple assez ancien, avez-vous vu les choses que le MFC a été conçu pour faire? Les gens n'ont pas fini d'étranges choses pour le faire fonctionner pour les types d'applications où cela n'avait tout simplement pas de sens. Habituellement, ils passent plus de temps à se battre sur MFC qu’ils n’auraient passé à écrire l’application qu’ils voulaient.
L'équipe de projet est capable de travailler dans le cadre. Certaines personnes ne prennent pas ou ne peuvent pas prendre le temps de comprendre comment une application doit être écrite dans un cadre donné, et au lieu de cela, elles écrivent les choses comme elles le font habituellement, au lieu de la façon dont le cadre a besoin. Cette mauvaise correspondance entre le code et le framework finit généralement par coûter beaucoup de temps et d'efforts à tout le monde.