Les cadres mettent-ils trop d'abstraction? [fermé]

Je programme depuis un peu moins d'un an et j'ai une certaine expérience dans l'écriture d'applications système, d'applications Web et de scripts pour les entreprises / organisations. Cependant, une chose que je n'ai jamais vraiment fait est de travailler avec un framework comme Django, Rails ou Zend.

En regardant par-dessus le framework Django, je suis un peu frustré par la quantité d'abstraction dans les frameworks. Je comprends les objectifs principaux de DRY et du code minimal, mais une partie de cette dépendance excessive à différents modules et à une abstraction lourde des fonctions de base en a l'air:

1. Rend les programmes datés très rapidement en raison de la nature en constante évolution des modules / frameworks,

2. Rend le code difficile à comprendre en raison de la pléthore de cadres et de modules disponibles et de toutes leurs particularités,

3. Rend le code moins logique à moins d'avoir lu toute la documentation; c'est-à-dire que je peux lire certaines listes de compréhension et de logique conditionnelle et comprendre ce que fait un programme, mais quand vous voyez des fonctions qui nécessitent de passer des chaînes et des dictionnaires arbitraires, les choses deviennent un peu difficiles à comprendre à moins que vous ne soyez déjà un gourou un module donné; et:

4. Il est difficile et fastidieux de basculer entre les cadres. La commutation entre les langues est déjà un défi, mais elle est gérable si vous avez une compréhension suffisamment solide de leur fonctionnalité / philosophie de base. Le basculement entre les cadres semble être davantage une question de mémorisation par cœur, ce qui semble à certains égards encourager l'inefficacité même que ces cadres ont été conçus pour éliminer.

Avons-nous vraiment besoin de mettre environ 50 couches d'abstraction au-dessus de quelque chose d'aussi simple qu'une requête MySQL? Pourquoi ne pas utiliser quelque chose comme l'interface PDO de PHP, où les instructions préparées / les tests d'entrée sont gérés mais la requête SQL universellement compréhensible fait toujours partie de la fonction?

Ces abstractions sont-elles vraiment utiles? Les fonctionnalités ne sont-elles pas inutiles, rendant les applications plus difficiles par rapport à des applications similaires écrites sans utiliser de framework?

Les cadres peuvent en effet être délicats. Des problèmes peuvent facilement survenir lorsqu'un cadre est trop "avisé", c'est-à-dire lorsqu'il préfère vraiment un style d'application particulier et que toutes les parties sont conçues pour prendre en charge ce style particulier.

Par exemple, si le framework résume complètement le processus d'authentification d'un utilisateur en vous permettant d'ajouter simplement un composant, d'ajouter un modèle de connexion quelque part et le tour est joué, vous obtenez l'authentification de l'utilisateur gratuitement. Cela vous a épargné beaucoup de travail répétitif en vous souciant des cookies, du stockage de session, du hachage de mot de passe et ainsi de suite.

Les problèmes commencent lorsque vous réalisez que le comportement par défaut du code d'authentification du framework n'est pas ce dont vous avez besoin. Peut-être qu'il ne suit pas les dernières meilleures pratiques de sécurité. Peut-être avez-vous besoin d'un hook personnalisé dans le processus pour déclencher une action, mais le framework n'en propose pas. Vous devez peut-être modifier les détails du cookie en cours de définition, mais le cadre ne propose aucun moyen de le personnaliser.

L'abstraction offerte par le cadre vous a permis d'ajouter une fonctionnalité importante à votre site en quelques minutes au lieu de quelques jours au départ, mais à la fin, vous devrez peut-être lutter contre le cadre pour le faire faire ce que vous en avez besoin, ou vous devez réinventer la fonctionnalité à partir de zéro de toute façon pour répondre à vos besoins.

