Quand NE PAS utiliser un cadre [fermé]

Aujourd'hui, on peut trouver un cadre pour à peu près n'importe quelle langue, pour presque tous les projets. La plupart des frameworks modernes sont assez robustes (en général), avec des tests à chaque heure, un code revu par des pairs et une grande extensibilité.

Cependant, je pense que TOUS les frameworks ont un inconvénient: les programmeurs, en tant que communauté, peuvent devenir tellement dépendants des frameworks qu'ils ont choisis qu'ils ne comprennent plus le fonctionnement sous-jacent, ou dans le cas de nouveaux programmeurs, ils n'apprennent jamais le 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 tout autre élément.

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 n'utilisent pas de frameworks sont considérés comme "obsolètes") est qu'il devient pratique courante d'utiliser un framework là où il n'est ni requis ni approprié. Les fonctionnalités facilitées par le framework sont confondues avec les capacités du langage de base. Les développeurs commencent à utiliser des frameworks 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.

Inversement, on ne veut pas réinventer la roue. Si j'écris du code pour accomplir une petite tâche basique commune, je pourrais avoir 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 même plus.

Il doit exister un bon indicateur pour déterminer le moment approprié pour utiliser un cadre. Que considérez-vous comme le seuil, comment décidez- vous quand utiliser un framework, ou pas.

"Il doit exister une bonne mesure pour déterminer le moment approprié pour utiliser un cadre."

Pas vraiment. S'il existait de bons indicateurs pour déterminer l'utilisation appropriée d'une technologie, vous ne verriez pas le langage, l'éditeur et la méthodologie sainte Guerres.

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.

Les cadres ne sont que des outils. Je ne pense pas que ce soit la faute de la structure si elle est trop utilisée, mais plutôt de la personne qui en fait une utilisation 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 le développeur que pour les espèces biologiques. Pour survivre à long terme, il faut bien équilibrer ses efforts pour développer ses compétences dans de nombreux domaines.

Pour répondre à votre question précise, je ne pense pas qu’il existe une métrique pour cela. Je préfère utiliser un cadre pour simplifier la résolution de problèmes. Si utiliser un framework m'aide à résoudre un problème avec 2 lignes de code au lieu de 20, je l'emploierai évidemment. Mais même si c'est 20 lignes contre 20, je pourrais décider d'utiliser un cadre si cela me donne de meilleures abstractions, plus proches du domaine du problème, 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 constitue donc un excellent outil de prototypage.

À un moment donné, lorsque votre application atteint un certain niveau de complexité, il me semble que les restrictions inhérentes à un cadre commencent à freiner la croissance. L'astuce consiste à reconnaître le moment où vous avez rencontré un tel point critique, puis à décider de ce que vous allez faire à ce sujet.

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.

Les autres développeurs connaissent-ils le framework?

Si tous les développeurs connaissent le framework X, alors, étant donné que toutes les autres raisons d'utiliser le framework sont viables, foncez! Pour moi, cela n'a aucun sens d'imposer l'apprentissage d'un cadre spécifique lorsque la majeure partie du temps de développement sera consacrée à l'apprentissage des complexité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'inaptitude de quelqu'un d'autre? Nup. (Partant du principe que ces nouveaux membres de la communauté ne travaillent pas immédiatement avec vous.)

J'utiliserais un cadre si (et UNIQUEMENT si) les conditions suivantes sont vraies:

Le cadre semble susceptible d'être pris en charge pendant un certain temps. Je les ai déjà vus en fin de vie et c'est VRAIMENT agaçant. Surtout quand votre projet débute à 9 mois et que changer de fournisseur n'est plus une option. Et si le framework n'est déjà plus supporté, réfléchissez-y à trois fois avant d'écrire quelque chose de nouveau en utilisant ce framework. Peu importe à quel point vous le savez déjà.

Le projet correspond réellement au cadre. Comme exemple assez ancien, avez-vous vu les choses que MFC était censé faire? Les gens n'ont pas arrêté de faire des choses étranges pour que cela fonctionne avec des types d'applications où cela n'avait aucun sens. Habituellement, ils passent plus de temps à battre MFC qu’à écrire l’application qu’ils désiraient.

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é. Au lieu de cela, elles écrivent les choses comme elles le font habituellement, au lieu des besoins du cadre. Ce décalage entre le code et le framework coûte généralement beaucoup de temps et d’efforts à tout le monde.