it-swarm.dev

Wann NICHT ein Framework verwenden

Heute kann man einen Rahmen für nahezu jede Sprache finden, der für nahezu jedes Projekt geeignet ist. Die meisten modernen Frameworks sind (im Allgemeinen) ziemlich robust, mit stundenlangen Tests, Peer-Review-Code und hervorragender Erweiterbarkeit.

Ich denke jedoch, dass JEDES Framework einen Nachteil hat, da Programmierer als Community möglicherweise so stark von ihren gewählten Frameworks abhängig sind, dass sie die zugrunde liegenden Funktionen nicht mehr verstehen oder bei neueren Programmierern die zugrunde liegenden Funktionen nie lernen anfangen mit. Es ist leicht, sich so zu spezialisieren, dass Sie (zum Beispiel) kein PHP-Programmierer mehr sind, sondern ein "Drupal-Programmierer", unter Ausschluss von allem anderen.

Wen interessiert das schon? Wir haben den Rahmen! Wir müssen nicht wissen, wie man es "von Hand macht"! Recht?

Das Ergebnis dieses Verlusts an Grundkenntnissen (manchmal in dem Maße, in dem Programmierer, die keine Frameworks verwenden, als "veraltet" angesehen werden) ist, dass es gängige Praxis wird, ein Framework zu verwenden wo es nicht erforderlich oder angemessen ist. Die Funktionen , die das Framework ermöglicht, sind verwirrt mit dem, was die Basissprache kann. Entwickler verwenden Frameworks, um selbst die grundlegendsten Aufgaben zu erledigen, sodass das, was früher als rudimentärer Prozess galt, jetzt große Bibliotheken mit ihren eigenen Macken, Fehlern und Abhängigkeiten umfasst. Was früher in 20 Zeilen erreicht wurde, wird jetzt durch Einfügen eines 20.000-Zeilen-Frameworks UND Schreiben von 20 Zeilen zur Verwendung des Frameworks erreicht.

Umgekehrt will man das Rad nicht neu erfinden. Wenn ich Code schreibe, um eine grundlegende, häufig auftretende kleine Aufgabe zu erledigen, habe ich möglicherweise das Gefühl, meine Zeit zu verschwenden, wenn ich weiß, dass Framework XYZ alle Funktionen bietet, nach denen ich suche, und vieles mehr. Der Teil "viel mehr" macht mir immer noch Sorgen, aber es scheint, dass viele nicht einmal mehr darüber nachdenken.

Es muss eine gute Metrik geben, um zu bestimmen, wann die Verwendung eines Frameworks angemessen ist. Was halten Sie für den Schwellenwert, wie entscheiden Sie , wann Sie ein Framework verwenden möchten, oder , wann nicht.

38
Chris

"Es muss eine gute Metrik geben, um festzustellen, wann die Verwendung eines Frameworks angemessen ist."

Nicht wirklich. Wenn es gute Metriken gäbe, um den angemessenen Einsatz einer Technologie zu bestimmen, würden Sie keine heiligen Kriege in Bezug auf Sprache, Editor und Methodik sehen.

Die Gruppen, mit denen ich zusammengearbeitet habe, machen dasselbe: Erraten Sie Kosten und Nutzen, wählen Sie den produktivsten Weg und hoffen Sie, dass sie Recht haben. Es ist nicht besonders wissenschaftlich - ein Teil Intuition, drei Teile Erfahrung, ein Teil Anfälligkeit für Marketing, ein Teil List und fünf Teile Rangmeinung.

27
Corbin March

Frameworks sind nur Werkzeuge. Ich denke nicht, dass es die Schuld eines Frameworks ist, wenn es überbeansprucht wird, sondern die der Person, die es überbeansprucht. Das alte Sprichwort "Wenn Sie einen Hammer haben, sieht alles wie ein Nagel aus" zeigt, dass diese Denkweise schon lange vor Computern existiert hat.

Zu spezialisiert zu werden kann in der Tat langfristig zu einem Problem werden - sowohl für Entwickler als auch für biologische Arten. Um langfristig zu überleben, muss man die Anstrengungen zur Entwicklung seiner Fähigkeiten in mehreren Bereichen sorgfältig abwägen.

Um Ihre spezielle Frage zu beantworten, glaube ich nicht, dass es dafür eine Metrik gibt. Ich bevorzuge die Verwendung eines Frameworks, wenn es die Problemlösung vereinfacht. Wenn mir die Verwendung eines Frameworks hilft, ein Problem mit 2 statt 20 Codezeilen zu lösen, werde ich es natürlich verwenden. Aber selbst wenn es 20 Zeilen gegen 20 sind, könnte ich mich entscheiden, ein Framework zu verwenden, wenn es mir bessere Abstraktionen gibt, näher an der Problemdomäne, wodurch der Code leichter zu verstehen und zu warten ist.