Cela ne veut pas dire que les abstractions du cadre sont mauvaises, pensez-vous. C'est pour dire que c'est toujours une possibilité que vous devez garder à l'esprit. Certains frameworks sont explicitement adaptés à cela, ils offrent un moyen d'obtenir quelque chose très rapidement en tant que prototype ou même cadre de production pour un type d'application très spécifique et limité. D'autres frameworks ressemblent plus à des collections de composants lâches que vous pouvez utiliser, mais qui vous permettent toujours beaucoup de flexibilité pour le changer plus tard.

Lorsque vous utilisez une abstraction, vous devez toujours comprendre au moins approximativement ce qu'elle résume. Si vous ne comprenez pas les cookies et les systèmes d'authentification, partir d'une abstraction n'est pas une bonne idée. Si vous comprenez ce que vous essayez de faire et avez juste besoin d'un code qui le fait déjà au lieu d'avoir à écrire fastidieusement le vôtre, les abstractions sont un excellent gain de temps. Des abstractions mal écrites peuvent vous causer des ennuis plus tard, c'est donc une épée à double tranchant.

Vous devez également faire la distinction entre les abstractions techniques et les abstractions de "règles métier" . La programmation dans un langage de niveau supérieur est une abstraction que vous ne voudrez probablement pas manquer (Python, PHP, C # contre C contre Assembleur; moins contre CSS), tandis que les «abstractions de règles métier» peuvent être difficiles si elles ne le font pas répondre exactement à vos besoins (authentification en un clic vs cookies à codage manuel).

En effet, les abstractions techniques «fuient» rarement, c'est-à-dire que vous n'aurez guère à déboguer le code machine lors de l'écriture d'applications en Python. Les abstractions de règles métier fonctionnent au même niveau technique et ne sont vraiment que des "ensembles de codes". Vous devrez probablement déboguer le cookie défini ou le hachage de mot de passe créé à un moment donné, ce qui signifie que vous plongerez dans de nombreux codes tiers.

Il me semble que vous comprenez mal les abstractions et la réutilisation du code.

Toute l'industrie du développement logiciel est construite sur des abstractions. Tout simplement parce que ne pas les utiliser, c'est-à-dire éviter d'utiliser des frameworks, des bibliothèques et en général du code qui n'est pas écrit en interne, augmenterait le coût de production d'un logiciel de cent, mille, probablement encore plus.

Comme si vous ne créez pas un jumbo jet à partir de zéro, sans utiliser les connaissances techniques développées pendant des années lors de la construction d'autres avions, vous n'écrivez pas de logiciel d'entreprise à partir de zéro.

Vous obtenez cela en utilisant PHP ou Ruby en premier lieu, vous avez déjà une énorme quantité d'abstractions, n'est-ce pas? Les plus évidents:

1. Le système d'exploitation, le langage de programmation et le compilateur fournissent une énorme abstraction sur l'assembleur et le matériel,

2. Le serveur Web fournit une abstraction des sockets, du basculement, du protocole HTTP, etc.,

3. SQL fournit une abstraction sur la façon dont les données sont stockées sur un support de stockage permanent et conservées en mémoire pour un accès plus rapide, assure l'ACID, la mise en miroir, etc.

Vous pouvez toujours essayer de créer une application Web sans utiliser ni système d'exploitation, ni serveur Web, base de données ou langage de programmation de haut niveau. Vous constaterez rapidement que vous avez passé des années à réinventer la roue, c'est-à-dire à recréer votre langage de programmation, votre serveur web et votre base de données, étant donné que leur qualité serait loin de la qualité des produits que nous utilisons réellement.

Les cadres ne sont pas différents de cela. Vous pouvez faire ce qu'ils font. Juste que vous perdrez votre temps à refaire les mêmes fonctionnalités, à la différence que ces frameworks le feront mieux et très souvent leur code sera testé et documenté mieux que le vôtre.

Prenons l'exemple d'un panier pour un site Web de commerce électronique. Vous pouvez inventer le vôtre et passer quelques semaines à le développer, ou vous pouvez prendre celui qui a été développé pendant des années par un groupe de personnes dans un cadre. Le leur devrait être testé, sans compter le fait que pendant quelques années, ces développeurs ont découvert et corrigé un tas de bogues que vous n'imaginerez pas lors du développement de votre propre panier.

Vous pouvez répondre que le leur est plus compliqué car il a plus de cas d'utilisateurs. Par exemple, le leur devrait traiter des remises, alors que vous n'avez pas de remises sur votre site Web et n'avez pas besoin de cette fonctionnalité dans le panier. Eh bien, vous n'êtes pas obligé d'utiliser cette fonctionnalité, et ce n'est pas comme si cela pénaliserait les performances de votre application Web.

Vous pouvez avoir un scénario très basique quand il est vraiment plus facile de développer votre propre panier au lieu d'utiliser celui existant. De la même manière, si la seule chose dont votre application a besoin est de stocker une liste de chiffres, rien de plus, vous n'avez pas besoin d'une base de données: un simple remplissage de texte suffirait. Dans ces cas, ne surchargez pas votre application: les scénarios simples nécessitent des solutions simples.

Un autre facteur est la lisibilité de votre code. Imaginez que vous avez créé un site Web de commerce électronique. Plus tard, vous avez quitté le projet et un autre développeur devrait le maintenir.

• Si vous aviez utilisé un chariot fourni par un framework, votre collègue serait soulagé: il doit maintenir un petit bout de code qui s'appuie sur un framework fiable et très documenté. Encore mieux: ce développeur a peut-être été utilisé pour travailler avec ce framework et le connaît bien. Sinon, il peut poser des questions sur Stack Overflow: à coup sûr, quelqu'un a déjà utilisé le framework.

• Si vous aviez votre propre panier, votre collègue devrait conserver un code personnalisé, peut-être même pas documenté, sans pouvoir obtenir de l'aide n'importe où.

En utilisant un framework, vous comptez sur un code qui est:

• Écrit par des développeurs expérimentés,

• Souvent révisé par paire,

• Testé à l'unité,

• Largement documenté,

• Utilisé depuis des années par des milliers de développeurs,

• Souvent pris en charge, vous pouvez donc signaler un bogue et le voir réellement corrigé,

• Connu par de nombreux développeurs qui connaissent les mises en garde et les problèmes possibles et peuvent vous aider sur des sites comme Stack Overflow.

• Disponible pour vous dès maintenant, gratuitement.

Je suis d'accord - la plupart des cadres deviennent des dictateurs gonflés. Ils promettent la liberté mais vous vous retrouvez dans la servitude. alors regardez un cadre comme un outil - le meilleur outil est celui qui reste à l'écart. Si en PHP, je suggérerais de vérifier le cadre Codeigniter, car c'est un équilibre élégant entre les conventions et la liberté et a une grande communauté. Et à l'affiche qui a utilisé l'exemple d'un panier de commerce électronique - j'aimerais tellement être d'accord avec vous. mais après avoir examiné le code de nombreuses solutions de commerce électronique - et conçu quelques-unes - je serais respectueusement en désaccord avec votre exemple.

Hmmm Un aspect de LedgerSMB sur lequel nous avons beaucoup travaillé était notre approche du framework. Il y a cependant deux problèmes fondamentaux qui viennent avec ce genre d'abstraction. Ceux-ci sont:

1. Explosion de dépendance, et

2. Mauvaise abstraction

Le premier est en fait meilleur que l'alternative qui réinvente la roue. Le second est un peu difficile à étiqueter car il peut provenir d'un cas de problème mal défini ou, plus souvent, de personnes utilisant quelque chose en dehors de son utilisation prévue.

Regardons par exemple les ORM. J'évite d'utiliser des ORM car il arrive très souvent que la base de données soit conçue pour le modèle objet de l'application car au mieux ce sont des couches d'abstraction qui fuient. Ce n'est pas forcément le cas. J'ai rencontré des développeurs qui parviennent à conserver une bonne conception de base de données et une bonne application tout en utilisant des ORM, mais ils ont recours à beaucoup de choses que le battage médiatique orm ne devrait pas être nécessaire, comme l'encapsulation de l'API relationnelle de la base de données derrière des vues pouvant être mises à jour.

Un problème majeur est bien sûr que plus le code est automatisé, en particulier lorsqu'il est également opaque, plus il est difficile de voir ce qui ne va pas. Il s'agit d'un point sur les ORM que @jhewlett fait ci-dessus (voir /software//a/190807/63722 ).

Un bon parallèle pourrait être l'avionique avancée comme cadre de pilotage d'un avion. Ceux-ci ont été hautement conçus pour la fiabilité et contribuent à l'augmentation de la sécurité des vols. Cependant, comme le soulignent de nombreux articles dans IEEE Spectrum, cela a un coût de récupérabilité à partir d'erreurs en dehors des limites de ce qui est considéré comme acceptable du point de vue de l'automatisation. Il en va de même pour le débogage. C'est une chose de déboguer du code SQL dans votre programme. C'est une chose très différente de déboguer une partie de votre programme qui écrit du code SQL pour votre programme à utiliser.

Nous avons écrit le framework LedgerSMB à partir de zéro car au moment où nous avons commencé, il n'y avait pas vraiment de bons frameworks qui faisaient ce que nous voulions. C'est en fait une chose dont je suis assez satisfait, et selon un développeur plus récent sur le projet, cela rend la personnalisation de l'application assez simple. (Nous gardons en fait la génération de code SQL au minimum et nous nous concentrons à la place sur les fonctions définies par l'utilisateur manuscrites, ce qui signifie que les parties d'écriture sql sont très fines). Oui, il fournit beaucoup d'abstraction à certains endroits, plus que certains programmeurs ne sont à l'aise (en particulier, "mapper les propriétés des objets aux arguments dans cette procédure stockée" nous pousse de temps en temps). Nous essayons, cependant, de garder tout simple et cohérent afin qu'il soit simple de déterminer ce qui n'a pas fonctionné. Cela fonctionne plutôt bien.

Au final, «trop» est un peu subjectif, mais au niveau objectif cela dépend aussi de ce que vous faites. Si vous faites exactement ce pour quoi le framework a été conçu, un framework bien conçu fournira une quantité parfaite d'abstraction. Si vous faites quelque chose qui est un peu moins adapté, l'abstraction deviendra à la fois trop et trop fuyante.

Oui, ils sont utiles. Ils vous offrent l'avantage de nombreux autres développeurs expérimentés qui travaillent pour résoudre un problème que vous devez résoudre, avec les avantages supplémentaires de l'avoir testé, corrigé de nombreux bugs et fourni des solutions à des problèmes délicats dont vous n'avez pas à vous soucier. vous en utilisant le cadre.

Peuvent-ils être exagérément gonflés? Sûr. Tout dépend de ce dont vous avez besoin et de ce que le cadre apporte à la table. Si vous avez une application Web simple, Rails est peut-être exagéré pour vous, et vous devriez envisager quelque chose de plus simple comme Sinatra comme solution.

Il y a certainement une courbe d'apprentissage à tous les cadres, et c'est plus raide avec plus de travail qu'il vous permet d'économiser. Cependant, l'apprentissage du cadre signifie que vous avez gagné du temps et pouvez tirer parti de toutes ces connaissances sur le prochain projet, au lieu de réécrire votre application à partir de zéro, une deuxième fois.

Mais, vous dites, je vais juste copier mon code de l'ancien projet, et je peux l'utiliser comme point de départ pour mon nouveau projet! Je vais juste changer ce qui est différent, et peut-être rendre certains de mes objets / fonctions plus généraux, et penser à une meilleure façon de résoudre ce morceau de code délicat! Félicitations, vous venez de créer un cadre. Faites cela plusieurs milliers de fois et vous avez quelque chose comme Django, Rails ou Zend.

Les cadres génèrent généralement plus de productivité (peut-être après une légère courbe d'apprentissage), mais il y a souvent un compromis à faire. Dans certains cas, par exemple, vous gagnez en productivité programmeur au prix d'une baisse des performances.

Envisagez les mappeurs objet-relationnels (ORM). Ils sont excellents en ce qu'ils prennent en charge une grande partie du code de cartographie fastidieux pour vous. Ils peuvent même créer vos objets pour vous. Cependant, en faisant abstraction du SQL, il est beaucoup plus difficile de raisonner sur les performances et d'optimiser vos goulots d'étranglement.

Si vous créez une application qui n'aura pas beaucoup de données ou de requêtes complexes, les performances peuvent ne pas être un problème pour vous. En effet, le temps du programmeur est le goulot d'étranglement pour de nombreux projets, et les frameworks, les bibliothèques et les langages de haut niveau aident à atténuer cela.

J'accepte que "vous utilisez des bibliothèques, mais les frameworks vous utilisent". C'est une façon très nette de le dire. Je ne suis pas d'accord que dès que vous commencez à réutiliser du code, vous commencez à construire un framework, car vous n'avez généralement pas besoin de faire beaucoup plus qu'un simple copier-coller pour utiliser à nouveau votre code - c'est un bibliothèque que vous construisez; pas besoin de devenir bizarre sur la façon dont vous introduisez le code dans votre site ou application.

Pour moi, le point crucial est que je dois tirer le meilleur parti d'une ressource qu'elle ne me demande d'investir. Ou, sous un autre angle, je dirais que dès que les besoins d'un cadre sont supérieurs aux récompenses disponibles, tout avantage est absent. C'est donc 'Oui! S'il vous plaît! Et merci!' à tous ceux qui font des actifs qui tomberont directement et fonctionneront au besoin dans mes propres html / CSS / PHP et SQL.

Une chose que je trouve incompréhensible est que les frameworks sont censés faciliter la maintenance? Si le maillage complexe des pièces d'interfonctionnement ne fonctionne pas comme prévu, vous feriez mieux de tout savoir sur le cadre en question. Ou soyez prêt pour une énorme entrée de nouvelle syntaxe.

Certaines personnes disent que c'est le principe hollywoodien des cadres: "Ne nous appelez pas, nous vous appellerons". En revanche, chaque fois que vous utilisez une bibliothèque, votre code l' appelle , et non l'inverse.

Comme vous pouvez le voir, le point important est de savoir qui contrôle - à savoir, le contrôle du flux de contrôle. Qui décide quelle instruction est exécutée après laquelle?

Il y a des arguments pour et contre, et chaque fois que je vois de telles discussions sans fin, j'ai tendance à penser que cela doit être une question de goût, plutôt qu'une question objectivement décidable. Sinon, cela aurait déjà été décidé.

À mon avis, si vous préférez utiliser des frameworks ou des bibliothèques en dit long sur le type de développeur que vous êtes, et non pas si l'une des deux approches est supérieure et finira par prévaloir.

Si vous préférez les frameworks, vous préférez échanger la liberté contre la sécurité: vous êtes probablement plus pragmatique et vous avez tendance à faire confiance aux autres pour faire leur travail correctement. Si vous préférez les bibliothèques, vous préférez échanger la sécurité contre la liberté: vous êtes probablement plus un idéaliste et vous remettez en question les idées et les revendications des autres.

Je ne pense pas qu'il serait sage de décider qu'il vaut mieux être comme l'ancien ou le dernier.

Répondre à votre question: les frameworks mettent-ils trop d'abstraction? Cela dépend de qui vous êtes, et en particulier de la distance avec laquelle vous vous sentez à l'aise par rapport aux premiers principes.

...

Et encore plus précisément, si vous n'aimez pas les frameworks comme Django, allez chercher des "microframeworks" comme Flask :)