14
Péter Török

Ich denke, dass Frameworks in einigen Kontexten überbeansprucht werden können, ja. Ein Framework ist nur ein Werkzeug, ja. Ein Framework ermöglicht es Ihnen, etwas sehr schnell zum Laufen zu bringen, und ist daher ein hervorragendes Prototyping-Tool.

Irgendwann, wenn Ihre Anwendung ein gewisses Maß an Komplexität erreicht, beginnen die Einschränkungen, die einem Framework inhärent sind, das weitere Wachstum zu behindern, scheint mir. Der Trick besteht darin, zu erkennen, wann Sie auf einen solchen Wendepunkt gestoßen sind, und dann zu entscheiden, was Sie dagegen tun werden.

6
leed25d

Ich arbeite meistens mit Webanwendungen und obwohl ich versuche, allgemein zu sein, gilt meine Antwort möglicherweise nicht für Ihren Programmierbereich.

Ich werde auch "Framework" verwenden, das synonym mit "Bibliothek" ist.


Bevor Sie ein Framework implementieren, müssen Sie einige Dinge berücksichtigen. Hier einige allgemeine Beispiele.

# 1. Spart das Framework Zeit und Mühe?

Die Antwort auf diese Frage lautet fast immer ja. Frameworks werden in der Regel erstellt, um spezifische Probleme zu lösen und sie sehr gut zu lösen. Zum Beispiel können Frameworks wie EntityFramework Sie vollständig vor dem Schreiben von SQL-Code bewahren. Was fantastisch sein kann, wenn Ihr Programmierteam SQL nicht fließend beherrscht.

Frameworks werden erstellt, um entweder a) eine programmiererfreundliche Schnittstelle zu ansonsten komplexen Komponenten hinzuzufügen oder b) Abstraktion zu bereits bekannten (oder etablierten) Komponenten hinzuzufügen.

Letzteres (oder in einigen Fällen sogar Ersteres) kann tatsächlich im Weg stehen der Entwicklung. Dies gilt besonders, wenn Sie oder Ihr Programmierteam ein neues Framework implementieren, in dem sie noch nie zuvor gearbeitet haben.

Dies könnte möglicherweise Ihren Entwicklungsprozess verlangsamen, was möglicherweise kostspielig sein kann.

# 2 Der Umfang Ihrer Bewerbung

Es wird gesagt, dass "alles, was es wert ist, getan zu werden, ist es wert, übertrieben zu werden", aber normalerweise ist das nicht der Fall. Es gibt wahrscheinlich keinen guten Grund, ein übergroßes Framework zu implementieren, wenn der Zweck Ihrer Anwendung darin besteht, "Kartoffel" zu drucken.

Wenn Sie eine Anwendung entwickeln (sei es Web, Desktop, Mobile oder eine andere denkbare Art von Anwendung) - wenn Sie der Meinung sind, dass die Größe Ihres Frameworks Ihre (möglicherweise zukünftige) Implementierung "in den Schatten stellt", kann dies eine große Rolle spielen Warnzeichen, dass Ihr Framework Ihre Anwendung möglicherweise nur aufbläht. Eine gute Anekdote wäre, wenn Sie jQuery einbinden würden, um Ihrem Body-Tag eine "geladene" Klasse hinzuzufügen, wenn das Dokument fertig ist. Dies nur mit nativem JavaScript zu tun, mag ein ein bisschen schwieriger sein, aber es bläht Ihre Anwendung nicht auf.

Auf der anderen Seite Wenn ein Framework viel von Drecksarbeit im Inneren (dh Datenbank-Frameworks) erledigt, kann es sogar sinnvoll sein, es zu implementieren wenn Sie das Framework nur "teilweise" verwenden. Eine gute Anekdote wäre, nicht zu versuchen, einen eigenen ADO.NET- oder MongoDB-Treiber zu erstellen, nur weil Sie nicht die gesamte Bibliothek verwenden müssen.

Manchmal sind Frameworks Open Source (und mit "Do-Whatever-You-Want" -Lizenzen). Dies eröffnet eine neue Möglichkeit, bei der sich ein Programmierteam möglicherweise nur für Teile eines Frameworks entscheidet.

Dies knüpft letztendlich an Frage 1 und 3 an.

# 3 Auswirkungen.

Manchmal kann die Implementierung eines Frameworks den Endbenutzer direkt beeinflussen. Dies gilt insbesondere für Webanwendungen, da große clientseitige Frameworks die Benutzererfahrung negativ beeinflussen können. Bei Benutzern mit langsameren Computern können langsames Rendern, Leistungsprobleme mit Javascript oder ähnliche Probleme auftreten, die durch unterdurchschnittliche Computer verursacht werden. Bei Benutzern mit langsamen Verbindungen können langsame (zumindest anfängliche) Ladezeiten auftreten.

Selbst in anderen Anwendungstypen können Endbenutzer durch Ihre Anwendungsabhängigkeiten negativ beeinflusst werden. Frameworks belegen zumindest immer einige Speicherplatz, und wenn Sie eine mobile App (oder sogar eine Desktop-App) entwickeln, muss dies möglicherweise berücksichtigt werden.

Serverseitige Frameworks (noch webspezifischer) wirken sich höchstwahrscheinlich nicht auf Ihre Endbenutzer aus, aber auf Ihre Infrastruktur. Einige Frameworks haben Abhängigkeiten selbst, für die Sie möglicherweise Ihren Webserver neu starten müssen, entweder nur den Dienst oder den Server vollständig.

Einige Frameworks sind möglicherweise auch sehr ressourcenintensiv.

Dies knüpft natürlich an Punkt 1 und 2 an.


Es ist alles nur ein großer "Kreis von Überlegungen", und es gibt keine echte wissenschaftliche Methode, um zu entscheiden, ob Sie ein Framework implementieren sollten oder nicht.

Corbin March hat es sehr gut zusammengefasst:

Die Gruppen, mit denen ich zusammengearbeitet habe, machen dasselbe: Erraten Sie Kosten und Nutzen, wählen Sie den produktivsten Weg und hoffen Sie, dass sie Recht haben. Es ist nicht besonders wissenschaftlich - ein Teil Intuition, drei Teile Erfahrung, ein Teil Anfälligkeit für Marketing, ein Teil List und fünf Teile Rangmeinung.

Es ist auch wichtig nicht elitär zu sein. Frameworks sind Werkzeuge, die verwendet werden sollen. Ich kenne Menschen beider Extreme; Auf der einen Seite hat man den Kerl, der sich das Leben sehr schwer macht, auf der anderen Seite hat man den Kerl, der langsame, aufgeblähte Anwendungen erstellt.

Alle Frameworks haben Anwendungsfälle, es geht nur darum, sie für die richtigen Zwecke zu implementieren.

6
die maus

Kennen die anderen Entwickler das Framework?

Wenn alle Entwickler Framework X kennen, sind alle anderen Gründe für die Verwendung des Frameworks realisierbar. Für mich macht es keinen Sinn, das Erlernen eines bestimmten Frameworks durchzusetzen, wenn der Großteil der Entwicklungszeit für das Erlernen der Feinheiten des Frameworks aufgewendet wird.

In Bezug auf Ihre Aussage zu neueren Programmierern, die die Grundlagen nicht kennen, sind Sie viel mitfühlender als ich! Ja, es ist eine Schande, aber werde ich meine Zeit damit verbringen, mir Sorgen um die Unfähigkeit eines anderen zu machen? Nup. (Basierend auf der Annahme, dass diese neuen Mitglieder der Community nicht sofort mit Ihnen zusammenarbeiten.)

4
J.K.

Ich würde ein Framework verwenden, wenn (und NUR wenn) die folgenden Bedingungen zutreffen:

Das Framework wird wahrscheinlich für einige Zeit unterstützt. Ich hatte sie schon einmal am Ende ihres Lebens und es ist WIRKLICH ärgerlich. Besonders wenn Sie 9 Monate in Ihrem Projekt sind und ein Wechsel nicht mehr wirklich eine Option ist. Und wenn das Framework BEREITS nicht mehr unterstützt wird, denken Sie dreimal darüber nach, bevor Sie mit diesem Framework etwas Neues schreiben. Egal wie gut du es schon weißt.

Das Projekt entspricht tatsächlich dem Framework. Haben Sie als ziemlich altes Beispiel die Dinge gesehen, für die MFC gemacht wurde? Die Leute haben endlose seltsame Dinge getan, damit es für Arten von Apps funktioniert, bei denen es einfach keinen Sinn ergab. Normalerweise verbringen sie mehr Zeit damit, sich mit MFC zu beschäftigen, als sie damit verbracht hätten, die gewünschte App direkt zu schreiben.

Das Projektteam ist in der Lage, innerhalb des Rahmens zu arbeiten. Einige Leute nehmen sich nicht die Zeit, um zu verstehen, wie eine App in einem bestimmten Framework geschrieben werden soll, und schreiben die Dinge stattdessen so, wie sie es normalerweise tun, anstatt so, wie es das Framework benötigt. Diese Fehlanpassung zwischen Code und Framework kostet normalerweise alle viel Zeit und Mühe.

4
Michael Kohne